You were handed a backup. Here is how to read it without us.
You were not in the room when the agent ran. You did not pick the tools, you did not see the prompts, and the person who handed you this file would like it read kindly. Whether you price the risk, audit the work or argue about it in front of a judge, your question is the same one: what did this agent actually do, and has anyone edited the story since. You don't have to take my word for it — every check below runs on your own machine, and the first ones need nothing from us at all.
1. What arrives
One archive, named by the sha256 of its own bytes (<sha>.tar.gz). Inside it:
- The tape slice — the append-only rows the agent's session wrote, in order, each carrying the hash of the row before it.
- The signed cards — one per action: where that action landed against the lane declared before it ran, with an ed25519 attestation line over the exact bytes.
- The notary countersignatures — a second signature, by a key that is not the agent's and not the sender's, over each row the notary witnessed.
- The Merkle/MMR inclusion proofs — for each witnessed row, the path from its hash to the notary's log head, so a row that was dropped or swapped shows up as a proof that does not close.
The name is the first check. If this prints the file's own name, not a byte changed in transit:
shasum -a 256 <sha>.tar.gz
2. Recompute it yourself — free, no call to us
The measurement is free and open-source (MIT); only the underwriting is paid. Recomputing a card is the measurement, so it is free and it never touches our servers. Install the open-source tool from npm, or build the same binary from the crate:
intentguard --card --text "<the action text from the tape row>"Same text in, same bytes out, on any machine: compare the output with the card in the archive (everything above its attestation line). A card that does not match was not produced from that text.
intentguard --verify-receipt <signed-card-file>Re-hashes the signed bytes and checks the attestation line. Exit 0 means it verifies; the output names the public key it verified under — compare that key with the published one in section 4, never with a key the sender gave you.
3. Ask the notary's copy — paid, debited to whoever asks
The sender's archive is theirs. The notary keeps its own witnessed copy, and you can ask it directly with POST /api/notary/query. Every query is one action, debited from the licence of the key that signed the query — the person asking, never the sender who owns the receipt. At zero credits the answer is 402 with the price, and nothing is looked up. The body is { op, car_sha | spec_hash, at, nonce, caller: { pubkey, sig } }, signed by a key registered to your licence. Four ops, and only four:
retrieve— the witnessed entry for one archive and the notary's signed receipt for it.list— every entry witnessed under one declared spec, with the countersigned receipts and, per agent, the gaps in its sequence counted.proof— the Merkle/MMR inclusion proof for one entry against the notary's current head.export— everything needed to recompute offline, per record: the entry, the signed text, the receipt and its inclusion proof.
curl -X POST https://thetadriven.com/api/notary/query -H 'content-type: application/json' -d '{"op":"proof","car_sha":"<sha>","at":"<iso time>","nonce":"<random>","caller":{"pubkey":"<your key>","sig":"<ed25519 over the query>"}}'Recomputing what comes back is free again: a receipt checked from its inputs is never an op here or anywhere.
4. Where the keys are
The card signing key and the notary countersign key are published at one address, derived from the signers' seeds at request time, never a hand-copied constant:
curl https://thetadriven.com/.well-known/intentguard-keys.jsonPin the key you read there. A card that verifies under any other key was signed by someone else.
5. Custody: where it lives, who holds which key, what fails and how
If you allocate capital against an AI deployment, these are the questions your diligence analyst asks first. Each answer is what the code does today; an answer that is still open is named open.
- What is stored. The archive exactly as the holder's machine wrote it, and one receipt: its sha256, its size, the account, the time it arrived, and where it sits. The manifest beside the archive lists every file inside with its own sha256; that list is the answer to what left the machine.
- Where. One object in a managed storage bucket (Supabase Storage, which encrypts at rest), stored under the holder's account and the archive's own name. It is written once: a second upload of the same name returns the first receipt, and the first copy stands.
- Encryption. The archive travels over HTTPS and is encrypted at rest by the storage provider. We add no client-side encryption layer today, so we can read what is stored. Read the manifest before you press the button.
- Who can read the raw bytes. The signed-in holder, and a carrier the holder grants: one archive, an expiry, revocable, and every carrier read written back onto the holder's record as a row. Anyone else is refused with a 403. A shared link (on by default, one control turns it off) shows the per-task curve, the money, the vega and the panels from this backup, under a pseudonym; it never shows your name, your email, your prompts or your source code.
- Who holds which key. The holder's signing key is made and kept on the holder's machine and is never uploaded. The licence key sits in the editor's secret store. The notary's countersign key is held by ThetaDriven, and its public half is published at the address in section 4.
- Restore. The original stays on the holder's disk in .thetacog/backup/; the stored copy is the second one. The holder downloads it signed in, and the restore check is the name check in section 1: bytes that hash to the name are the bytes that were uploaded.
- Retention. Open, and named open: no retention period and no rule for a lapsed licence is published yet. Today nothing is deleted, because no door deletes a stored archive. The period and the lapse rule will be written here before any carrier is asked to rely on one.
The failure modes, each with what happens:
- A file that does not hash to its name is refused, and nothing is kept.
- An archive over 200 MB is refused with its size, never truncated.
- A store that does not answer shows on every page as UNMEASURED with its reason, never as a zero.
- Rows written before the first countersigned row were never witnessed. A gap after it is counted.
- If ThetaDriven stops answering: the archive on the holder's disk, the open-source recompute in section 2 and the key you pinned in section 4 still work. The paid query to the notary's copy in section 3 does not.
An archive is made by pressing 🔗 Countersign (backup) in the ThetaCog extension's sidebar.
6. What this is sufficient for, and what it is not
Sufficient for: the rows were not edited after the notary countersigned them, and each placement was computed from a record the agent did not author. NOT sufficient for: that the work was good (Rice) or that the log is complete before the first countersigned row.
Whether the work was good is undecidable (Rice, 1953), and we do not claim it. Rows written before the first countersigned row were never witnessed; a gap after it is counted, never silence.
Uploading a backup: /backup · what a licence costs: /pricing
See how large one piece of agent work gets, with and without a scope declared before it starts, on the default curve.