Skip to main content

The model is never asked whether its own edit worked.

Every rival ships an AI that writes code. The difference here is that each diff carries a receipt a third party can verify offline, the run itself can be refused, and the same loop runs air-gapped.

What a developer touches

Three consoles, and they are the same components in a workspace and in a clean room, the clean-room host passes the room’s scope and drops no capability. Submit a governed task against a connected repository, pick the crew formation, autonomy mode, model and budget, and watch the run.

Inside a run, four panels carry what matters to a reviewer: a live run watch streamed as it happens, a diff-provenance view of the signed receipts, a findings view of what the pre-commit scan surfaced, and the run’s project memory.

This is not an IDE. There is no hosted code editor, no language-server integration and no editor extension. It is a surface for submitting, watching and reviewing governed runs against a connected repository, which is a different product from an AI pair-programmer in someone’s laptop. If your question is “can my engineers use this in VS Code?”, the answer is no.

Coding · Run detail, diff provenanceillustrative
api/handlers/export.pyverified
guard addedreceipt a1c4…f209prev …8b31signer: coding-agent@node
api/handlers/export.pyverified
test addedreceipt a1c4…f5aaprev …f209signer: coding-agent@node
core/policy/egress.pyverified
predicate compiledreceipt a1c4…9d17prev …f5aasigner: coding-agent@node

chain intact · 3 receipts · Ed25519

Coding · Run detail, diff provenance. Each applied change carries a signed receipt whose hash folds in the previous one, so the whole run is a chain a third party verifies offline. The agent never asks the model whether its own edit worked, the suite and the typechecker do. Representative product UI with illustrative data, not a customer deployment.

Six phases, and the interesting property is what is not trusted

01

Provision

Clone the bound repository into a fresh per-run workspace root. A clone that fails, fails the run with the real error, no bootstrap and no repair is attempted over a tree that was never checked out.

02

Bootstrap

A fresh checkout has source and nothing else, and a suite run against it fails on missing imports while a repair loop burns its budget chasing a phantom. So dependencies install once, before the first verify, language and package manager detected across seven language families, with a monorepo walk that reports each sub-project separately. The sandbox has no default route, so the install runs inside one bounded egress window whose registry host the broker authorises. After that window the network is sealed.

03

Navigate

Three retrieval surfaces, deliberately layered. A symbol map so the agent navigates without re-reading whole files, cached on file content hash so an edit cannot serve stale symbols, and a language outside the supported set is omitted from the map rather than faked. Regex search, root-confined, run inside the sandbox. And semantic retrieval over a compartment-scoped vector space, so code retrieval physically cannot reach another workspace's code.

04

Edit

Two surgical primitives instead of whole-file overwrite: a replace that refuses a target which is absent or ambiguous rather than editing the wrong site, and a diff applier that verifies every context and removed line and refuses a patch against drifted content. Both compute the new content in one pass and write once, so a failed edit leaves the original byte-for-byte untouched. Multi-file work that only makes sense together runs as an atomic changeset, snapshot every target, apply, and on any failure restore every snapshot.

05

Verify

The loop reads the compiler and the test suite, not the model's opinion of its own work. Test frameworks are auto-detected from marker files and each parser reads that framework's real console shape into a structured verdict, exercised on both a passing and a failing run. A framework outside the matrix is an explicit unsupported error, never faked as passed. Diagnostics run in machine-readable modes, so a broken build cannot be mis-read as clean.

06

Repair

Each iteration edits, then verifies. Clean diagnostics and a green suite is success, both are required, and a run with clean diagnostics but a failing suite is not success. Otherwise the structured failures are fed back and the loop continues, ending in exactly three states: succeeded, failed carrying the last real failures, or halted by the gate before the next iteration's budget is spent.

8

test frameworks read into a structured verdict, each parser exercised on both a passing and a failing run

7

diagnostics tools in machine-readable modes, so correctness is derived from parsed output rather than from an exit code or a summary line

Every applied diff produces a signed, chained receipt

The receipt records who, what, why and as-of-when, with the diff’s hash, a link to the previous receipt’s hash, and a real detached signature over the canonical receipt bytes, the same primitive that seals the metering audit chain, not a hash pretending to be a signature.

Verification is stateless and offline. A third party needs the receipt, the diff text and the signer’s public key. No database, no service, no account. A changed diff or any changed metadata field is rejected, and receipts are chained per run, so removing one is detectable.

A diff, and the receipt that outlives it. Nothing connects the two halves of this figure, and that is the point: verification needs the receipt, the diff and a public key, not a running System9.
A diff, and the receipt that outlives it, Nothing connects the two halves of this figure, and that is the point: verification needs the receipt, the diff and a public key, not a running System9.
ElementWhat it does
ChangesetMulti-file work that only makes sense together is applied atomically: snapshot every target, apply, and on any failure restore every snapshot.
ReceiptRecords who, what, why and as-of-when, with the diff's hash and a real detached signature over the canonical receipt bytes, the same primitive that seals the metering audit chain.
The chainEach receipt links to the previous one's hash, per run, so removing one is detectable.
What a verifier needsThe receipt, the diff text and the signer's public key. No database, no service, no account.
What fails verificationA changed diff, or any changed metadata field.

And nothing commits until it is scanned

A pre-commit assurance gate runs in-sandbox over the pending changeset, composing the platform’s existing security primitives rather than reinventing them: the credential detectors plus an entropy detector for high-entropy tokens; a real static analyser over a covered rule set, which reports a changed file in an uncovered language as unsupported rather than faking it clean; and licence checking with a software-bill-of-materials fragment emitted for every touched dependency.

The gate is fail-closed. Any secret, any medium or high finding, any disallowed licence blocks the commit. A clean scan writes nothing, so the findings ledger never carries a fabricated finding.

Write authority is graded

Status, diff, log and branches are read-safe. Create-branch, checkout, commit and open-pull-request are consequential and permission-gated. The two genuinely destructive operations require both an operator capability set at construction (unreachable from tool arguments) and an explicit per-call flag.

The strongest guard is non-exposure

Force-push, rebase, amend and history rewriting are not exposed as tools at all. The most reliable protection against an agent rewriting an audit trail is that the capability does not exist in its hands.

A run is governed as a unit

A run-level governor evaluates the aggregate (value delivered against tokens, wall-clock, fan-out and churn) and a net-negative run is halted and marked requeue-recommended, because a sustained breach owes a recovery path rather than merely an alarm.

Crews are authorised once, then bounded

A formation compiles to seats, each equipped with exactly its role's tool ceiling. A scout or verifier seat without write authority cannot apply a patch. Each seat's credential is minted as the intersection of what was requested and what the parent holds.

The same loop, on a device that has never touched the internet

This is the part with no commodity equivalent. The Edge Agent carries the coding surface, patch application, code search, test running and the version-control family, dispatched first in the on-device tool set. A local model reasons on the device, the tools plan, edit, search, test and commit, and not a byte leaves.

It is a behavioural mirror of the core, not a reduced sibling: the same unique-match replace, the same hunk-verified diff applier, the same root confinement rejecting traversal and absolute paths, and the same framework matrix parsed into a structured verdict.

Its confinement is tighter than a shell, never looser. Every process runs through one runaway-guarded primitive, argument vectors, never a shell, so there is no injection surface, with an inherited timeout, an output cap and a scrubbed environment. Any caller-supplied value beginning with a dash is refused, so a model cannot smuggle a force flag through a branch-name field.

In three sentences

Every code change an agent makes carries a signed, hash-chained receipt that a third party verifies offline with nothing but the receipt, the diff and a public key. Nothing commits until a fail-closed gate has scanned it for secrets, vulnerabilities and licence violations. And the identical plan, edit, test, commit loop runs on a device that has never touched the internet.

No commodity coding tool proves its edits, and none of them work with the network unplugged. That is the whole argument, and it does not require a benchmark to make.

Bring a repository and a compliance requirement

The interesting conversation is not whether an agent can write code. It is what your auditor needs to see about the code it wrote.