Suites · not a certification
Conformance
A structurally admissible configuration is not a demonstrated effective guarantee. A harness that passes is not a validation of production REG.
Sources and reading context
reg-conformance/README.md and spec.md; tenir-conformance-s1-g1/README.md and STATUS.md; illustrative architecture, audit section
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
The reg-conformance repository is an implementation-neutral suite. It defines properties — safety, liveness, fault tolerance, I8 — and a ConsensusBackend interface: reserve, commit, release, reconcile, get_state. It prescribes neither Raft, nor Paxos, nor a particular database. Any backend that holds the properties declared by its profile is a possible subject of conformance. “Consensus” in the interface name means a coordination point for shared state, not necessarily a distributed algorithm.
Catalogue
The README and the illustrative document report the same counts, which they say are checked by a test independent of the generator: 144 theoretical combinations, 42 structurally admissible (9 single-process, 18 single-host, 15 multi-host), 102 rejected. Rules R1, R2, and R3 bind host scope, concurrency, and deduplication. A profile that violates resilience bounds is rejected: for crash-only, n ≥ 2f+1; for Byzantine, n ≥ 3m+1.
Structural is not effective. The effective-guarantee verifier requires a proof file to be present, a SHA-256 equal to the attestation, and a relative path without ... Otherwise it fails closed. The README says that failure, for the example profiles, is the intended behaviour. That absence is an incomplete marking: INCONCLUSIVE, IMPLEMENTATION_GAP, or a missing proof is not summarised as full admissibility, nor as posture NORMAL.
Run
From a copy of the repository, the documented commands are:
python3 tools/enumerate_configs.py
python3 tools/validate_profiles.py
python3 tests/test_catalog_enumeration.py
python3 tools/verify_effective_guarantees.pyThe runner runner.py describes itself as suite v0.3.2. Modes: --mode http (adapter, evidence level 2), --mode native (in-process kernel, level 3), or both. A result must declare interface_mode. Mixing native and adapter without a label is non-conformant in the sense of RFC-7. Report states include PASS, FAIL, INCONCLUSIVE, NOT_APPLICABLE, ADAPTER_REQUIRED, IMPLEMENTATION_GAP. INCONCLUSIVE is never a PASS.
spec.md v0.3.1 says the runner registers 53 vectors, of which 36 extended vectors were still IMPLEMENTATION_GAP, native C4 not applicable, and CT-R4-009 and CT-R4-010 open. That sentence dates the file’s scope. The tree continued. Do not read 36 as the live count without re-reading VECTORS.md.
Published validation — 20 October 2026
REG-Conformant — Raft single-host loopback profile (limited scope)
The REG Conformance v0.6.1 release, published on 21 October 2026, reports an independent re-run by Harv Banning on 20 October 2026: 46 of 46 tests PASS, for TENIR-Gov v5.6.1 (commit 8203705), on a single-host Raft loopback cluster.
Declared SHA-256 fingerprint: f9f9c98b42c939acd9b953e08e1da89a94fcbb3a5d8cf11abb8e3ec60d785172.
Scope: C3 is not claimed; this is not a third-party certification; physical multi-host remains unsupported. The release summary is a published attestation, not in itself an independent reproduction of the evidence or a production-behaviour guarantee.
Evidence, as of 19 October 2026
Logs under evidence/ carry headers that say execution was in the author’s environment, not by an independent verifier. The hash proves the file has not changed since the attestation. It does not prove the test was executed correctly. deployment.manifest remains, in the profiles that were read, a blocking dependency: without it, an external auditor cannot bind the evidence to the host hypothesis.
The README still summarises some multi-host profiles as having no evidence, and writes that no multi-host consensus implementation exists. The consensus-replicated.yaml profile in the same tree nevertheless declares RaftConsensusBackend 5.6.0 and points at evidence/test-raft-*.log. Those two texts do not agree. The logs themselves describe a 3-node cluster, a fault model with no Byzantine faults, and an author rather than a third party. The tenir_governance changelog states that test nodes use localhost and separate ports: this is not a trial on a physical multi-host network. The architecture drawing adds: Raft 5.6.0 is not proof of consensus in a hostile environment.
S1 harness
The tenir-conformance-s1-g1 repository, version 0.1.0, is the S1 G0+G1 executable harness, “Evidence Lost After Commit”. Its first line says it is not a validation of production REG. The G1 file repeats it: passing the tests proves that the harness satisfies the G0 assertions, not that REG or TENIR is validated.
STATUS.md is more precise, and narrower. It says the G0 operational definitions for S1 through S6 were run against an RFC-4 laboratory membrane, for the tested sequential interleavings, with CI artifacts. The S1 path calls a real PolicyEngine for the score. That does not establish unconstrained concurrency, production cryptographic verification, or certification of a gateway. The public sentence it asks readers to keep is exactly that.
Limits written in the harness README: the trust public key is supplied by the caller; rotation and revocation are not implemented; declared postconditions do not prove an effect in the world; S11 commitments are in-process artifacts. To run case S1:
python -m pytest tests/test_s1.py -v
python tools/run_s1.pyThe spec’s evidence levels — semantic mapping, adapter-tested, native conformant — remain labels that must be declared. None of them equals an independent audit until the subject, the revision, and the environment are cleanly pinned. The spec.md text says so.