Change Control You Can Read: Versioning as Governance Evidence

Governance frameworks ask the same question of every model change: was it deliberate, documented, and communicated before it reached users? A platform that cannot prove that per change is asking to be trusted; one that publishes it per change is asking to be checked.

Change control is the least glamorous pillar of model governance and the one most audits actually turn on. The failure being prevented is specific: behavior that changed without a decision, a record, or an announcement — the silent update that makes March's stored answer inexplicable by June. This piece describes the change-control mechanism a verified-model dependency gives its integrators, then walks a real release through it end to end, because a worked example is better governance evidence than any policy summary.

The mechanism in four properties

First, changes are gated on verification: a release ships only when the second implementation agrees with the engine on every model's vector set, which means a change cannot reach production accidentally-half-made. Second, behavior binds to versions: any change in what a model computes bumps its spec version, and the version rides in every envelope, so every answer names the behavior regime that produced it. Third, the record is public and spec-anchored: the changelog page is generated from the specs' own changelog sections — the change record and the behavioral contract are one document, unable to drift apart. Fourth, detection is the caller's by construction: a CI fixture asserting your pinned version fails your build on any bump, which converts the vendor's change control into your own alarm (/writing/version-pinning-ci).

A real release, walked through

Take the divorce model's 1.2.0, shipped this August. The change: yearlyData.year became a 1-based relative index instead of the wall-clock calendar year — removing the model's only wall-clock dependence so identical inputs hash identically across New Year's. Trace it through the mechanism. The spec was updated first, its changelog entry written with severity flagged BREAKING (a field's meaning changed), scope stated (chart labels only; no other output moves), and rationale given (replay determinism). The second implementation was updated to match, and the harness — which gates every release — re-ran green. The catalog's version bumped, so every post-release envelope self-identifies as 1.2.0. And the entry published to the changelog page the same day — where an integrator's fixture failure would route them to it. Every governance question about that change — deliberate? documented? communicated? verifiable? — has a public answer with a date on it.

What an integrator's change-control file looks like

The governance payoff is that your side of the record assembles itself from commits. Each fixture update lands as a dedicated commit linking the changelog entry it responds to; each annual review memo (/writing/annual-model-review) summarizes the year's deltas; each stored envelope pins its answers to a version. Together they form a complete, dated narrative of every behavioral change in your math dependency and your response to it — produced as a byproduct of the integration patterns this library already recommends, not as a separate documentation effort. When a reviewer asks how vendor model changes are controlled, the answer is a directory listing, not a paragraph of assurances.

• ✓Pin versions in CI; let the fixture be your change-detection control.
• ✓On every bump, read the entry before re-running anything — severity lives there, not in the number.
• ✓Record your response per change: fixture commit linking the entry.
• ✓Fold the year's deltas into the annual review memo.
• ✓For governance files, cite entries by URL — the record is public, so your citations are checkable.

The standard this sets for the category

Most vendor change management is described in diligence answers and demonstrated never. A spec-anchored public changelog inverts that: the mechanism is demonstrated continuously and needs no describing. That inversion is worth generalizing into your vendor policy — for any computational dependency, ask not whether change control exists but where its record is published and how a caller detects a change mechanically. Vendors with good answers make your governance cheaper; vendors without them are asking your audit file to take their word for it — the one thing an audit file cannot do.