The Contract Is a .proto File

One shared contract repository holds the schema file, which declares every service-to-service call in the system. The build then converts this schema file into typed clients and servers for both sides of the call, while also producing the HTTP role of a handle. The claim is that the contract is declared in the schema and nowhere else.

Each aspect of the interface - messages, calls, field meanings, required fields, value bounds, and refusal codes - is all defined within the .proto file. This approach may initially seem like a style preference, but it becomes clear when considering the alternative of two documents that remain in sync by a person's memory. The case study demonstrates that both environment variables and metrics, which were previously described manually in code-specific files, are now kept as repository artifacts.

For variables declared by the service configuration, the catalog records the defined_in file and line of the declaration. For metrics declared by the platform, they are also recorded in the catalog. The metrics snapshot includes an entry per metric, plus a dynamic row for the runtime metric registration. The check process runs the generator in check mode whenever any relevant files change, ensuring that any drift is caught as a build failure.

Certain resources, like variables with runtime-generated names, are not included in the catalog. The conclusion is that a manually written description drifts, while a derived and checked description remains consistent. The HTTP handle is not considered a separate interface but rather the same contract with its role explicitly marked using an annotation, with the HTTP specification derived from the schema.