All insights
    LOG/005Jun 15, 2026Thought PiecesSAIN Industries

    Anchor'd, explained: a tamper-evident record for AI work

    For most of computing history, a record spoke for itself. A log said what a system did. A file said what it was. Disputes were about meaning, and rarely about whether the record was real.

    Generative AI changed that. When any document or recording can be fabricated cheaply, the authentic ones lose their default credibility too. "Here is the file" stops being an argument. The question becomes: show that this is what you say it is, and show that it has not changed since.

    Anchor'd is built to help answer that question for the work AI does. It keeps a tamper-evident audit trail of every action, approval, and draft. This piece explains what it records, how a changed record shows itself, and where we draw the line on what we claim.

    What Anchor'd records

    Each event on the record captures:

    • Who acted: an agent, an assistant, or a person
    • What they did, and to what: the action and its target
    • A fingerprint of the details
    • When it happened
    • What caused it, where that link exists, such as the request that started an agent's run

    For AI work, that means the request, the agent's draft as written, every edit, every hold, and every approval. Here is a sample of what a reviewer can do with that record.

    How a changed record shows itself

    An ordinary log can be quietly edited. Anchor'd is designed so that an edit leaves a mark.

    Each event gets a receipt. Events are grouped into batches, and their fingerprints are combined, two at a time, until one fingerprint stands for the whole batch. That batch fingerprint is what goes into SAIN's tamper-evident ledger. A receipt carries the event's fingerprint and the few others needed to rebuild the batch fingerprint, so a record can be checked against the ledger without trusting whoever is holding it. The check is designed to run offline.

    If anyone changes a record after you hold its receipt, the receipt no longer checks out. Try both cases below.

    One more point matters to anyone handling controlled information: the ledger holds fingerprints. Your prompts, responses, and documents are not written to it.

    Provenance for decisions

    The records that get challenged in the next few years will not only be documents. They will be decisions. Which agent acted. What it was given. What it produced. Who approved it, and which version they approved.

    Showing that a file is unchanged is the start. Showing that an AI decision happened the way you say it did, to a reviewer who was not there, is the goal. That is why Anchor'd records the action and the approval along with the document the action produced. Guardian's holds and the human decisions that follow go on the same record.

    What we claim, and what we do not

    We are careful here, because this is a field where overclaiming is common.

    • We say tamper-evident. A changed record shows the change when it is checked. We do not claim a record cannot be changed. We claim that a change shows.
    • Today, a check is against SAIN's ledger. It shows whether a record has changed since its fingerprint was written there. A check that needs no trust in SAIN at all, with outside parties co-signing the record, is a goal we have not reached, and we do not claim it.
    • A record is one part of an evidence process. Whether a record is accepted in a given setting depends on your controls, retention, and procedures as well as on any tool. Anchor'd gives those processes a record they can check for changes.

    Questions to ask any audit-trail tool

    Whether you are looking at Anchor'd or anything else, these questions tell you what a record is worth:

    1. What exactly is recorded? Look for the actor, the action, the target, the time, and the version approved.
    2. Is the agent's original draft kept? Without it, nobody can see where human judgment came in.
    3. How does a changed record show itself? Ask to see it demonstrated on a real record.
    4. Who can run the check, and where? Can your own team run it, and can it run without a network connection?
    5. What does the check depend on? Find out whose systems you are trusting when a record checks out.
    6. What goes into the ledger? Make sure sensitive content stays out of anything shared.
    7. What does the vendor say it cannot do yet? A clear answer is a good sign.

    Next steps

    For how this works inside a program office, read why AI in a program office needs a record. For the wider argument, read why Anchor'd matters.

    There is more on the Anchor'd page. If you need to show a reviewer what your AI did and who approved it, we are glad to start with the questions your reviewers ask.

    Talk to us.