Inputs
- Proposed change and target state
- Change policy and invariants
- Attestations and evidence
- Current system context
Extended platform
MZiNG
Change only within declared invariants.
Control Plane change assurance: policy gates, change lifecycle, commit invariant and enforcement planning for system change.
Responsibility
What MZiNG is responsible for
MZiNG governs change inside the Control Plane. It evaluates a proposed change against policy gates and a commit invariant, refuses a candidate that would violate the invariant, and records the decision through the change lifecycle: declare, attest, admit, candidate, commit, enforce, observe, reconcile, audit.
Change is where many invariant violations are introduced. MZiNG adds a governed path between a proposed change and the system accepting it, including a commit invariant that can refuse a candidate outright.
The lifecycle is deliberately explicit: a change is declared, attested, admitted, evaluated as a candidate, committed only within the invariant, then enforced, observed, reconciled and audited. Prior evidence shows the commit refusal working; the current state is labelled demonstrable rather than re-verified.
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.
Decision
Coordinate policy, constraints and uncertainty.
Execution
Apply the effect through a controlled adapter.
Evidence and audit
Keep linked, ordered, reviewable records.
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.
- Change lifecycle: declare → attest → admit → candidate → commit → enforce → observe → reconcile → audit
- Policy gates over a proposed change
- Commit invariant ΔJ/ε with candidate refusal on violation
- Enforcement planning and observation hooks
- PostgreSQL-backed durable change log and lease handling
Outputs
- Change admission decision
- Commit/refusal record
- Enforcement plan and observation results
- Audit entries
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 change control path, invariant commit refusal and enforcement planning are implemented with Go tests and prior smoke evidence. They were not re-verified in the current review pass, and packet-level enforcement is not implemented. A later D0 review also found an early 20/20 acceptance run had executed a bound that was later found violated, so this site does not cite that run as proof.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- MZiNG lifecycle smoke test with 65 assertions (prior recorded run).
- Commit invariant refusal unit and HTTP tests: a candidate failing ΔJ/ε must not commit.
- PostgreSQL persistence and lease takeover tests.
- D0 defect record superseding the early 20/20 acceptance claim.
Dependencies
- Control Plane
- Gatekeeper
- PostgreSQL
- 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
- Prior evidence only in this review pass: the control path was not re-run against the current head.
- Packet-level enforcement is not implemented; enforcement operates at plan boundaries.
- The early 20/20 acceptance run is not cited as proof because a later D0 review found an executed bound had been violated (1% bound executed at 40%).
- Container packaging is partial in the reviewed environment.
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 applies NiGeNje's governance model to change itself: the same separation of proposal, authority, commit and evidence, specialised for system change rather than agent tool calls.
Evaluation questions
- Which invariants govern a change in your environment?
- What happens to a candidate that fails the commit invariant?
- How is an accepted change observed and reconciled afterwards?
Next step
Evaluate MZiNG 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.