Operational Coherence: Versioning and evolution

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 ensures that the substrate survives temporal evolution with explicit governance. 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 system that works at time t may fail at time t+1, not because of bugs, but because the world has moved. The definition of "puffy" in 2024 may differ from "puffy" in 2026. The query that pinned puffy_v1 must eventually confront puffy_v2.

The Two Empires handle time badly. String-dominant systems have no versions: every run is "latest," and drift is silent. The embedding that retrieved relevant documents yesterday retrieves different documents today, and nobody can trace why. Schema-dominant systems have versions frozen in DDL: migration is a ceremony requiring downtime, committee approval, and prayer. Neither provides explicit semantics for how meaning survives change.

The Third Mode needs versioning rules: explicit discipline for how predicates evolve, how queries adapt, and how standing is preserved or downgraded across time.

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.

A vocabulary change Σ → Σ′ is a conservative extension relative to (S, Q, I) if:

1. Every sentence in the query language fragment, expressible over Σ and true under invariants I, remains true under I′
2. Every well-formed query in Q (the set of pinned queries over Σ in scope S) remains well-formed over Σ′
3. Every certified result over Σ remains certified over Σ′, provided all dependent predicate packages retain compatible certificates and all enforced invariants remain satisfied

Conservative extension is always relative to a scope, a query set, and an invariant set. "Conservative for all pinned queries over Σ in scope S" is the operational test. There is no absolute conservativity; there is only conservativity relative to what you are preserving. Truth preservation is evaluated on the dependency closure of Q under Σ (not the whole substrate).

Examples of conservative extension:

• Adding a new predicate that does not reference existing predicates
• Adding new views that refine existing views
• Adding new invariants that are already satisfied by existing data

What conservative extension buys you: old queries continue to work, old results remain valid, no migration required, standing is preserved.

A vocabulary change is a breaking change if it violates any conservative extension condition. 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 | downgrade_to_witnessed
}

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), ...]
}

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	Standing preserved
subset	v2 ⊆ v1 (v2(x) → v1(x))	Standing preserved forward; may downgrade backward
superset	v2 ⊇ v1 (v1(x) → v2(x))	Standing preserved backward; migration required forward
approximation	agreement ≥ threshold	Standing downgraded to witnessed
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 conservative certificate requires satisfying the agreement contract on all shared cases. 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) proves the migration preserves what it claims. This is the key difference from traditional migration tools. Migration tools run scripts; they do not produce certificates. The Third Mode requires a certificate that the migration preserves standing, invariants, and agreement contracts where claimed.

Migration is not "run this script." Migration is "produce a certificate that the script does what it claims."

Repair Semantics

Things break. Predicate evaluations fail. Invariants are violated. Agreement conflicts arise. Drift is detected.

Repair is the response: local patch plus overlap recheck. Repair is not rollback (too expensive, often impossible). Repair is not ignore (violates coherence). Repair is: fix locally, recheck affected overlaps, update standing.

RepairSemantics {
  trigger: failure | violation | conflict | drift,
  scope: local | cover | global,
  patch: LocalPatch,
  overlap_recheck: OverlapRecheck,
  standing_impact: preserve | downgrade | invalidate
}

Repair scope determines cost (priced by A21):

• local: Fix within a single view (cheapest)
• cover: Recheck overlaps in a cover (moderate)
• global: Recheck all overlaps across the site (expensive)

Repair vs migration boundary: When does a break trigger repair vs new version?

Condition	Action
Same predicate version, fix within a context, semantics unchanged	Repair
Semantic change, new computation, different intension	Migration

Rule of thumb: if you can describe the fix as "the predicate was evaluated incorrectly," it's repair. If you must say "the predicate means something different now," it's migration.

Repair produces a patch witness; migration produces a compatibility certificate. Repair keeps the package version; migration creates a new package version.

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)	Up to witnessed
promoted	Passed promotion; available in cover	Yes (cover)	Up to certified
deprecated	Superseded; still available	Yes (with warning)	Preserved
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 valid and auditable). "Standing invalid" means "not admissible for new contracts," not "historical evidence erased."

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 → 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: This is a breaking change. The old predicates are subsumed into a broader concept. The change type is widened for both employee→worker and contractor→worker.

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: downgrade (different intensions; worker is broader)
• 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." Standing is downgraded (from certified to witnessed) because the intension changed: "worker" means something broader than "employee."

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 valid.

T10: Higher-Arity Events

"Alice introduced Bob to Carol at the conference."

Higher-arity events have higher repair cost. Why? More projections = more overlap checks.

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

This 4-ary event produces 6 binary projections for overlap checking:

• 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. This is a temporal conflict: the social graph's stale snapshot disagrees with the new event.

Repair path:

1. Detect conflict: met_at(Alice, Bob, Conference_2024) implies they met; social graph (as of t−1) says no relationship
2. Produce obstruction witness: temporal mismatch (snapshot vs event)
3. Either repair the social graph view (patch to update snapshot + recheck all projections touching Alice or Bob) or reject the introduce event

This is repair, not migration: the meaning of met_at has not changed; a view's stale snapshot needs updating. If instead the organization decided that met_at should now require a formal introduction (changing the predicate's intension), that would be migration.

The recheck set is not just (Alice, Bob). It includes every claim touching Alice or Bob in the overlap with the social graph view. The recheck set grows with the entity's incidence in the graph.

Cost scaling:

• Binary predicate: 1 projection
• Ternary predicate: 3 projections
• N-ary predicate: n(n-1)/2 binary projections, plus higher-order constraints

From A21: C_overlap ∝ |V| · d̄ · k̄(p) where k̄(p) is average arity of predicate projections. Higher arity = higher coherence cost.

Implication: Higher-arity predicates should be admitted more conservatively, with higher standing thresholds and tighter scope constraints, because their repair cost is higher and conflicts propagate further.

Consequence

Chapter 22 defined what predicates promise: the package. Chapter 23 defined what queries require: the contract. Chapter 24 defined how both survive time: versioning rules.

Together, they complete Part V: Machines That Glue.

The substrate is now operational:

• A22 (Context Graph): Stores contexts, claims, witnesses, constraints, equivalences
• A23 (Identity Maintenance): Declares, propagates, and constrains equivalences
• A24 (Predicate Package): Bundles signature, intension, tests, invariants, provenance, scope
• A25 (Query Semantics): Specifies contexts, predicates, witnesses, uncertainty, invariants
• A26 (Versioning Rules): Governs evolution with conservative/breaking, migration, repair, lifecycle

Operational coherence is not "everything is consistent." It is:

1. Versioning is explicit: conservative vs breaking, with certificates
2. Migration is certified: plans with witnesses, not scripts
3. Repair is scoped: local patches with overlap rechecks, priced by A21
4. Compatibility is typed: different certificate types have different standing implications
5. Lifecycle is governed: versions move through states with explicit transitions

The system survives time because time is modeled. Versions are not accidents; they are first-class objects with certificates, migrations, and deprecation windows.

Part VI returns to the touchstones as proofs-of-necessity. Each fugue demonstrates the full machinery on a concrete problem.