Make your AI audit records self-verify offline, forever.

What an AI audit cannot prove about itself without a BitGraph

Systems that prove what an AI ran are good at what happens inside their own boundary. A signed record says what the run claims. An attested runtime says what code ran. A transparency log says what was registered, and in what order it arrived.

What none of them can give their own record is a position outside that boundary. The time inside a record is signed by the same key that would sign a backdated one. A log kept by the system under review can be regenerated in full before anyone looks. A freshness window can tell you a record looks too old; it cannot tell you whether the record’s claimed time agrees with anything outside it, and a small enough backdate passes any window.

In an AI audit, every label refers back to its issuer, the party under review: the time on a record, its place in a log the issuer keeps, the tags attached to it. A label can be changed, removed or moved to another record, and nothing shows it. The exception is a record fused with its BitGraph: the record carries its slot’s commitment and the BitGraph carries the record’s fingerprint, so changing either one breaks the pair.

BitGraph adds that one fact. The position is issued by a separate measured boundary, before the record’s fingerprint reaches it, and it cannot be moved afterwards. It is a second ordering signal from a different trust domain, not a replacement for the first.

How it fits into an audit record

The commitment goes inside the record before the record is signed, so the finished record depends on a position that existed before it.

1. Take a position. The system asks BitGraph for a slot and receives the slot’s commitment.
2. Put the commitment in the record. It is written into the record like any other field, before signing.
3. Sign the record. Only now does the record’s final fingerprint exist.
4. Commit the fingerprint to the same slot. Within two minutes, the slot is consumed and the BitGraph binds the two.

The signed record now contains a commitment to a position that existed before the record’s own fingerprint, and that position is committed by this exact record. The record could not have been finished before the slot, and it cannot be moved to another place afterwards. An agent connected over MCP does this for its own task records.

What a verifier gets

From the record and its BitGraph alone, offline:

• IntegrityThe record in hand is exactly the one that was committed. Change one byte and it no longer matches.
• PositionThe commitment inside the record points to a slot that existed before the record was signed, and the BitGraph commits this record. A commitment copied from another record fails, because its BitGraph commits a different one.
• FloorThe slot names an Ethereum block that had already been mined when the slot was allocated. The record could not have been finished before that block.
• Origin of the BitGraphThe signature verifies, and a hardware attestation ties the signing key to a published, reproducible enclave image the verifier chooses to accept.

Three answers, not two

A record that carries a commitment has one of three results, in the verifier’s own words. Valid when the BitGraph checks out and commits this record. Invalid when a BitGraph is present and contradicts the record. Unverifiable when there is no BitGraph to check. Missing evidence is never read as tampering, and tampering is never read as missing evidence.

Verification runs in an open verifier, @mikeargento/bitgraph-verify, with no network call. The verification page lists every check and what each result means.

One run, read as a receipt

An agent writes a trust record for each task it runs. Before it signs the record it takes a BitGraph position and writes the commitment into the record; once the record is signed, it commits the fingerprint. Illustrative values below, in the shape of a real BitGraph.

More cases, each with the existing record, the verification problem, and what a BitGraph adds, on the use cases page.

Underneath: one position, used once

BitGraph allocates an unused position before it receives a record’s SHA-256 fingerprint. It then binds the fingerprint to that position and marks it consumed. Unused first, consumed second: the place is fixed before the fingerprint is bound to it.

Five things, five words

Every claim on this site is made with these, and each has one name here: what stays on your machine, what crosses to the enclave, what exists there before it arrives, the step that binds the two, and what you keep afterward.

The record

Any file: a trust record, a log, an evaluation result, a model output. BitGraph never receives it.

The fingerprint

The record’s SHA-256 digest, 32 bytes. The only thing about the record that is sent. Change one byte and the fingerprint changes.

The position

A place in a signed sequence, allocated by the enclave before it has received any fingerprint. The protocol calls an allocated position a slot.

The commit

The single step that binds the fingerprint to the slot, consumes the slot, and signs the result. A slot can be consumed once, and never reused.

The BitGraph

Also called the proof: the signed result of that commit, returned to whoever asked. It carries the signed slot, both counters, the signature, a hardware attestation and the floor.

A database can also mark a row unused and then consumed. What makes this evidence rather than bookkeeping is who enforces it and what they leave behind. The allocation and the commit both run inside a measured AWS Nitro enclave whose code identity (a hash of the enclave image, called PCR0) is public and reproducible. The slot is signed at allocation, so it provably contains no fingerprint. The commit signature covers a hash of that signed slot, so the slot cannot be swapped afterwards. And every BitGraph carries a hardware attestation that ties the signing key to that enclave image.

At a cadence the operator sets, as often as once per Ethereum block, the same enclave makes a BitGraph of the hash of a recent block. Those positions are called anchors. A block hash cannot be known before its block is mined, so an anchor, and everything the sequence placed after it, came after that block. Nothing is written to Ethereum; it is read, as a public clock that no party to a dispute controls. The anchor after a position is its ceiling in the sequence: a place, not a time.

What it leaves unproven

• TruthA record can be wrong in exactly the form it was committed.
• BehaviorIt does not show that the model or agent did what the record says. That stays with whatever attests the run.
• AuthorshipThe BitGraph names the enclave that committed the fingerprint, not the system or person that wrote the record.
• CompletenessA record that was never made leaves no trace, and an unused slot can be abandoned. BitGraph shows the order of what was committed, not that everything was.
• Exact timeThe floor is a time; the ceiling is a position. There is no wall-clock upper bound, and no field in a BitGraph is a trusted timestamp.
• A replacement for witnessesIt adds an ordering signal from a separate trust domain. It does not replace transparency logs, witnesses or the attestation of the run itself.

The full list, with the reasoning, is on the limits page. The assumptions and failure modes are on the trust model.

Where to go next

• How it worksThe full explanation: the slot, fused records, anchors and time, epochs.
• Integration guidePut a commitment in a record, sign it, commit its fingerprint. SDK, CLI and two HTTP calls.
• MCP serverConnect an agent with one URL. It takes a position before a task and commits its record after.
• VerificationEvery check a verifier runs, and what each result means.
• Make a BitGraphDrop any file in your browser. Only its fingerprint leaves your machine, and the BitGraph comes back to you.
• Use casesAgent records, evaluations, regulated decisions, and records that cross organizations.
• Trust modelWhat is assumed, what is enforced, what is detected, and what is not.
• ContactMichael Argento built BitGraph. Licensing, evaluation and questions go here.