What is a versioned policy?

The definition, and the failure it prevents

A versioned policy is a business rule — a scoring model, a routing rule, a discount threshold — treated as a published artifact instead of an editable setting. It carries a name, a version number and a content fingerprint; once registered, that version never changes. A decision made under it stores the version and fingerprint alongside the outcome, and revising the rule means publishing the next version.

The failure this prevents is silent reinterpretation. In a system where rules are editable in place, a question like why was this deal approved in March has no reliable answer, because the rule that approved it may have been edited since. With versioned policies the March decision names the March rule, byte for byte — the history of what the system believed is part of the data.

How Accordo implements it

Every scoring-model, routing-policy, enrichment-provider and discount-policy version carries a deterministic SHA-256 fingerprint of its canonicalized source and declared config. Startup inserts-or-verifies each name, version and fingerprint in one transaction: re-registering identical source is a no-op, and a registered version whose source has changed stops the application at boot rather than letting an old decision quietly mean something new. Rollback is publishing a new version that carries the earlier rules — history is never edited.

The decisions carry their versions with them. Every score run stores the model name, version and fingerprint it executed under, plus one contribution row per rule, so the number remains explainable later (C-07). Every quote version stores the discount policy's decision with the policy name, version and fingerprint that produced it (C-08). And the mechanism is deliberately falsifiable: one of the removable rules in the falsification kit is definition-version immutability itself, with a named test that catches its removal (C-23).

Thresholds and tunables must live in the declared config, which is fingerprinted and passed frozen into every evaluation. The fingerprint covers the definition's own source and that config only — a handler closing over a mutable outer variable is not captured, and closure analysis is deliberately not attempted, so the discipline is a contract the author keeps, enforced where it can be and stated where it cannot.

What versioning does not claim

A versioned policy is reproducible, not correct. Nothing verifies that version 2 encodes the rule the business meant, and a wrong rule is reproduced exactly as faithfully as a right one. Versioning answers which rule ran, never whether it should have.

Reproducing the decision is also not reproducing its inputs: a score run fingerprints the mutable record fields it read rather than copying all of them, which is why reproducing a historical routing decision exactly reads partially supported in the job catalogue. And no policy is ever evaluated because time passed — there is no scheduler, so every evaluation starts from an explicit request (L-04).