Release

Convergence Validation

Definition

The process of confirming that current system state converges to the governed intent defined in the operational context — performed before release promotion.

Definition

Convergence validation is the process of confirming that the current state of a system — its implementation, configuration, and dependencies — converges to the governed intent documented in the operational context corpus. Convergence validation is performed as part of the release certification process, prior to any promotion decision.

A system converges when its actual state is consistent with the governed decisions, constraints, and approvals that were established for it. Validation confirms this convergence is real and verifiable — not assumed.

Why It Matters

Software can be built correctly and still be wrong relative to governed intent. Tests pass. Build pipelines succeed. But if the implementation diverged from the operational context that governed its development — if an undocumented architectural decision was made, or a dependency constraint was bypassed — the release is not converged.

Traditional CI/CD has no mechanism to detect this. Convergence validation fills that gap. It compares the artifact under review against the operational lineage record, checking that every governance gate was passed and every constraint was met.

What Convergence Validation Checks

In a Yanzi-governed release, convergence validation confirms:

  • Intent alignment: the implementation is consistent with the intent artifacts in the corpus
  • Rule compliance: no active Rule constraints were violated during development
  • Role authority: all actions taken were within the bounded authority of the active Role
  • Checkpoint coverage: the lineage includes checkpoints at appropriate governance intervals
  • Approval completeness: every governance gate that required human approval was approved

What Happens When Validation Fails

A failed convergence validation does not block the release by default — it produces a divergence report. The report identifies which specific constraints were not met and surfaces the relevant lineage records. A human engineer reviews the report and determines whether to correct the divergence or explicitly accept it with a documented rationale.

This is governance by visibility, not governance by lock. The record of the divergence review becomes part of the canonical lineage.

In Yanzi

Convergence validation was introduced as a formal release gate in v2.9.1. The validation output is stored as an append-only artifact in the corpus, producing a permanent record of what was validated and when.