Use cases

Not every record needs a position. The records someone may later dispute do. Each case below names the record that already exists, what a reader cannot check about it today, where BitGraph enters the workflow, and what the proof adds and does not add. BitGraph sits beneath the receipt, the log and the signature; it does not replace them.

An AI agent's record of its own work

The record: The task record: what the agent was asked to do, the inputs it used, the tool calls it made, and what it produced. It is written by the agent's own harness and kept by the same party.
The problem: Whatever the record says about its own time and order is that party's claim. A log kept by the system under review can be regenerated in full before anyone looks at it, and a timestamp inside it is signed by the same key that would sign a forgery.
Where BitGraph enters: Before the task starts, the agent asks BitGraph for a position and receives its position commitment. It writes that commitment into the task record and commits the record's digest under the same position. Outputs are recorded as they are produced, each at a later position. Both MCP servers implement this pattern; nothing about the task leaves the machine except digests.
What the proof adds: The task record could not have been finished before its position was allocated, and its proof names a public Base block that the enclave bound into the position when it opened. Every output sits at a later position in the same sequence. A reviewer checks the order from the files and the proofs alone, offline, with no access to the agent's infrastructure.
What it does not: That the agent did what the record says, that the outputs are correct, or which model produced them. Those stay with whatever evidence the harness signs.

Connect an agent over MCP

An evaluation that must postdate a public moment

The record: A question paper and an answer sheet. The claim that matters is that the questions were not in the model's training data.
The problem: Today that claim is a promise about a process: the set was kept private, or written after a cutoff, or held out by the party running the test. A buyer comparing a vendor's score with an evaluator's can settle it only by being handed the test, which destroys it for everyone afterward.
Where BitGraph enters: The paper is derived from the commitment of a freshly allocated position, whose proof names a public Base block bound in when the position opened, and is committed under that position. The answers are recorded later, at a later position. The derivation is specified so anyone can repeat it.
What the proof adds: The questions could not have existed before the block their proof names as the floor, so no corpus frozen before it can contain them. The answers provably follow the paper. Vendor, evaluator and buyer verify both from a folder, offline, without revealing the paper to each other.
What it does not: That the template families were unfamiliar to the model, that it worked unaided, or how long it took. The answer sheet has a floor, not a ceiling.

Automated decisions in regulated finance

The record: A decision record, a receipt, a model output or a compliance result, produced by the institution's own systems and retained under rules such as MiFID II, SEC Rule 17a-4 or DORA.
The problem: A signed record shows what decision was made. The auditor or counterparty who relies on it still trusts the institution's infrastructure for the ordering and the history, and that is the party whose conduct is in question.
Where BitGraph enters: Each record, or each day's records as one set, is committed as it is produced. The record stays inside the institution; only its digest is sent.
What the proof adds: Independent evidence that this exact record occupied this position, after a public block, and was not inserted later into a more convenient place. The proof is checked outside the institution, and it supplements the retained record rather than replacing it.
What it does not: That the decision was correct or lawful. The record-keeping obligation itself is met by the institution's system; the proof is evidence about it, not compliance with it.

Clinical decision support and change control

The record: A decision record, a model manifest, an authorization, or a change-control artifact for AI-enabled software. HIPAA's audit-control and integrity requirements and change-control expectations all assume a decision can be reconstructed later.
The problem: Reconstruction may be needed years later, and ordinary logging, however strong, stays under the control of the organization whose history is being audited.
Where BitGraph enters: Manifests and decision records are committed as they change. Patient data is never sent; a digest reveals nothing about the record's contents unless someone already holds the exact bytes.
What the proof adds: Independent evidence of the order between exact digital states: which manifest was in force before which decision, and after which public block.
What it does not: That the decision was clinically right, or who made it. Note the privacy exposures below before recording low-entropy records.

Government and sovereign environments

The record: An administrative decision record, a policy analysis, or an evidence artifact that must stay inside a jurisdiction and may be challenged after the vendor contract behind it has ended.
The problem: The auditor may not trust, or may not be able to reach, the vendor or cloud service that produced the record. The check may have to run offline.
Where BitGraph enters: The system keeps its own signed evidence and commits a digest. The artifact never leaves the secure environment.
What the proof adds: A proof that verifies offline, years later, with no call to the vendor or to BitGraph. The one external reference, a public Base block, is checkable with one lookup on Base.
What it does not: Anything about the content. And the trust root is AWS Nitro hardware and a published enclave image, which some sovereign settings will want to run themselves; the self-hosting guide covers that.

Run your own enclave

Records that cross organizations

The record: Company A signs a delegation; company B signs an execution receipt. Each may attest the hardware that ran its side.
The problem: Neither record can show where the two stood relative to each other, and the ordering evidence lives inside one company's infrastructure, which is exactly what the other does not want to trust.
Where BitGraph enters: Each delegation, receipt or manifest is committed by whoever produces it, on the same public sequence.
What the proof adds: A shared coordinate system: either party, or a third-party reviewer, checks the other's evidence and its order without trusting the other's database. The proof travels with the record.
What it does not: Whether the delegation was proper or the action correct. Those stay with the systems that signed them.

Other records with the same shape

The property is the same wherever exact bytes have to be defended later by whoever holds them.

Photography and photojournalism: which version the photographer delivered, fixed at a position beside Content Credentials rather than in place of them.
Periodic reports and attestations: each report takes the next position as it is issued, and a rewritten report no longer matches the position the original held.
Evidence and chain of custody: which file existed before which, with no clock to dispute.
Issued documents and credentials: a holder presents the document with its proof, and the position is checked without a call to the issuer.
Instrument and field data: an order that someone who was not present can check; against an expectation of what should be there, a gap becomes visible.
Construction and site records: a photo or daily report made on the day holds a position from that day, before any dispute exists.
Drafts, designs and prior art: revisions take later positions, so the development history itself becomes evidence.

Before adopting it in a regulated setting

Read this first

A proof holds a record’s fingerprint, never its contents, and the protocol has no ledger. BitGraph currently keeps a copy of each proof: this site looks them up by fingerprint. The copy is a convenience for the site, separate from the protocol, and could stop at any time without affecting any proof. It carries two exposures. Copies already kept cannot be deleted for ten years, by anyone, including BitGraph. And while the site shows them, anyone who can guess a record’s exact bytes can confirm it was recorded; that matters for low-entropy records, such as a short form from a known template. The record itself never leaves your systems.

The evidence is the proof itself, a small JSON file that comes back to you. Keep it beside the record or in any database, public or private. Anyone holding the record and the proof can check them together, offline, without contacting BitGraph; the verifier never consults the copy. The trust model lists the exposures in full.

Where next

Make a BitGraphDrop any file in your browser. The file never leaves your machine, and the proof comes back to you.
Integration guideRecord from your own systems: SDK, CLI, or two HTTP calls.
MCP serverConnect an agent with one URL.
ContactLicensing and evaluation, with Michael Argento.