Compliance requires every service's application logs to carry the owning team and the deployed commit SHA by the end of the quarter. There are 210 services in 5 languages; 180 were generated from the platform's service template and all of them ship logs through the platform's collector agent. Which mechanism puts the fields on the logs of services already running in production?

The deciding property

Pick the layer you already own and already deploy. The requirement is retroactive - it is about 210 services that exist, not about the next one - and the collector agent is the only component in the stack that the platform can change and roll out by itself.

The second property is whether the field is knowable at that layer. Owning team and commit SHA both are: the agent reads pod metadata and labels that the deployment already carries, so it can attach them to every line it forwards without the application knowing anything about it. Coverage goes to 100% in one agent rollout, measured in days.

Why the other options fail

• The template is the instinct because the fields belong in a service's logging setup. A generator is a one-time copy, so it reaches the next 30 services and none of the 210. Fleet coverage arrives at the rate services are rewritten, which is years.
• A library plus pull requests does work, and it takes five implementations in five languages plus 210 merges by teams with their own priorities. Realistic coverage by quarter end is 60 to 80%, and the remaining fifth is the part compliance asks about. Keep this option for fields the agent cannot see.
• An admission policy blocks deployments of services that do not declare the fields. It verifies a manifest, not a log line, so it is checking a proxy for the thing required. Worse, it stops teams shipping without making a single existing log line compliant, and with most of 210 services non-compliant on day one it freezes the estate.

What it costs

The agent becomes load-bearing for an audit obligation, so its failure mode is now a compliance gap rather than a gap in dashboards. Budget for a per-line CPU cost on the node, for the extra bytes on every log line - two fields at 40 bytes against a 400-byte line is a 10% ingestion increase, which is real money at fleet volume - and for the fact that the platform is now the author of a field it cannot explain if a team disputes it. Record the enrichment in the agent's configuration history so an auditor can see when it started.

When this is the wrong answer

The moment the required field is only knowable inside the process. A tenant identifier, a user identifier or a correlation id exists in the request handler and nowhere in pod metadata, and no amount of agent cleverness can invent it - that genuinely needs the library and the 210 merges, which is why the two mechanisms belong in different places rather than competing. It is also wrong where the logging path is not uniform: if a third of the estate writes directly to a vendor endpoint and bypasses the collector, enrichment creates a silent split where some logs comply and some do not, and the first job is to make the path uniform.