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
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 readsverified, 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 arole, 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 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
receivedeliberately 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 verdict means
What a verified pack proves, and what it does not.
The trust boundary
Why your counterparty does not have to trust Sanning, or you.