# How it works

Your agent signs each decision, the service co-signs it and gives it a public timestamp, and anyone can check the result with the open verifier. The content stays with you.

The full contract is in the [API reference](/docs/api). The [concepts page](/docs/concepts) explains it in order, and [Verify](/docs/verify) says what each check means. Plans and limits are on the [pricing page](/pricing).

## One record on a time line

- **Your agent calls a tool.** The call is recorded before the tool runs. Only a salted hash of the content leaves your systems.
- **The record is signed twice and bounded in time.** Signed by the agent with its own key, which never leaves your machine, and co-signed by signafAIde, so neither you nor the service can change it alone. Not before a public randomness round, not after the hourly public timestamp.
- **An auditor checks it.** With the open verifier, `signafaide verify`, and the public services. Not the service's word.

## Where each part happens

### Your systems

Where your agent runs.

- The SDK wraps the tools that act
- Each record is signed with the agent's own key
- Records and content stay in `.signafaide/`

### signafAIde

The service.

- Co-signs each batch and the agent's latest record
- Adds a public randomness round: not before
- Adds an hourly public timestamp: not after

### Anyone

You, your auditor, a regulator.

- Gets one verification pack
- Runs `signafaide verify` with the open verifier
- Sees which checks passed and which could not run

## The four steps

They run in the background. Nothing waits for the network unless you turn on strict mode.

1. **The agent signs.** Each call of a wrapped tool writes a `decision` record before the tool runs and an `outcome` after it. Both are signed with the agent's key and chained to the record before.
2. **Only hashes travel.** The service receives the envelope: the tool name, the time, the chain links and a salted hash of the content. Inputs and outputs, and the salt, stay with you unless you choose to store them, so the service cannot work out the content from the hash.
3. **The service co-signs and timestamps.** It signs each batch and the agent's latest record, notes a public randomness round, and adds the batch to the next hourly public timestamp.
4. **Anyone can check.** `signafaide verify` checks every signature, chain link, receipt and timestamp, and says how many of its 12 checks passed; a check still waiting (a public timestamp confirms within a few hours) is shown as pending, never as passed. Most run offline; the public timestamp check needs a network lookup or a saved block header. An auditor relies on the open verifier code and the public drand and timestamp services, not on your word or ours.

## Records written offline

An agent that is offline, or that has not opted in yet, keeps signing and chaining records on its machine. They are sent when it can reach the service, with the time the agent wrote them. The service accepts records up to 7 days old, and never a record dated more than 5 minutes after it receives it.

Such a record has two times. The claimed time is the agent's own clock, signed into the record. The proven window starts at the randomness round of the batch it was sent in and ends at the public timestamp. For a record sent late the claimed time is earlier than the window, and the console, the auditor view and audit packs show both, with the note "written offline, sent later".

The 7 days are also a backdating window. Whoever holds an agent's key, and the operator of the witness, can make a record claim a time up to 7 days before the service first saw it. That is why the evidence is the proven window, not the claimed time: the record cannot have been written before its batch's randomness round or after its public timestamp, whatever it claims.

## Compared with a log you write yourself

A log you control proves nothing to a third party, because you could have edited it.

| | Your own log | A signafAIde record |
|---|---|---|
| Signed by | nobody | the agent's key and the service's key |
| Edited later | leaves no trace | breaks the signatures and the chain |
| A record removed | leaves no trace | leaves a visible gap in the chain |
| Earliest time | what the clock said | after a public randomness round |
| Latest time | what the clock said | fixed by a public timestamp |
| Checked by | the people who wrote it | anyone, with the open verifier |

## Why not WORM storage and our SIEM?

Write-once storage, such as S3 Object Lock, does one thing well: once written, an object cannot be changed or deleted before its retention date, even by an administrator. A SIEM is good at collecting events and alerting on them. Both are worth having.

Neither proves anything to a third party. The bucket and the SIEM are yours, so an auditor has to take your word for what went in: a record you never wrote, or wrote late with an earlier date, or left out, looks the same as a complete log. signafAIde adds three things a store you control cannot: an independent co-signature on each record, public time bounds (not before a public randomness round, not after a public timestamp), and a completeness check on each agent's chain against the newest head the service signed. You can keep writing to your WORM store and SIEM as well; the records verify the same.

Next: what this gives an auditor. [Auditors and compliance](/auditors)