Actual maturity · October 2026
Status
KB3 is the active doctrinal rendering line and the REG RFCs remain proposed drafts. TENIR-Gov v5.7.0 was published on 24 October 2026 with a bounded single-host deployment scope, no multi-host C3 claim and no production certification.
Sources and reading context
KB3 and versioning policy; REG RFCs; TENIR-Gov v5.7.0 release (24 October 2026), README and pyproject.toml; historical 5.6.x change logs; harness STATUS.md
Simplified public rendering, read on 19 October 2026. KB3: enacted, active doctrinal rendering line. It renders meaning; it is not the code, and not a constitution. KB2: prior rendering line. This site certifies no implementation. Read the detailed status →
On this page
Read this first
- The framework and the standard are not the software: KB3 and REG describe meaning lines or proposed rules.
- The software exists as a beta: TENIR-Gov v5.7.0 is published, but its stated scope remains bounded and single-host.
- Published does not mean certified: nothing on this page proves a customer deployment, multi-host tolerance, or exactly-once external effect.
Where each namespace stands
| Namespace | State the sources themselves assume |
|---|---|
| TENIR 2.0 | Name of the framework in the canon namespace. That name is not, by itself, the enactment of KB3. |
| KB3 | Enacted, active doctrinal rendering line, by the owner’s declaration of 19 October 2026. The files provided with that declaration contain no signed record under 00_GOVERNANCE/04_DECISIONS_AND_RATIFICATIONS. A document layer, outside the code. KB3 renders meaning; it does not create sovereign meaning and is not a new constitution. Specialized services or applications may wrap or extend it; they must not redefine it. TENIR-Gov should align to it; it is not KB3. |
| KB2 | Prior rendering line, continuity only. No simultaneous active authority with KB3. The build of 30 March 2026 is kept. The note that once named it active, at institution, is historical context, not current authority. KB1.1 is historical. Written and curated with assistance; author Abdelaziz Skiredj. |
| REG | RFC-0 through RFC-7: Proposed Standard, frozen draft, 2–3 October 2026. Not a standard adopted by an external body. |
| TENIR-Gov | Open-source beta software (“Development Status :: 4 - Beta”). v5.7.0 released on 24 October 2026, tied to tagged source commit 47ef67e3efc5f3008896a7d88bebf929fa0a98f0. A published release is not evidence of a qualified customer deployment. |
| 5.6.1 | Historical snapshot: the changelog reviewed on 19 October still said “Pending release”. That statement no longer describes the latest published release. |
| 5.7.0 | GitHub release and PyPI package 5.7.0, published 24 October 2026. Published deployment boundary: single host, verified production manifest and durable registry configuration; production multi-host Raft blocked by FM-20, with no multi-host C3 fault tolerance or external exactly-once provider effect claimed. |
| S1 harness | Laboratory validation on tested interleavings. Non-certification written at the head of the repository. |
| Schemas v1 | Publishable bundle of February 2026, example hosts, stubs acknowledged. |
Published deployment boundary — TENIR-Gov v5.7.0
The 24 October 2026 release and its tagged README explicitly separate publication, CI success and deployment qualification. The published boundary is bounded single-host operation with a verified production manifest and configured durable registry. Publication does not prove that a customer has deployed the package, an external exactly-once effect, or multi-host C3 tolerance. Test figures require a named commit, environment and test selection; historical coverage figures are not guarantees for this release.
Historical 5.6.0 audit (not the v5.7.0 status)
The earlier illustrative document reported three findings on v5.6.0. Keeping them here preserves the history; it neither proves that they persist nor that all v5.7.0 configurations remediate them:
- F-01, commit.
reconcile_commit()might force a mutation without re-checking capacity. A RELEASED state might become COMMITTED, violating I8. - F-02, normalisation.
register_resource()would reset state. After a crash or reload, an available-resource signal might become false. - F-03, assessment. The linearizability checker would be invalid. LIN evidence might contain false positives.
The then-unpublished 5.6.1 changelog described corrections: reject reconcile_commit() unless the reservation is RESERVED, non-destructive resource registration, and further safety corrections “under review”, including the linearizability checker. The excluded perimeter is explicit: Byzantine tolerance, hardened authenticated transport, third-party attestation, proof of exactly-once external effect. An earlier Raft run is reported: 46 tests passed on commit 8203705, GitHub run 39205580977, Python 3.11.17, localhost. This site does not replay those tests. For conclusions about v5.7.0, consult the tagged source, scoped CI results and a corresponding deployment manifest.
The communication freeze described by the earlier illustrative document was a historical prerequisite to v5.7.0. The release has since been published; publication does not turn tests into certification or establish production suitability for every deployment.
The identified published package is tenir-governance 5.7.0 (beta line). Two SSRN working papers are recorded on the Publications page: 7291620 and 7197218. They do not certify the runtime, and they are not KB3.
Historical counts that are not v5.7.0 results
Older R5/R4 documents describe different test scopes: the v5.6.0 changelog recorded 787 tests; an older tenir_governance README cited 733 tests and v5.4.2. The tenir-governance README speaks of 557 tests and 96% coverage for R5. The tenir-gov README speaks of 313 tests. Those historical statements from different files are neither a single series nor measurements of v5.7.0. The Raft and full release test suites overlap: do not sum their counts. No tests were replayed for this site.
What is not established
- Production certification, an independent audit, or evidence that a customer deployment has a validated manifest binding evidence to its real host.
- Byzantine tolerance or multi-host C3 fault tolerance: neither is claimed for v5.7.0. Production multi-host Raft remains blocked by FM-20.
- Exactly-once external effect. Silence is not non-execution. The manuscript treats this as the E1–E3 limit, not as a deployed theorem.
- Key rotation and a signed trust anchor in the S11 harness.
- Adopters, contracts, or results of a UM6P programme. The profile names
partner_aandpartner_bexist in the code. They do not document a deployment. - Blueprint v4.4, cited by the code and by the manuscript, absent from the cloned trees.
What the sources themselves leave open
The prior rendering line asks the chassis to consume a complete TENIR 2.0 object instead of letting the implementation define the doctrine. KB3, without creating a new canon, further asks for one rendering line at a time, visible compliance class and degraded status, no silent renaming of the machine contract, execution mode kept separate from posture, and a public surface that states what it simplifies. The 5.7.0 drawing asks for safe reconciliation, non-destructive persistence, a reliable linearizability validator, and hardened consensus transport. The conformance README asks for deployment.manifest before any external audit. The harness STATUS.md asks readers to keep the non-certification sentence, and lists documentary remainder outside the repository. The versioning policy asks every surface to declare the authority it does not have. None of those asks is closed by this page.