Assuming the service is not operating on the whole format, then it's already implicitly depending on the presence of those fields and also implicitly depending on the fact that they are a strict subset of the overall set of fields in the protocol. I'm not sure why making this fact slightly more explicit by having the client add a single interface would be a big pain.

In principle, this also enables type checking the whole pipeline before deployments since the interfaces can be known upfront rather than latent in the code.

Single interface?

In the search infrastructure example I mentioned up-thread, we had hundreds, maybe thousands of schemas involved.

I said a single interface per client, where I'm using "client" as a stage in the pipeline. Each piece of middleware that plugged into this pipeline already implicitly depends on a schema, so why not describe the schema explicitly as some subset of the underlying message?

Typescript has a types like Partial, Pick and Required which lets you work with subsets of fields of an existing type (https://www.typescriptlang.org/docs/handbook/utility-types.h...). Can something like that be built for Protobuf message processing?