Applied AI · Code Provenance
Released · three programs, 0.x
The Deterministic Stack
Lock what was asked for, gate every change an AI makes, repair what is already written — with no AI doing the checking
1 · The stack
2 · The Cartouche Monitor
3 · Closer
4 · CodeRadar
What this is
Three programs that keep an AI coding agent honest, in the order a change meets them. The Cartouche Monitor removes semantic ambiguity before a line is written — each line of the request is signed off on a clip of what it means — and watches the build against it, so the user's expectation is met. Closer fences the agent in and judges each change before it lands: counterfeit is rejected on the spot and sent back to be rewritten and re-tested, and only an accepted change reaches the file. CodeRadar watches what is on file and catches, then repairs, counterfeit code that got there anyway. None of the three asks a model whether the code is right; each check is a rule or a proof, and gives the same answer every time.
The technical shape
- Order
- Cartouche Monitor → Closer → the file is written → CodeRadar
- Cartouche
- removes semantic ambiguity: each line signed off on a clip → one hieroglyph per line → one master hash; every save is read against it, each symbol sealed or not
- Closer
- three tiers: you the signer, a restricted writer (Read · Grep · Glob · mcp__gc), a gate of fixed code · bin/gc + pack/live v40
- Closer's checks
- W1 World intact · R6 read the World · G18 no caches · S1 no fake-shaped code · E1 suite passes · C1 claims hold · U1 before/after · R10 a false positive is its own verdict
- CodeRadar
- supervised daemons · about 190 checks in ten families · one ranker over a 257-row table · one repair per finding, with before/after mirrors
- Record
- a hash-chained, append-only ledger: every accept and reject, expected against observed
- Stance
- offline by default · no model in any check · the same verdict every run
- Stage
- Cartouche 0.2.0 · Closer 0.2.0 · CodeRadar 0.1.0, released 2026-11-04 on GitHub under PolyForm Noncommercial · github.com/LowerJacksonMound/cartouche · /closer · /CodeRadar · Python targets, macOS first
The deep end · full technical outline
Outline v2 · expanding
Why three, and why no AI
Most of the market answers AI-written code with a second model — have an AI check the AI. But a probabilistic failure cannot be caught by a probabilistic checker: a model that writes counterfeit code can just as easily write a passing verdict. Every gate in the stack is an AST rule, the repo's own tests, or a sealed claim; kernel, scanner and pack import no model client and no network module. And no single gate is enough, because counterfeit enters at three moments: when the request is misread, when the change is written, and after it is on file.
What counterfeit code is, to all three
Code that performs the appearance of work and still passes tests: stubs, constant returns, swallowed exceptions, answer tables keyed on the tests' own inputs, pass-throughs that claim to transform, writes that go nowhere. The Cartouche Monitor sees it as a build that drifts from what was agreed; Closer names eleven species of it, T1 to T11; CodeRadar catalogues it per rule family.
One loop, one record
The Cartouche Monitor fixes what was asked for, so Closer judges a change against the intent and not against the agent's reading of it. Closer decides whether a change may land. CodeRadar decides whether what landed is counterfeit and hands back one repair — and a repair re-enters through the signer as a new ticket, so every write, a fix included, still passes the gate. Every verdict is written to a hash-chained ledger that cannot be edited after the fact.
The handoff between the gate and the watch
Closer sits before the write; CodeRadar sits after it. The repo is the only surface they share, and neither calls the other. The division is a ruling: Closer hunts species T1 to T10 at land, and a T11 counterfeit — right on every tested input, wrong on one the tests never give — is allowed through the gate for CodeRadar to catch in the live build.
Where it stands
Released 2026-11-04 as three 0.x prereleases. Cartouche 0.2.0, Closer 0.2.0 and CodeRadar 0.1.0 each ship with a self-test and planted counterfeits a stranger can run from a clone; every command in each QUICKSTART was run as written and its output shown. Closer's record stands: on its sealed set of 33 tasks and 66 working counterfeits, none landed; on 34 real open-source bugs, all 34 buggy trees were struck and all 34 fixes landed clean. CodeRadar's write route, unfinished at the last update, completed live cycles in four trial rounds and found six of seven planted shapes on a real app; what it cannot decide is named under Known limits in its README. Issues are welcome; none of the three takes outside code.
1 · The Cartouche Monitor
Semantic ambiguity: one sentence, two apps
"Kids make nutritious snacks" is two sentences sharing one set of words. App requests fork the same way, quietly. "Send the car; it drives to me" means a real car coming down the street to the door — and the same words allow a picture of a car, driving toward you from the horizon, one pixel at its vanishing point. An agent that builds the second reading has met every word; its tests pass; a reviewer AI reading the same words the same way approves it. The words were met and what was meant was not. Better code does not close that gap; only removing the ambiguity does.
Remove semantic ambiguity before a line is written
Cartouche answers a request with clips, not questions. Each line the app will say — "Where to?", "That card was declined. Try another?", "On my way." — is found on a clip of someone saying it, or rendered, and a person watches it and signs it off. The clip fixes what the line means: "On my way." is a driver at the wheel with the street going by, not a picture of a car. Each signed-off line is tied to one function, and its lock is hashed. Once every line is signed off there is one reading of the request left, and it is the person's.
The user's expectation is met through the removal of semantic ambiguity
A builder can only miss what was meant when the request allows more than one meaning. Sign-off on clips leaves one; the build is then held to that one, and nothing rereads the prose and guesses again. So the app that is built is the app the person watched, meant and signed off — the car comes to the door — not merely an app that matches the words.
Why real Egyptian hieroglyphs: no modern meaning
Each signed-off line takes one symbol, picked by its lock from real Egyptian hieroglyphs: a hand, a reed, a mouth, water, a house; a falcon or an owl seals each ring. They have no modern meaning; therefore ambiguity cannot be injected via the code projection. A symbol that pictured its function — a car for drive() — would invite a reading of its own, and the build could satisfy the picture instead of the line. A dead script carries nothing but the lock it was drawn from, and the same lock always draws the same symbol.
One master hash
The symbols drawn together inside their rings are the cartouche — the name ring the Egyptians drew around a king's name, here drawn around an app's intent — and the whole request is one master hash. It is signed off once, by a person watching, and frozen: edit a line after sign-off and the build no longer matches the release. The variables a user brings later (which address, which card) fill the request; they do not reopen it.
Watched while it is built
The monitor is bound to the master hash before the agent writes anything (ct_watch), and after every save it reads the code against the symbols (ct_look) — plain code, not another AI. Each symbol is sealed or it is not, and each fault names the file, the function, the lines and what to change: missing (a signed-off function is not there), template (a stub, or a constant dressed as work), skew (a step the request needs is not wired), locked (the request was edited after sign-off). The fault goes back to the agent; Cartouche never writes the fix. At residual zero, every symbol seals.
Where it sits
The Cartouche is the first of three programs that keep an AI coding agent honest. It fixes what is meant before a line is written. Closer judges each change before it lands and sends a counterfeit straight back to the agent to rewrite. CodeRadar watches the files after they are written, and finds and repairs counterfeit code that got through. Intent, then the gate, then the watch.
Where it stands
Imagined in October 2026, released 2026-11-04 as 0.2.0. The lock, the scan, the sign-off page and the live cartouche run as plain code; its self-test, nine plants (honest builds must seal, counterfeit ones must be refused) and 133 unit tests pass on Python 3.9 to 3.14. Clips are found by searching for where each line is said, or rendered and dropped in; the person checks every licence. It judges Python only, and runs on macOS first. The dictionary grows with each app. Choosing the permutations and edge cases worth filming is a judgement, and a film that misses one leaves that fork open. And live use will go off script — "whaddya need?" instead of the line that was certified — so it must snap to the nearest agreed signal, not invent one.
2 · Closer
Three actors
The signer is a person with the shell and the keys. The writer is a Claude Code session with almost nothing: Read, Grep, Glob and one MCP server — no shell, no editor, no other servers. The gate is the fixed code between them. Everything the gate learns is filed where the writer cannot read it.
Narrow the seat, not the prompt
The writer's limits are enforced, not requested. A PreToolUse hook repeats the allowlist as a second wall; a Stop hook refuses "done" until the gate's own check exits 0. The writer can only stage files inside the ticket's write set and call land. Nothing it does touches the repo until the gate says so.
The World and the claims
gc init and gc scan freeze a write-once snapshot of the repo — the World — verified by file list before anything touches it. The signer states what the change must do as claims: small sealed tests, each a dotted name the task requires, optional setup, one call and one expectation. Claims are drafted from the task's acceptance criteria by fixed tables, never by an agent; the signer fills every placeholder. No claims, no ticket. The writer never sees them.
The ticket
Minting binds the World, the claims and the write set into one ticket by their hashes. It reaches the gate down a channel the writer cannot read, so the agent cannot tune its code to the test it will face. One task, one ticket; the agent can only write through it.
Land: every check, on a copy
At land, fixed code applies the patch to a sandbox copy and runs every check: W1 the World intact, R6 the World read, G18 no smuggled caches, S1 no fake-shaped code, E1 the repo's whole suite, C1 every claim under a clock and a line budget, U1 the pre-existing functions unchanged on the same inputs. Any non-zero exit flips the governor to reject; the saved copy is restored.
S1, the shape of the lie
S1 is pure AST, scoped to the functions the ticket introduces. Its nine shape rules: stub_body, const_return, swallow, hollow_test, theatre_return, factory_none, finally_return, always_true, identity_return. Two more strike code that asks whether it is being judged — a tracer query, the test runner's name, a swapped trace hook. A claim that fails names the function and the gap: pass_through, fake_check, answer_table, fake_effect, partial or unreached; a claim the gate cannot bring to a verdict is recorded as unjudged, not struck.
Reject, rewrite, re-test
A rejected change is rolled back, the ticket struck, and the counterfeit goes straight back to the agent to rewrite under a new ticket, judged again in full. Retries are bounded: after N struck tickets on a task, set by the signer, no more are minted. An accepted change appends a hash-chained ledger row recording the kernel, pack and claims hashes it was judged by.
Checks must prove themselves
Ruling T1: a check that does not catch is trash. Every live check carries planted counterfeits that must fail and honest twins that must pass before it goes live, and a change to the pack needs the signer's yes. The release pack, v40, runs W1, R6, G18, S1, E1, C1, U1 and R10; its 51 plants each make a real land through the gate.
3 · CodeRadar
What counterfeit code is
Code that parses, passes linting and type checking, and reads as logically sound to a reviewer — while violating mathematical invariants every real implementation must satisfy. Not broken code: broken code throws. Counterfeit code runs; it just does not do what it claims. Its shapes are recognizable: identity functions that compute a result and return the input; mutation theater that builds a cleaned list and returns the original; pass-only stubs behind confident docstrings; dead computation written to look busy. Every one of them passes ast.parse, mypy, and ruff.
Why it accumulates
Agent reliability degrades along two axes at once — task difficulty and codebase size — and the failure concentrates where both dials are turned up, which is exactly where developers reach for AI help. Compounding it: no human reads at agent speed. An agent produces hundreds of lines across dozens of files in minutes; reviewing every line negates the speed advantage, skipping review means trusting output at its least trustworthy. The only resolution is validation that runs at agent speed — deterministic, local, real-time.
The four invariants
Every legitimate implementation must satisfy four conditions: inputs influence outputs (every parameter reaches a return value through the data-flow graph); computation is captured (assigned variables are read, calculated values used); iteration accumulates (loops build state, not overwrite it); functions produce (a return value or a side effect). Violating any one is sufficient proof of counterfeit. Verdicts are binary — no scores, no thresholds, no confidence percentages to adjudicate.
The mathematics
Data-flow reachability: build the directed graph of variable flow, run backward DFS from all return values — any declared parameter outside the reachable set is accepted but never influences output. Dead stores by set difference: written − read. AST structural hashing proves an if and its else are the same branch (hash equality on the dumped subtrees, line numbers ignored). Algebraic-identity and tautology checks catch padding (x + 0, x · 1) and decisions that are not decisions (x == x). A cyclomatic floor flags validators with no branches; statistical bounds (μ ± 2σ against known-good code, 2× excessive / 0.5× underuse per metric) flag functions that are mathematically unlike real implementations.
The daemons
CodeRadar runs as a supervised set of daemons over one repo, after a verified snapshot and a 21-step health check of its own engine. They rescan the live code frame by frame: an AST and circuit watch (mypy, CRC fingerprints of frozen functions), a validator running about 190 checks in ten families — every one a pure predicate on the AST, true or false — and the live proof dashboard. Detection records raw observations and never scores. File save to verdict in under five seconds, sub-second for a single edit, offline, no API, no tokens, no model drift. (The film draws them as three, ω₁ ω₂ ω₃.)
One decision, fitted on honest code
A single ranker decides which functions are counterfeit. Every rule id has a row in a 257-row disposition table: deciding, or context. A deciding id fails the function; a context id is published dimmed and never decides. The table is data, fitted on fifteen honest open-source libraries with more held out; a rule family is admitted only when it holds on at least seven of them and loses none of its planted counterfeits. Unattended repair must preserve behaviour, or it is withheld with the reason shown.
One fix, not a menu
For each infraction the cheatsheet builder generates candidate repairs, ranks them against a profile learned from the repo itself (framework, naming, defensive-guard conventions), and gates them: must parse, must differ from the original, must introduce no dangerous patterns. One vetted before/after pair ships per finding. The asymmetry is by design — detection needs graph theory; the repair is almost always simple, because counterfeit code fails by omitting something straightforward. Cross-file forensics trace blame through the import graph to a natural wall — logical, permission, or cyclic — and a layered-error peeler chains compatible fixes when one repair uncovers the next.
Zeroed mirrors, live supervision
Every validation cycle writes .noai_state.json mirrors to every directory: findings, recommended order, and the before/after for each repair. In the full configuration four coordinated agents watch the mirrors, apply the fixes, run the tests, and resume building only when the mirrors read zero — provable clean state, not a feeling. Above it all, the live circuit graph makes agent damage visible in seconds: the documented save was an agent severing every import from an __init__ mid-“fix” — nodes went red, the developer interrupted at that exact moment, and days of building on a broken foundation never happened.
Related in the lab
- IMAXING Latent Space →
- Shares instrumentation — building the instrument that makes a hidden state legible.
- Replacing Resumes →
- Shares instrumentation — building the instrument that makes a hidden state legible.
Built at this bench
The machine, the instrument, the film that explains it — all designed and built in-house. The same bench works for hire.
Services →