What it is actually running

Credentials belong in the environment rather than in a checked-in file, so the environment has to beat the JSON. The cost of that is a config file which still reads the way it did the day it was written, while the running service has moved — and no surface reported the merge, so the only way to answer the question was to read the file and hope.

This is not hypothetical and the cost was paid before the feature existed: our own hub had "type": "filesystem" in its config file while every blob it stored went to MinIO. Two separate readings of that string reached the wrong conclusion, because the file is a plausible-looking answer that nothing contradicts.

So the dump comes from the process, not the file. What you get back is what the service resolved at startup, which is the only version of the configuration that has any effect on anything.

A merged value with no provenance is barely better than the file — it tells you what is running and lets you keep believing the file set it. So every value the environment overrode is marked with the variable that did it, and the mark is per value rather than a summary count.

A key that resolves to nothing annotates nothing, and would therefore read as "the config file set this" — so the test suites on both services assert that every recorded provenance key resolves against the dump it annotates. A provenance record pointing at a path that no longer exists is worse than none, because it is silent.

It reads the same way on both services, because the question is the same one and answering it differently per service is how you end up with two mental models of one fleet.