CAIN-42 CAIN StudioHow KEYSTONE works
Five stages, one verdict rule, and no step where the AI model grades its own work.
1. Detect: FALSEWORK
FALSEWORK is CAIN-42's fabrication detector. It parses the Python file into an abstract syntax tree and applies
deterministic rules for code that looks finished but is not: a verifier that returns True without
comparing anything, a hard-coded score, an except that turns an error into success, a non-constant-time
secret comparison, and more. It grades each module REAL, PARTIAL, STUB or
UNKNOWN. It calls no model and no network, so the same input always gets the same answer.
In every recorded KEYSTONE run that had a defect, FALSEWORK named the check unconditional_verdict
(severity MEDIUM) and graded the file PARTIAL before the fix.
2. Act: the model writes a fix and a test
The model receives the file and the finding and must return structured JSON: the complete fixed file, an explanation, and a pytest test that should fail on the original and pass on the fix. The file content is sent as data, never as instructions. Each record stores the model name, token counts, seconds and the provider request id, so the call can be traced. If the model's test does not catch the defect, the engine allows one retry (added 2026-10-15).
3. Prove: sandboxed, with an independent test
Four test runs happen for every fix: the model's test on the original, the model's test on the fix, the reference test on the original, the reference test on the fix. The reference test is written independently of any fix (for the demo samples it ships with the sample) and the model never sees it. Since 2026-10-23 the reference test runs isolated from the code it judges, so the code under test cannot rewrite the test's result. The sandbox is bubblewrap: no network, read-only system, 256 MB of memory, 20 seconds. FALSEWORK then re-scans the fixed file.
4. Sign: canonical JSON, SHA-256, Ed25519, chained
The record is serialized as canonical JSON (sorted keys, no whitespace). Its SHA-256 is the
record_hash. Each record carries the previous record's hash in prev_record_hash, so removing,
inserting or reordering a record breaks the chain. The record_hash is signed with an Ed25519 key whose
fingerprint is published. The bundle also carries a signed head.json listing exactly which records it
holds, so a bundle cannot silently drop the last record.
5. Export: an auditor's zip
The whole ledger, or one run, downloads as a zip: the records, the signed head, the public key, a manifest of
SHA-256 hashes, a README and verify_keystone.py, a standalone verifier that imports no CAIN code and
refuses to report VALID until you pin the key yourself.
The verdict rule (current, since 2026-10-23)
| Condition | If it fails |
|---|---|
| FALSEWORK found a defect | NOTHING_TO_FIX |
| The model returned a usable fix and test (no API error, valid JSON) | NOT_VERIFIED with the error as the reason |
| An independent reference test exists | NOT_VERIFIED: "a test written by the same model that wrote the fix cannot prove it" |
| The reference test ran isolated, before and after | NOT_VERIFIED |
| The reference test fails on the original and passes on the fix | NOT_VERIFIED |
| The model's test fails on the original and passes on the fix | NOT_VERIFIED (e.g. "Claude's test also passes on the original") |
FALSEWORK re-scans the fix as REAL | NOT_VERIFIED |
| All of the above | VERIFIED_FIX |
VERIFIED_FIX. One record in the public ledger (sequence 2) was signed that way.
See the upgrade page.Where KEYSTONE sits in CAIN-42
CAIN-42 is a Byzantine trust fabric: no agent, node or wrapper vouches for itself. KEYSTONE applies the same rule to AI-written code: the model does not vouch for its own fix. It is a product built on CAIN-42's existing moats (evidence, provenance and attestation), not a new architecture layer.
FIRME AI CORPORATION · CAIN-42 is a Byzantine trust fabric. Numbers marked "our own check" were run by us, not by an independent party. Nothing on these pages is a certification.