Inputs
- Proposed change and regression suite
- Change evidence
- Laboratory environment configuration
Assurance and evidence
MZiNG Assurance
Change assurance in a standalone lab.
Separate change-assurance product: no-regression gate, signed evidence, nftables laboratory and PostgreSQL failover testing.
Responsibility
What MZiNG Assurance is responsible for
MZiNG Assurance is a separate standalone change-assurance codebase. It implements a no-regression gate, signed evidence and a laboratory for nftables and PostgreSQL failover behaviour. It is not the same codebase as MZiNG Network, and a formal relationship between the two is not established.
MZiNG Assurance explores change assurance in a self-contained laboratory: a no-regression gate, signed evidence for change decisions, and failure exercises for nftables and PostgreSQL failover.
It is presented separately from MZiNG Network because the evidence describes two separate codebases. The site does not claim that one is an extension of the other, or that the lab has been validated in a production or multi-vendor environment.
Lifecycle position
Where it sits in the governance lifecycle
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Admission
Establish authority independently of the executor.
Evidence and audit
Keep linked, ordered, reviewable records.
Conformance
Evaluate outcomes against the original obligations.
Verified capabilities
What is verified today
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
- No-regression gate for a proposed change
- Signed evidence for change-assurance decisions
- nftables laboratory exercises
- PostgreSQL failover exercise
Outputs
- No-regression gate result
- Signed change evidence
- Laboratory exercise reports
Evidence and maturity
What the evidence supports
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Maturity note
The standalone lab implementation and tests exist, with signed evidence and failover exercises. It is not running in the reviewed stack and is outside the release-candidate scope.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- mzing-change-assurance CLAIMS.md and README.
- Change-assurance readiness record: single-host lab, out of RC scope.
Dependencies
- MZiNG
- Certification and Audit Ledger
Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.
Limitations
What this product does not do (yet).
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
Limitations — read before evaluating
- Standalone single-host laboratory; not running in the reviewed stack and outside the release-candidate scope.
- No multi-vendor packet verdict, production identity provider or HSM was available.
- Separate codebase from MZiNG Network; no formal relationship between the two is established.
No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.
Relationship to the platform
How it fits
MZiNG Assurance is a separate change-assurance codebase from the Control Plane MZiNG capability and from MZiNG Network. It contributes laboratory evidence about regression gating and failover; it is not presented as a component of the integrated lifecycle.
Evaluation questions
- Which regressions should a no-regression gate cover?
- What evidence is signed, and by whom?
- What would a multi-vendor or production failover exercise require beyond this lab?
Next step
Evaluate MZiNG Assurance against a real control problem.
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.