From Inventory Drift to Integrated Truth: How a Canonical OSS Inventory Makes Our Automation Safer

Every stack carries a quiet liability: the gap between the open source it *thinks* it runs and the open source it *actually* runs. That gap is invisible right up until it is not - when an upgrade assumes a version that was never deployed, a screening tool clears a component that is not really there, or a runtime guarantee is written against a module that has since moved. On 2026-06-29 the work concentrated on closing that gap for good.

Why this day mattered

A canonical OSS inventory is not documentation hygiene. It is the substrate that upgrade governance, compliance screening, and runtime guarantees all read from. When that substrate drifts, every downstream decision silently inherits the drift - and you only find out at the worst possible moment. Turning the inventory into a single, machine-readable source of truth means the systems built on top of it stop reasoning about a stack that no longer exists.

What changed

In a single closed UTC day, 118 merged PRs across 10 repos moved this from intention to fact.

The day's work pulled a fragmented OSS picture into one canonical, machine-readable inventory and made it discoverable the same way from every repository. Module identity was reconciled against the live tool-registry, so the names the platform uses and the names the inventory records finally agree. A crosswalk now ties the integrated-system view together, and the directory prefers trustworthy current copies over stale snapshots - so "where does this component really live, and at what version" has exactly one answer.

In parallel, the CI substrate got more honest about *where* it runs. Jobs now fail closed when they land on a runner that cannot actually execute them - a host without Node on its PATH, for example - instead of flapping between green and red depending on which machine picked up the work. A build that cannot be trusted to run is now treated as a build that did not run, which is exactly the behaviour you want guarding a publish lane.

Why it holds better

The combination is what matters. A canonical inventory gives every consumer one truth to read; fail-closed runners make sure the automation that reads it only proceeds on infrastructure it can actually trust. Drift has fewer places to hide, and the failure modes that used to look like flakiness now surface as explicit, debuggable stops. That is less exciting than a feature launch and far more valuable: it is the difference between automation you supervise and automation you can rely on.

Want to know more

With a canonical, machine-readable inventory in place, the obvious next question is how much of the upgrade-and-screening loop can become fully automatic - letting the stack propose, validate, and gate its own dependency changes against a truth it no longer has to guess at. That is the thread worth pulling next.