Read this first
Limits
Everything below is a thing AFA cannot do. Each one is also the reason a careful reader can use the record at all. Every other page in these docs assumes you have read this one.
1. Hashes, not payloads
The record is built from hashes and structural fields. The reference clients never send the text of a prompt or a tool result, and the API never reconstructs it, so we cannot show you what an agent said, only that the record of it was not altered afterwards. The API keeps whatever a client puts in raw; keep secrets out of it.
The check: Write an event whose raw carries only structural fields, then GET /v1/events/{event_id}: the response adds a payload_hash and nothing else. No route returns text a client did not send.
2. Detection, not prevention
A changed or reordered entry breaks a signature or a hash link, and the check reports where. Nothing here stops the change from being attempted. The record is tamper-evident.
The check: Edit one stored block and POST /v1/chain/verify reports block_hash_mismatch at that block index.
3. Allowed and did, not wise
The record says what an agent was allowed to do and what it did. It does not say whether the action was a good idea, or whether the policy behind it was the right policy.
The check: No field in any response carries a quality judgement. decision is allow, ask or deny; nothing grades the outcome.
4. A host must deliver the action to the gate
The gate only sees actions a connected host sends it. A broad grant permits broad behaviour, and a host that never asks is never refused.
The check: GET /v1/grants/status names the exact tools a grant allows. Compare that list with what the host actually ran.
5. Verification runs without our servers
Delegation tokens carry the order-bound public key and a binding signed by the service identity. With the published service key both checks run as plain Ed25519 on your machine.
The check: GET /v1/delegations/service-pubkey once, pin it, then run the offline verifier on the Verify page with the network off.
6. Nothing customer-facing runs offline
The API, the console and the MCP transport all need a connection to api.afaprotocol.com. Offline verification covers exported records, not live checks.
The check: With the network off, GET /v1/health fails and the console shows nothing new. The offline verifier still runs.
7. The console shows what the API knows
Panels stay empty until a connected host writes to the account. Nothing is backfilled and nothing is inferred.
The check: The console's counts match POST /v1/events/search on the same account, called with the same window.
Two words that are not interchangeable
Soundness is what these pages claim: a record was not altered after signing, an action was checked against a policy before it ran, a chain is continuous. Correctness is what they never claim: that the action was appropriate, or that the person who approved it was paying attention.