Operational Coherence

The many become one, and are increased by one.

This chapter formalizes versioning rules as Anchor A26, completing the operational specification of the Third Mode substrate. A26 defines conservative extension relative to a scope-query-invariant triple, classifies breaking changes by type, and specifies four artifact kinds: conservative extension certificates, breaking change manifests, patch witnesses, and compatibility certificates. The chapter also develops migration plans, repair semantics, and the version lifecycle from draft through retirement. Together with A24 (predicate packages) and A25 (query semantics), A26 specifies the work required to continue relying on a result after its vocabulary or evidence changes. These are proposed contracts; their statement does not establish their implementation. For the narrative treatment of schema evolution and versioning discipline, see Vol I, Chapters 7 and 8 (The Witness Protocol and Similes of Symmetry).

Systems Live in Time

A query runs today. What happens tomorrow?

The predicate it references has been versioned. The invariants have been updated. The context views have changed. The equivalence declarations have been refined. The agreement contracts have been tightened.

Static semantics are not enough. A later use may require evidence or a definition that the earlier operation did not need. A bug is one possible cause of failure; changed conditions are another. The definition of "puffy" in 2024 may differ from "puffy" in 2026. The query that pinned puffy_v1 must eventually confront puffy_v2.

Existing systems already version schemas, models and evidence. The question is what a version record lets the receiving operation inherit. Pinning a package can preserve the meaning of a query; it cannot preserve support that has since been withdrawn. The version and the grounds for continuing to use it must remain separately inspectable.

Conservative Extension vs Breaking Change

Definition (A26: Versioning Rules). Versioning rules govern predicate and vocabulary evolution. The core distinction is between conservative extension and breaking change.

For this operational specification, a change Σ → Σ′ is preserving relative to (S, Q, I) if:

1. The declared old queries retain their interpretations and results on the specified data and evidence scope; hard invariant obligations remain satisfied
2. Every well-formed query in Q (the set of pinned queries over Σ in scope S) remains well-formed over Σ′
3. Every result whose certification is claimed to persist retains adequate, currently applicable grounds: compatible dependent packages, satisfied invariant obligations, evidence not withdrawn under the applicable correction process, and the authority required for its declared use

This operational preservation test concerns the dependency closure of Q in scope S. Logical conservativity has the separate definition in Chapter 16: an extension proves no new sentences in the old language. The operational label used here must not be offered as a proof of that logical property.

Changes to examine:

• A new predicate can preserve old query behavior if its definition and execution introduce no relevant interference
• A new view needs valid comparison maps and a check of the queries that will use it
• An invariant satisfied by current data may still exclude previously allowed models or future records; current-instance satisfaction does not prove logical conservativity

An established operational preservation result can spare the declared old queries a migration. Its certificate must identify the queries, data, evidence and checks it covers. A test on selected instances establishes that test result; it cannot silently certify every future instance. If a required preservation check is unfinished, compatibility remains unresolved.

A vocabulary change is breaking for the declared use if it violates a required operational preservation condition. Lack of a completed check is an unresolved assessment, not evidence that a break occurred. Breaking changes come in types:

Type	Meaning
removed	Predicate deleted from vocabulary
redefined	Predicate computation changed
narrowed	Predicate scope reduced
widened	Predicate scope expanded
renamed	Predicate token changed

Breaking changes require explicit declaration (the change is registered, not silent), a migration plan (path from old to new), impact analysis (which queries and standing are affected), and a migration witness (A17b) proving the migration preserves what it claims.

A26 Artifacts

The substrate stores versioning artifacts as first-class objects:

ConservativeExtensionCertificate {
  old_signature: Σ,
  new_signature: Σ′,
  scope: S,
  query_set: Q,
  invariant_set: I,
  standing_preservation: preserve_certified,
  current_support: EvidenceAndAuthorityRefs,
  checked_domain: DeclaredDomain
}

BreakingChangeManifest {
  change_type: removed | redefined | narrowed | widened | renamed,
  affected_predicates: [PredicateId, ...],
  affected_queries: [QueryId, ...],
  migration_plan: MigrationPlanRef  // see MigrationPlan below
}

PatchWitness {
  view: Context,
  predicate: PredicateId,
  old_evaluation: Evaluation,
  new_evaluation: Evaluation,
  overlaps_rechecked: [(Context, Context), ...],
  correction: Option<CorrectionRecord>,
  reassessments: [DependentReassessment, ...]
}

CompatibilityCertificate {
  v1: (PredicatePackage, VersionId),
  v2: (PredicatePackage, VersionId),
  compatibility_type: conservative | subset | superset | approximation | breaking,
  direction: forward | backward | bidirectional,
  evidence: CompatibilityEvidence
}

Compatibility Certificates

Compatibility between predicate versions is not binary. It is typed, with evidence requirements and standing implications.

Type	Logic	Standing Implication
conservative	v2 ∩ domain(v1) ≡ v1	The established equivalence preserves the specified predicate result; continuing certification also requires current support and authority
subset	v2 ⊆ v1 (v2(x) → v1(x))	A supported v2-positive implies v1-positive; unchanged query results do not follow
superset	v2 ⊇ v1 (v1(x) → v2(x))	A supported v1-positive implies v2-positive; neither the converse nor unchanged query results follows
approximation	agreement ≥ threshold under a stated comparison	Supports that bounded comparison; exact certification and an automatic change of standing do not follow
breaking	fails agreement contract	Migration plan required

We use subset and superset rather than "refinement" to avoid ambiguity. In logic, "refinement" often means stricter (subset). In schema evolution, "refinement" often means more detailed (superset). Set-theoretic terms make the direction explicit.

Compatibility evidence depends on the predicate's agreement contract (A24). The contract specifies the distance measure; compatibility is agreement under that measure:

• Bool predicates: Exact match on shared exemplars
• Score predicates: |v2(x) − v1(x)| ≤ ε on shared exemplars (or calibrated loss ≤ δ)
• Probabilistic predicates: Divergence bound (e.g., total variation ≤ ε) or interval inclusion at confidence α

The minimum evidence set is dictated by the agreement contract. Some compatibility relations are proven (formal proof), some are empirically witnessed (test agreement), some are only calibrated (calibration witness).

CompatibilityEvidence {
  formal_proof?: Proof,              // for proven subset/superset
  test_agreement?: TestAgreement,    // for empirical compatibility
  calibration_witness?: CalibrationWitness,  // for score/probabilistic
  overlap_check?: OverlapCheckResult // for overlap exemplars
}

A universal conservative certificate requires grounds covering all shared cases claimed by it; a finite exemplar check certifies only its checked population unless additional grounds justify generalization. A subset certificate requires v2 true → v1 true on all shared cases. A superset certificate requires v1 true → v2 true on all shared cases. An approximation certificate requires agreement at threshold level. A breaking certificate indicates the agreement contract failed; migration is required.

Migration Plans

When a change is breaking, you need a migration plan: a structured artifact specifying how to move from old vocabulary to new.

MigrationPlan {
  from_version: VersionId,
  to_version: VersionId,
  forward_migration: ForwardMigration,
  backward_compatibility: Option<BackwardCompat>,
  migration_witness: MigrationWitness,
  deprecation_window: Duration
}

Forward migration specifies:

• Transform: How to convert old data/queries to new
• Standing policy: preserve (only for conservative parts), downgrade (change affects standing), or recertify (significant semantic change)
• Overlap recheck: Whether affected overlaps must be rechecked

Backward compatibility (optional) specifies how to serve old queries from new data, with explicit standing loss. Not all breaking changes have backward compatibility. When they do, the backward view may have gaps.

Migration witness (A17b) identifies what a migration preserves and the grounds for that claim. An implementation may supply a proof, an evaluated test or an attested assurance; those have different reach. Running a script does not by itself establish preservation, although ordinary migration tools can supply the required checks. A pending migration or a failed preservation test must not be recorded as a successful certificate.

Repair Semantics

A correction begins with a particular assertion. It may concern the evidence offered for it, an erroneous evaluation, a mapping or the scope that a receipt advertised. The original record identifies what was asserted; accepting a correction changes what may now be claimed on its strength.

The receiving operation needs more than a list of descendants. A supplier's report may have supported both a dimensional comparison and a claim about resistance to heat. A correction to the heat test affects the latter dependence. It does not refute the dimensional measurement merely because both appeared in the same file. Nor does withdrawal of a supplier's result dispose of a recipient's independent test. The dependency record must identify the property or premise consumed, its evidence version, and the conclusion or action for which it was used.

Consider a conclusion with two separately sufficient support routes:

If the accepted correction withdraws A, the first route no longer supplies the required support. The conclusion can survive through D and E if that route remains adequate for the same receiving use. It is not enough to find those letters elsewhere in a graph: their evidence may itself have depended on A, or may establish a different scope. Until that relation is examined, independence is unestablished and reassessment remains incomplete.

Here “independent” means unaffected by this correction, not statistical independence. The receipt identifies the route assessed and its grounds. If neither known route remains adequate, the old certification loses its support; this neither proves the conclusion false nor rules out a further investigation. Truth-maintenance and provenance work already distinguish alternative justifications from premises needed jointly.¹ The receiving institution adds the question of whether those grounds suffice for its actual purpose and authority.

A PropertyOrPremiseRef can identify the compound premise and its supporting derivation. The existing evidence and reassessment references can retain the two routes; a singular field name does not require collapsing them into one undifferentiated list. The record must show which route was consumed, which was reassessed and what supports any retained conclusion.

The proposed contract has a declared boundary: identified sources and uses, the dependency records examined, and the recipients reached. It makes no claim to discover every copy or every inference made elsewhere. A correction receipt cannot certify complete propagation merely by recording its own creation.

CorrectionRecord {
  source_assertion: ClaimReceiptRef,
  source_evidence: [VersionedEvidenceRef, ...],
  corrected_property_or_premise: PropertyRef,
  correction: CorrectedAssertionOrWithdrawal,
  grounds: [EvidenceRef, ...],
  accepted_by: AuthorityRef,
  authority_basis: PolicyOrDelegationRef,
  accepted_at: Time,
  examined_dependency_boundary: DependencyCoverage,
  reassessments: [DependentReassessment, ...],
  outstanding: [RecipientOrDependencyOrAction, ...]
}

DependentReassessment {
  use: VersionedUseRef,
  consumed_premise: PropertyOrPremiseRef,
  consumed_evidence: [VersionedEvidenceRef, ...],
  receiving_scope_and_policy: ScopeAndPolicyRef,
  disposition: support_withdrawn | independent_support_retained
             | reassessment_incomplete | dependency_unaffected,
  grounds: [EvidenceRef, ...],
  current_claim_status: ScopedStatus,
  notification: not_sent | sent | acknowledged | unreachable,
  action_review: not_applicable | outstanding | referred | completed,
  action_review_evidence: Option<AuthorizedProcessRef>,
  unresolved_obligations: [Obligation, ...]
}

These are manuscript formats, not a new executable interface. Appendix I's tenth operation records accepted withdrawal and its dependent treatment; Appendix G gives the corresponding explanatory records.

Disposition	Consequence for the receiving use
Required support withdrawn	The use must stop advertising that support. Its previous certification cannot continue on the withdrawn basis. This does not by itself prove the conclusion false.
Independent support retained	The conclusion survives on identified, adequate grounds unaffected by the correction. A bare assertion of independence is insufficient.
Reassessment incomplete	The remaining check and its owner or referral stay visible. Continued certification cannot be attributed to the unfinished check. A consequential pending use also requires I.1.6's responsible disposition, review point and response to continued uncertainty.
Dependency unaffected	The changed premise was not among the grounds consumed by this use; the recorded explanation identifies the distinction.
Action already taken	A separate authorized process must decide what reconsideration or remedy is required. This action status accompanies the evidentiary disposition; it is not a substitute for one.

Acceptance of the correction requires grounds and authority under the receiving process. The source asserter or its delegate can withdraw its assertion. An institution empowered to correct the record may accept a challenge under its own rules. A stranger's unauthenticated withdrawal is not a command to revoke another institution's conclusion; the substantive challenge may nevertheless require consideration. When authority cannot yet be established, that question remains pending. It is not recorded as an accepted withdrawal or dismissed as a demonstrated falsehood.

Once required support has been withdrawn through the applicable process, known dependent uses cannot continue presenting it as current. Their reassessment may still be unfinished. The record must distinguish removal of that support from a fresh decision about the conclusion, and distinguish both from notification. A sent notice does not establish receipt; acknowledgment does not establish reassessment. Unreachable recipients and absent dependency records remain explicit limits on coverage.

If incomplete reassessment leaves an action continuing or a consequential decision postponed, Appendix I, I.1.6 governs the pending use. The institution must identify who is responsible for disposition, when the use must be reviewed and what the applicable process requires if the evidence is still unsettled. Revising that date does not itself justify extending a burden. An unresolved authority check also needs this account when it keeps a substantive challenge pending; refusing an unauthorized withdrawal is not a decision that the challenge lacks merit.

A21 supplies a way to budget the investigation: named checks, reusable results, estimated costs and work left undone. Exhausting the budget cannot convert the remaining uses into unaffected dependencies. It can require a narrower completion claim and suspension of certification that would otherwise rely on the missing work. A separately authorized precaution or alternative course retains its own grounds; it is not relabeled successful completion of the ordinary check.

Repair can include a local patch, overlap rechecks, renewed testing or a return to an earlier representation. No one procedure is required for every defect. If an evaluation was wrong, its corrected record receives a new evidence identity while preserving the relevant history. If a definition changes, migration also has to address the altered meaning. A claim that no package semantics changed does not license overwriting the evidence that explains an earlier decision.

The same limitation applies after action. Correcting the report may change which components qualify for future use. It does not remove an installed component, discharge a contract or compensate a person. The repair record identifies affected actions and the authorized process to which they have been referred; completion of that process requires its own evidence. An institution cannot discharge a remedy by marking the underlying assertion corrected.

History remains available under appropriate access and retention rules. Preserving evidence of a defective decision does not authorize indefinite retention of personal information or renewed adverse use against its subject. The declared purpose and authority govern what must remain inspectable, by whom and for how long.

Version Lifecycle

A predicate version moves through states:

State	Meaning	Queryable	Standing
draft	Under development	No	None
admitted	Passed admission; available in scope	Yes (local)	As established by the scoped admission evidence
promoted	Passed the additional scope or use requirements	Yes (declared scope)	As established for the promoted use
deprecated	Superseded; still available	Yes (with warning)	Preserved where current grounds remain adequate
retired	No longer queryable	No (new queries)	Archival only

Deprecation windows: When a version is deprecated, queries pinning that version continue to work for a deprecation window (policy parameter: 30 days, 90 days, 2 versions). After the window, queries must migrate to a supported version or fail explicitly. The window is declared, not discovered when old queries break.

Retirement vs archival semantics: A retired version loses queryable standing (cannot be referenced in new query contracts) but retains archival standing (historical receipts remain available as records of what was checked). Retirement alone need not discredit an earlier result. A discovered defect may do so: preserve the receipt and its correction without continuing to advertise the rejected claim as certified.

This connects to A25 (Query Semantics): queries may pin specific versions or request "latest stable" (promoted, not deprecated). Version drift warnings are query-level artifacts.

T9: Schema Evolution

"Employees and contractors → workers."

Classic schema evolution. The HR system has employee_v1 and contractor_v1 as separate predicates. Business wants a unified worker_v1 that covers both.

Analysis: Adding worker_v1 while preserving the old predicates need not break their contracts. Suppose instead that the undertaking replaces those filters with the broader predicate and deprecates their interfaces. That change widens employee→worker and contractor→worker, requiring the migration below.

Compatibility certificate: superset (worker ⊃ employee; worker ⊃ contractor).

• employee_v1(x) → worker_v1(x) holds for all cases (100%)
• worker_v1(x) ↛ employee_v1(x) (contractors are workers but not employees)

Migration plan:

• Forward: employee_v1(x) ∨ contractor_v1(x) → worker_v1(x)
• Standing policy: retain the established positive implication on its grounds; reassess queries whose meaning or required support changed
• Backward: worker_v1(x) ∧ employment_type(x) = employee → employee_v1(x)
• Deprecation window: 90 days

Overlap recheck: Ensure employee and contractor views agree on worker semantics where they overlap (e.g., if the same person was classified as both at different times).

Artifacts produced:

• Breaking change manifest (type: widened for both employee→worker and contractor→worker)
• Migration plan with forward/backward
• Compatibility certificate (superset)
• Migration witness (preserves "is a worker" truth for all former employees/contractors)

The migration witness is the key artifact. It proves that every entity that was an employee or contractor is now a worker. Downstream queries that asked "show me all workers" will now include everyone who was previously returned for "show me all employees" or "show me all contractors." The proved implication can retain its stated assurance. A broader predicate does not automatically downgrade every result; old queries and broader new queries have different meanings and require their own evidence.

Deprecation note: employee_v1 and contractor_v1 remain as deprecated views during the 90-day window. Old queries pinning these predicates continue to work. The backward compatibility layer translates worker_v1 results into employee_v1 or contractor_v1 results using the employment_type discriminator. After the window, unpinned queries fail explicitly; archival receipts remain inspectable, with any superseding correction attached.

T10: Higher-Arity Events

"Alice introduced Bob to Carol at the conference."

An implementation that maintains more dependent projections can incur more repair work. Arity alone does not determine that set or its cost.

Worked example: introduce(Alice, Bob, Carol, Conference_2024)

One representation materializes six pair relationships from the four roles, retaining the event context where needed:

• met_at(Alice, Bob, Conference_2024): Alice met Bob at the event
• met_at(Alice, Carol, Conference_2024): Alice met Carol at the event
• met_at(Bob, Carol, Conference_2024): Bob met Carol at the event
• attended(Alice, Conference_2024): Alice attended conference
• attended(Bob, Conference_2024): Bob attended conference
• attended(Carol, Conference_2024): Carol attended conference

Note: met_at is not the same as a stable knows predicate. met_at(A, B, E) is event-scoped; knows(A, B) (if it exists) has its own temporal semantics and may derive from multiple met_at events or other sources. The projection is about the event, not about a persistent relationship.

Each projection may be stored in different views (social graph, event attendance, HR records). Suppose the social graph view has a snapshot from time t−1 that says knows(Alice, Bob) = false (no prior relationship). The introduce event at time t asserts they met. These statements are temporally compatible: people with no prior relationship can meet later. Neither a contradiction nor a reason to reject the event follows from the two dates.

Update path:

1. Preserve the time attached to the old relationship record.
2. Record the new meeting without treating it as a refutation of the earlier state.
3. Recompute current relationship views only where their declared derivation uses this event.

A repair is needed if an old snapshot was being presented as current, or if a rule mistakenly asserted that meeting and lack of prior acquaintance were incompatible. A new event alone requires an update, not an obstruction witness. Rechecks follow actual dependencies; merely mentioning Alice or Bob does not make every claim dependent on this event.

Cost scaling:

• Two roles: 1 pair
• Three roles: 3 pairs
• N roles: n(n-1)/2 pairs, with event grouping and other required context retained

In A21, k̄(p) is the average cost per check, not predicate arity; frequency and the actual overlap graph also enter the calculation. The projection counts above describe a scheme that materializes every pair. They do not bound the cost of every faithful encoding.

Implication: Admission and repair budgets must follow the dependencies the implementation actually checks. A higher-arity predicate may create more such work, but its arity alone does not justify a higher standing threshold or prove a greater repair cost.

Consequence

A package version tells a recipient which definition was used. A query receipt tells it which grounds supported an answer. A correction joins those records to a new obligation: identify what the affected use consumed and decide what remains supported. Keeping the version stable cannot settle that question.

The practical gain is selective work. A recipient can reuse an unaffected measurement, replace a withdrawn premise with independent evidence, or stop an unsupported certification without pretending that every earlier result has become false. That discrimination depends on recorded grounds, not merely recorded links. Where the record is missing, the contract exposes the gap instead of certifying that correction has reached its end.

Part VI tests these proposed obligations in constructed examples. A successful example establishes the stated operation under its assumptions. Whether an implementation supplies it, and whether an institution has repaired its consequences, remain separately answerable questions.

Footnotes

1. Johan de Kleer, “An Assumption-based TMS,” Artificial Intelligence 28 (1986), pp. 127–162, especially pp. 129–131, author-hosted paper; Todd J. Green, Grigoris Karvounarakis and Val Tannen, “Provenance Semirings,” PODS 2007, §§2–4, author-hosted paper. Assumption sets and provenance expressions distinguish conjunctive requirements from alternative sufficient derivations; a flat set of contributing records can lose that distinction. This schematic case borrows that distinction. It does not reduce empirical sufficiency or authorized reliance to Boolean derivation, nor identify absence of support with proof of negation. ↩