The name that survives its system

Production teams already use several meanings of “same”. A container registry means the same artefact when a digest matches. A deployment platform may mean the same workload when a stable object identifier persists. A product manager means the same service when users see the same name and purpose. A risk owner means something stronger: the approved assumptions, controls and responsibilities still apply.

These meanings overlap, but they are not interchangeable. A cryptographic digest is exceptionally good at distinguishing bytes. An inventory standard can identify components. Supply-chain provenance can record where, when and how an artefact was produced. SLSA, in-toto, OCI descriptors and SPDX strengthen these layers in complementary ways.[3][4][5][6] None of them, by itself, proves that two configured releases preserve the same consequences for people and institutions.

Four identities are hiding under one noun

It helps to separate four layers. Artefact identity asks whether the bytes are the same. Assembly identity asks whether the exact model, prompt, index, configuration, policy and tool set are the same. Service identity asks whether the stable product handle, endpoint and declared function continue. Governed identity asks whether the obligations that made the service acceptable still hold.

The layers are nested only loosely. A release can replace every artefact while preserving governed identity. It can also preserve every application binary while an external data source, clock, permission grant or vendor endpoint changes what the system may do. The system that matters is therefore not a file, model or pod. It is the configured socio-technical arrangement that turns intent, context and authority into effects and receipts.

Same for whom, and for what reliance?

Identity claims are always indexed to a use. The service can be the same product for a customer who only needs a stable endpoint, yet a new accounting system for an auditor who relies on journal semantics. It can be the same container image for operations and a new decision system for a person whose appeal now reaches different evidence. This does not make identity arbitrary. It means the relevant equivalence relation must be named.

Governed identity concerns a particular kind of reliance. It asks whether the people and institutions affected by the system can continue to rely on the same promises: which purpose constrains use, who may authorise an effect, what evidence supports it, what happens under uncertainty and how a mistake is reversed. Those promises are not private preferences. They are encoded in contracts, policies, controls, operating procedures and sometimes law.

This indexing also prevents overclaiming. A team may establish continuity for invoice classification while explicitly withholding it for automated payment. It may preserve the same advice function but not the same authority to act. The strongest honest identity claim is the narrowest one that covers the actual reliance being carried forward. A release record should therefore state not only “same system”, but “same governed system for these purposes, actors, effects and conditions”.

Why version numbers mislead

Semantic Versioning gives version numbers meaning relative to a declared public API. Major versions mark incompatible API changes; minor and patch versions indicate forms of compatibility.[8] That convention is useful, but an API is only one observable surface. A patch can preserve request and response schemas while changing a decision threshold, data entitlement, human review route or failure behaviour. Conversely, a major API redesign can leave the underlying authority and outcome obligations unchanged.

The hidden assumption is that interface compatibility implies responsibility compatibility. It does not. A bank transfer API can return the same fields while switching from “authorise then execute” to “execute then retrospectively screen”. A retrieval service can return the same answer while losing the source version needed for appeal. A model can preserve average accuracy while moving errors towards a protected group or a high-cost edge case. These are identity-relevant because they alter what affected parties and operators may legitimately rely upon.

flowchart LR
  A["The name that survives its system"] --> B["Identity lives in obligations"]
  B --> C["The dry-dock tests"]
  C --> D["The semantic change manifest"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#7B4CD8,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Identity lives in obligations

To make this precise, begin with a concrete situation. A case enters a claims-assessment service. The system gathers evidence, proposes a classification and may release a payment. Change one variable: the identity token becomes stale midway through the run. What should happen?

If the system’s contract says authority must be fresh immediately before an irreversible effect, the answer is more than “produce the right classification”. The system must stop, refresh authority or return a typed abstention. A replacement that reaches the same classification but pays on stale authority has not preserved the relevant behaviour. The causal mechanism is a governed obligation: a property that must hold across a sequence because someone relies on it for safety, legality, contestability or recovery.

The obligation vector

Represent the approved system by four obligation families. Let B denote behavioural commitments, such as accuracy bands, abstention rules and typed action semantics. Let A denote authority commitments, such as actor, subject, purpose, permission and freshness. Let E denote evidence commitments, including provenance, decision receipts and postcondition readback. Let R denote recovery commitments, including idempotency, compensation, escalation and safe resumption.

A baseline release S₀ and candidate release S₁ preserve governed identity in context K only when the projection of their risk-relevant executions onto those obligations remains equivalent within declared tolerances.

Every symbol refers to an operational object. T(K) is the set of trajectories that matter in the deployment context, including normal, edge, adversarial and interrupted runs. P discards irrelevant implementation detail and retains the obligations being tested. The tolerance δ states what variation is acceptable. For a latency target, it may be a numerical band. For “never execute after permission revocation”, it is zero.

The assumption that makes the formula useful is that the obligation set is declared before the comparison. If teams choose obligations after seeing results, the test becomes a story about whatever survived. Remove that assumption and almost any replacement can be called equivalent by ignoring its failures.

Why provenance is necessary and insufficient

Provenance answers indispensable questions. W3C PROV models entities, activities and agents. in-toto records which steps were performed, by whom and in what order. SLSA provenance links artefacts to builders, inputs and build definitions, and requires verification against expectations rather than passive storage.[7][4][3] Sigstore can bind signatures and attestations to image digests.[12] These controls help establish that the candidate is the intended candidate.

That is a precondition for continuity, not the conclusion. A perfectly authentic build can implement a newly dangerous rule. A complete SBOM can inventory a component whose threshold changed. A signed model can be faithfully deployed with a different retrieval corpus. Supply-chain evidence proves ancestry and integrity; semantic evidence proves preserved obligations. Governance needs both.

The dry-dock tests

A useful release process should not demand a full philosophical inquiry for every patch. It should ask stronger questions only when a change can reach stronger obligations. The practical answer is a graded set of tests, ordered from ancestry to consequence.

Test 1: lineage continuity

Can the organisation identify exactly what changed, who authorised it, which inputs produced it and what artefact reached the environment? This is where source revision identifiers, content digests, SBOMs, signed attestations and deployment manifests belong. SLSA’s insistence on verifying provenance against expectations is crucial because stored evidence that nobody checks is not a control.[3]

Passing this test permits one claim: the candidate descends through the intended change process. It does not permit “same behaviour” or “same governed system”. A negative result means semantic testing cannot be trusted because the object under test is not reliably bound to the object deployed.

Test 2: contract continuity

Does the candidate preserve the public and typed operational contract? Check schemas, error semantics, idempotency keys, timeout behaviour, state transitions and postconditions. Formal refinement gives the right intuition: a lower-level implementation is acceptable when it correctly realises the higher-level specification.[10] Behavioural subtyping makes a related demand that properties proven about the expected type continue to hold for its replacement.[9]

For production AI, ordinary API compatibility is too shallow. The contract should include abstention, uncertainty, evidence references, authority checks and unknown-outcome handling. Passing allows the claim that existing integrators can rely on the same typed behaviour inside the tested envelope. It still does not establish that policy, data rights or human oversight remain equivalent.

Test 3: governed continuity

Now test the obligations that justified approval: intended purpose, subject and actor binding, permitted context, decision thresholds, protected invariants, human authority, evidence sufficiency, monitoring, release and recovery. NIST’s AI RMF Playbook explicitly joins post-deployment monitoring with appeal, override, decommissioning, incident response, recovery and change management, and recommends tracking component and dataset modifications.[1] The FDA’s predetermined change control plan provides a regulated precedent for describing planned modifications, the method for developing and validating them, and their impact before relying on continued authorisation.[11]

Passing permits the scoped statement “the previous governance decision still attaches under context K and tolerances δ”. A negative result does not automatically ban release. It means the candidate must be treated as a new governed system, with a new approval basis, migration plan and explicit handling of old commitments.

The evidence packet must travel with the release

A continuity decision made in a meeting is weak unless its evidence is bound to the deployed candidate. The release packet should contain the approved anchor identifiers, candidate digests, configuration and data snapshots, the semantic change manifest, test-suite versions, test results, exceptions, approval identity and deployment receipt. After release, it should add operating observations and the first independent postcondition readbacks.

Temporal order matters. Provenance verified before a final configuration change does not cover that change. A policy decision evaluated at build time does not establish permission at effect time. A rollback plan demonstrated against an earlier database schema may fail after migration. The evidence chain should therefore mark when each claim became true and which later event could invalidate it.

This packet turns continuity into a reproducible judgement. Another reviewer can reconstruct the candidate, inspect the declared obligations, rerun the decisive traces and determine whether the same release was actually deployed. Without that binding, “tests passed” is an anecdote about an object that may no longer exist. Release evidence is part of governed identity because it connects the approved claim to the operating system that acts.

Do not let many small patches launder a large change

Teams often review changes one ticket at a time. That creates a cumulative-drift failure mode. Each patch remains below a local threshold, yet the sequence moves the system outside the original approval envelope. Thresholds rise, prompts become more directive, retrieval sources expand, reviewer time shrinks and recovery becomes manual. No single ticket declares a new purpose or authority model. The configured result nevertheless behaves like one.

The remedy is to compare the candidate not only with the immediately preceding release but also with an approved anchor. Every release should carry an obligations hash and a delta chain back to the anchor. When accumulated deltas cross a tolerance or touch a zero-tolerance invariant, the system must re-establish governed continuity or open a new approval.

stateDiagram-v2
  [*] --> Claim
  state "Four identities are hiding<br/>under one noun" as Claim
  state "Same for whom, and for what<br/>reliance?" as Test
  state "Why version numbers mislead" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

The semantic change manifest

The practical contribution of this paper is a semantic change manifest: a signed, machine-readable record that connects component deltas to obligation claims, evidence and release consequences. It complements an SBOM and build provenance rather than replacing them.

The manifest begins with two anchors. The configured anchor binds exact artefacts, data snapshots, policies, prompts, tools, topology and human roles. The governance anchor binds the declared purpose, authority model, action contracts, evidence obligations, risk tolerances and recovery guarantees. A release then declares which elements changed and which obligations those changes can reach.

Five questions every change must answer

What changed?

Exact component, configuration, data, topology, environment or human-work delta, bound to immutable identifiers where possible.

Which obligation can it reach?

Behaviour, authority, evidence or recovery, including zero-tolerance invariants.

What evidence tests preservation?

Provenance verification, typed contract tests, stateful interventions, subgroup checks, readback or recovery drills.

What is the result allowed to mean?

Lineage continuity, contract continuity, governed continuity, conditional release or new-system approval.

The fifth question is implicit in all four: what would make the claim fail? A good manifest stores defeaters. A change that introduces a new effect, expands a purpose, alters who may authorise, weakens evidence or removes a recovery path cannot be waved through by a high aggregate score.

Four release classes, not one pass flag

The manifest should produce one of four release classes. Governed continuity means lineage, contract, risk traces, receipts, recovery and anchor comparison all support the previous approval within scope. Conditional continuity means the contract is preserved but one or more governed claims still depend on operating evidence; release, if justified, must be reversible, bounded and time-limited. Lineage continuity only means the candidate is authentic and intended, but substitutability has not been shown. New governed system means purpose, authority or effect boundaries changed, or a relied-upon evidence or recovery obligation was removed.

These classes resist two common pressures. The first is the demand for a binary green tick even when evidence is incomplete. The second is the tendency to call every uncertainty a failure and thereby encourage teams to hide change. A graded result allows honest progress while keeping semantic claims precise. Conditional release is not a euphemism for approval. It is a separate transaction with tighter scope, stronger observation and an expiry condition.

The class should also determine communication. Users need notice when their available appeal evidence changes. Operators need new runbooks when recovery changes. Risk owners need a fresh decision when authority expands. Version numbers can remain useful, but the semantic change class is the part that tells stakeholders which reliance has survived.

How to use the artefact

Start from the latest approved anchor, rather than only yesterday’s build. Enter the primary change type and consequence tier. Mark only evidence that is bound to the deployed candidate. A test result from a staging build with a different prompt, dataset or policy package does not count.

A governed continuity result permits the previous approval to attach only for the declared context and tested tolerances. A conditional continuity result permits a bounded canary or reversible release with explicit monitoring and rollback triggers. Lineage only means the candidate is authentic but semantically unproven. New governed system means a purpose, authority or effect boundary changed, so the right action is reapproval, not a more flattering version label.

A negative result is informative. It identifies missing evidence or a changed obligation. It does not prove the candidate is unsafe. Likewise, a positive result cannot establish metaphysical identity, universal behavioural equivalence or safety outside the tested context. The tool is an assurance instrument, not an oracle.

type ContinuityManifest = {
  systemId: string;
  approvedAnchor: {
    configuredDigest: string;
    obligationsDigest: string;
    context: string;
  };
  candidate: {
    releaseId: string;
    artifactDigests: string[];
    dataSnapshots: string[];
    policyDigest: string;
    topologyDigest: string;
  };
  deltas: Array<{
    kind: "artifact" | "model" | "data" | "topology" | "authority" | "evidence";
    description: string;
    reaches: Array<"behaviour" | "authority" | "evidence" | "recovery">;
    zeroToleranceInvariant?: string;
  }>;
  evidence: {
    provenanceVerified: boolean;
    contractTestsPassed: boolean;
    riskTraceTestsPassed: boolean;
    receiptsComplete: boolean;
    recoveryDemonstrated: boolean;
    anchorCompared: boolean;
  };
  decision: {
    class: "governed-continuity" | "conditional" | "lineage-only" | "new-system";
    scope: string;
    requiredActions: string[];
  };
};

function classify(m: ContinuityManifest): string {
  if (m.deltas.some(d => d.kind === "authority") || m.decision.scope === "new external effect") {
    return "new-system";
  }
  if (!m.evidence.provenanceVerified) return "unbound-candidate";
  if (!m.evidence.contractTestsPassed) return "lineage-only";
  const governed = m.evidence.riskTraceTestsPassed
    && m.evidence.receiptsComplete
    && m.evidence.recoveryDemonstrated
    && m.evidence.anchorCompared;
  return governed ? "governed-continuity" : "conditional";
}

The strongest boundary

No finite trace set proves complete equivalence for an open production system. Unknown environments, adaptive users, vendor changes and distribution shifts remain. Formal refinement can prove properties only relative to a specification, and the specification may omit the harm that later matters. Empirical testing samples a world it does not exhaust.

The right response is not to abandon continuity claims. It is to scope them. State the context, tolerances, tested trace families, unmeasured risks, monitoring window and invalidation triggers. Require stronger post-deployment evidence as consequence and novelty rise. Continuity is a defeasible governance claim that must be re-earned, not a permanent essence attached to a product name.

Glossary

Approved anchor

A configured release and obligation set against which cumulative change is assessed.

Configured system

The exact models, data, prompts, policies, tools, topology, people and environment that produce effects.

Governed identity

A scoped continuity claim that previous obligations and approval still attach.

Obligation envelope

The tolerances and invariants covering behaviour, authority, evidence and recovery.

Risk-relevant trace

A sequence involving normal, edge, adversarial or interrupted conditions that may expose an obligation.

Semantic change manifest

A machine-readable link from release deltas to affected obligations, evidence and decision consequence.