Skip to main content
AlgoVoi’s Keystone Assurance Framework (Cell and KAF) is an assurance layer over the JCS conformance corpus: a hermetic runtime (a cell) that reproduces every conformance vector byte for byte with the network off, plus a sealed, hash-chained receipt (the Keystone Seal) that anyone can verify offline with no trust in AlgoVoi. It turns a green CI badge into a result you re-run and check for yourself. Last updated: 5 August 2026.

​
Why a badge is not enough

Every library ships a green CI badge and asks you to trust it. For money moving autonomously between agents, “trust my tests” is not an assurance model. A single disagreed byte is a failed receipt, a mis-bound payment, or a refund that will not compose. The question that actually matters is whether you can prove, independently, that an implementation produces exactly the right bytes without trusting the author. Cell and KAF answer it in two layers.

​
Cell (P1): the hermetic runtime

A cell is a deterministic, isolated runtime pinned to an exact (language, runtime version, libc variant) and resolved to an exact image digest per run. It takes the corpus and re-derives every vector from first principles inside a sealed environment.
  • No network at execution. Provisioning is a recorded, network-on exception; execution runs with the network off (--network=none) against a read-only copy of the corpus, and a network canary proves the isolation held.
  • Real modules only. A real-module rule means every result comes from an installed module, never from a -c one-liner or a REPL context that could mask an environment defect.
  • Same bytes anywhere. Run the same cell on your laptop, our CI, or a stranger’s server and you get the same bytes every time.
The first shift: conformance stops being “the maintainer’s suite went green” and becomes “re-run it yourself and compare the bytes.”

​
KAF (P2): the Keystone Seal

Reproducibility is necessary but not sufficient. You also need to know a given run is authentic and unmodified. The Keystone Seal turns each fully green run into a receipt.
  • The receipt body is JCS-canonicalised with algovoi-substrate, then differential-checked against the independent rfc8785, so the canonicalisation itself is cross-checked, not assumed.
  • It is signed (RFC 9421 plus RFC 9530) by the published algovoi-rfc9421-signer.
  • The receipt file is its own canonical bytes, its SHA-256 is the chain link, each receipt names its predecessor, and the first is anchored to the P0 snapshot (MANIFEST.txt). History cannot be reordered or backdated.
The second shift: an assurance result becomes a portable, tamper-evident artifact, not a screenshot of a passing build.

​
10-way consensus (P3)

A green result from one implementation proves one implementation. P3 extends the hermetic-cell run across ten independent language implementations: Python, JavaScript, Go, Rust, Java, PHP, C#/.NET, Ruby, Elixir, and Kotlin, including the RFC 8785 canonicalization author’s own Java reference. Every set of cross-validated vectors must agree byte for byte across all ten. A single disagreement fails the phase. 1226/1226 agreements are recorded in the current sealed chain. The third shift: conformance stops being one language’s answer and becomes ten independent implementations forced to the same bytes.

​
Strata and zero-escape (P4)

Generative seeded strata produce batches of adversarial inputs, each designed to probe a distinct class of canonicalization hazard: key-ordering edge cases, Unicode normalisation traps, number-boundary values, and structural depth pressure. The zero-escape gate requires every generated forgery to be rejected; a single escape fails the phase. The current sealed run passed 634 forgeries with zero escapes. The fourth shift: the corpus is no longer a fixed list an author controls. New hazard classes can be probed generatively, and the seal records the strata seed so the run is reproducible.

​
Chain and splice integrity (P5)

P5 red-teams the receipt chain itself rather than the vectors it covers. Two classes of attack are tested: chain attacks (reordering, truncation, predecessor substitution, genesis-anchor swap) and splice attacks (grafting a valid receipt from one chain into another). 10/10 chain attacks and 5/5 splice attacks are detected and rejected by the published kaf_verify tool. A single undetected forgery fails the phase. The fifth shift: the assurance artifact is itself adversarially tested, not just the conformance vectors it seals.

​
Aggregating seal (P6)

P6 packages the evidence from P1-P5 into a single Keystone chain. Each phase’s hermetic run produces a receipt; P6 seals all of them into the hash-chained sequence anchored to the P0 genesis manifest. The chain currently stands at 18 receipts. Anyone can re-derive the entire chain from the committed kaf-evidence/evidence.tar.gz with no external box: the archive contains every run artefact, and kaf_verify --evidence-dir re-runs the differential driver locally to recheck consensus. The sixth shift: the full P1-P5 assurance surface is collapsed into a single portable, tamper-evident artifact that an auditor can verify offline in one command.

​
Verify it offline yourself

The proof is a git clone. Reproduce every vector set and re-check the seal chain with the published verifier, with nothing to trust but the maths.
49 anchor sets and 374 vectors, with the cross-validated sets agreed byte for byte across ten independent language implementations at 1226/1226, and a seal chain that verifies with no help from us. The full detail, including the honesty rules the framework holds itself to, is in the corpus kaf/README.md.

​
Where it sits on the substrate

Conformance vector sets

The 49 anchor sets and 374 vectors KAF reproduces, cross-validated across ten languages.

JCS canonicalisation substrate

The five normative rules and the ten-implementation matrix the cells re-run.

RFC 9421 signer

The published signer that seals each receipt (RFC 9421 plus RFC 9530).

Verify it yourself

The hosted and installable path to reproduce the corpus without our infrastructure.

​
Frequently asked questions

​
What is the Keystone Assurance Framework (Cell and KAF)?

It is AlgoVoi’s assurance layer over the JCS conformance corpus. A cell is a hermetic runtime that reproduces every conformance vector byte for byte with the network off; KAF (the Keystone Seal) turns each fully green run into a sealed, hash-chained receipt. Together they let anyone re-run the corpus and verify the result offline, with no trust in AlgoVoi.

​
How is a hermetic cell different from a normal CI run?

A normal CI run proves the maintainer’s suite passed on the maintainer’s machine. A cell pins the language, runtime version, and libc to an exact image digest, runs with the network off against a read-only corpus, and proves isolation with a network canary. The same cell produces the same bytes on any machine, so you re-run it rather than trust it.

​
Can I verify a KAF receipt without trusting AlgoVoi?

Yes. Each receipt is JCS-canonical, its SHA-256 is the chain link, and each names its predecessor back to a genesis anchor. The published kaf_verify tool recomputes the whole chain offline against a public key, with no AlgoVoi account or network call, so an auditor can confirm nothing was reordered, edited, or backdated.

​
Is Cell and KAF backward compatible with the published packages?

Yes. Every published AlgoVoi package on PyPI and npm is checked to reproduce the same corpus bytes under the current substrate as before, byte for byte against pinned vectors. Backward compatibility stops being a changelog promise and becomes a re-runnable proof anyone can reproduce from a clone.

​
The one-liner

Cell and KAF turn “trust my tests” into “re-run mine and check the seal.” For money moving between agents, that is the difference between a claim and a proof.