> ## Documentation Index > Fetch the complete documentation index at: https://docs.sanning.io/llms.txt > Use this file to discover all available pages before exploring further. # What a hand-off record does not prove > Integrity, not accuracy; attribution, not independence; a record, not a control; ambiguity and unclaimed records; and the wait for independent time A verified hand-off is a narrow statement: the message the second agent recorded is the message the first agent recorded, and each side was signed by the key it names. This page states what that statement does not reach. Say it to whoever relies on your evidence, before they read more into it. ## Integrity, not accuracy A record proves what was recorded, not that it was true. If an assessing agent recommends approval and a reviewing agent receives that recommendation, a verified pair shows the reviewer recorded exactly the bytes the assessor sent. It does not show the reviewer acted on them, or accepted them. Pairing grades whether the two sides commit to the same message, and never what the receiver did with it. `outcome` on a `handoff.received` record says what the receiving agent claims it did (`accepted`, `rejected` or `failed`), and pairing does not read that field: a received record carrying `outcome: "rejected"` pairs exactly as `verified` / `verified` as one carrying `"accepted"`. A verified pair over a rejected received record still says only that the reviewer's record matches the assessor's; it says nothing about whether the reviewer acted on the recommendation, whether the recommendation was right, whether the data behind it was correct, or whether the model was fit for the task. Those are conclusions for the people reviewing the work. Sanning is content-blind: it holds commitments, never the content, so it cannot vouch for the content either. ## Attribution, not independence between organizations A pair across two organizations proves that two keys each signed their own side. It does not prove that two independent parties hold those keys. Pairing matches on keys and hashes and never on which account a record came from, so a pair verifies across packs from two organizations. The kernel flags one key signing both sides of a hand-off. It cannot tell two keys held by one party from two keys held by two, because binding a key to an organization happens outside the evidence. An agent's identity informs a reader and never decides whether evidence verifies. If independence matters to your review, establish who holds each key by other means. ## A record, not a control Sanning records what agents did, and lets anyone check the record later. It does not approve, block or enforce what an agent may do, and a verified record of a decision is not evidence that the decision was permitted. `receive` refuses when a record does not verify, or when the message that arrived is not the one the sender committed to: see [What receive checks, and what it refuses](/guides/handoff#what-receive-checks-and-what-it-refuses) for the full list. Every one of those is an integrity check, not a policy one. Whether an agent is allowed to send a message, or to act on one, is decided by your own systems, never by `receive`. ## More than one message in one direction Pairing looks for a signed counterpart by key and by record type. It does not look at case, at sequence, or at which message a sent or received record names to narrow that search. When the other side holds more than one record that could be a counterpart (two messages in the same direction, fan-in, fan-out, or the same pair of records appearing again in another case), the reader grades every one of those candidates and reports the worst, unless a candidate is already accounted for. A candidate that another record already accounts for, as a mutually named pair with the same message and the same sequence, is set aside before the reader grades. An honest exchange of several messages in one direction then reads `verified`, rather than `failed` on `message_hash` and `sequence` with the finding `counterpart_ambiguous`, which is what an unaccounted-for candidate still reads as. You can tell that apart from a genuine tamper by reading the candidates themselves: one of them reads `verified`, and the rest are the exchange's other honest messages, not a decoy planted beside a broken pair. A formed pair also has to name each other: the sent record names the received record's signer, and the received record names the sender's. An honest record can fail that check, `counterparty_named`, when its counterparty signed a second record of the same message at the same sequence, for example one message sent to two recipients. ## Step records declared under the wrong role A pack's declaration marks every record it holds with a `role`, `handoff` or `step` (`sanning.declaration/v2`). A record declared `handoff` must be claimed in the declaration's hand-off sides; a record declared `step`, such as a closing record or an ordinary log line, must not be, and sits outside the hand-off scope test entirely. A record signed under the wrong role, or claimed under the wrong role, is named rather than read past, so a case holding one does not read `verified`. Within its own role, a step record's content can still be withheld on purpose without moving the verdict. A `sanning.declaration/v1` pack carries no `role` field. Its declared records that no pair claims are named the same way, and a pack with no declaration at all is named as one that does not say what it holds. The check cannot take the audited party's own word for which of its records are hand-off sides, so an unclaimed one is always named rather than assumed innocent. ## The wait for independent time A record is witnessed only once its interval is stamped. Until then, the only time on a record is the time the agent signed into it, which is the agent's own claim. When a receiver checks a hand-off on arrival, it checks the sender's signature and the message, offline, in the moment; it does not check when the record was made. Independent time arrives when the interval holding the record closes and its stamp is published on the public record, minutes later rather than seconds. [The witness](/concepts/witness) explains the interval and how long the wait is. ## What a receiver cannot check on arrival Three questions stay open at the moment a message arrives, and each has a different answer later: * **Whether the sender's key is enrolled and not revoked.** That is a roster question, and `receive` deliberately does not ask it. Weigh it on your own terms after the record verifies. * **When the record was made.** Independent time comes with the stamp, as the previous section describes. * **Whether anything was left out.** A pack's signed declaration says what its holder claims the pack holds, and a reader checks the pack against that claim. Nothing proves a party showed you every exchange there was. ## Next What a verified pack proves, and what it does not. Why your counterparty does not have to trust Sanning, or you.