Trust map: what each check shows
Each check answers one narrow question. A pass on one says nothing about the others. This page lists the checks behind a record of any exchange between agents, what each one shows, and what it does not show.
The checks are the same in every setting. What is at stake, and what each check is asked to cover, depends on the setting. In context, below, works through two: shared inference among strangers' machines, with the Mesh-LLM case study as the worked example, and the internet of agents. None of these checks rates an agent or a machine; each answers one question about records.
The checks
| Check | What it shows | What it does not show |
|---|---|---|
| Content binding | The record's fingerprint is recomputed from its bytes and matches the id it was sealed under. Change one byte and it no longer matches. | That what the record says is true. Who wrote it. |
| Signature | Proves the holder of a key signed this record's id. | Who holds the key, or that the party the record names did the work. For the other side's record, the key is the one they announce: their claim, not an identity anyone else vouched for. |
| Inclusion in a signed checkpoint | Proves the record sits in the log under that checkpoint's root. | That the log holds nothing else, or that anyone outside the log's operator holds the checkpoint. A count of records a checkpoint covers is only a number the log's operator reports. |
| Checkpoint signature | Proves the log's key signed that checkpoint: that root, at that size. | That the operator showed everyone the same checkpoint. Only someone outside, such as a Transparency Service that registered the checkpoint, can catch two different versions. |
| Continuity | When checked with a consistency proof, it proves each checkpoint builds on the one before, so an earlier entry was not rewritten or dropped between them. | That every action was recorded. A log can stay consistent and still leave an action out. |
| Witness receipt (a SCITT Receipt) | A Transparency Service you don't run registered your checkpoint in its own log, so a later rewrite would show to others. The Receipt proves the checkpoint is in that log, not that the service agrees with it. The service sees checkpoints, never records or text. | That the records are true, or that they are all there. It says nothing about the content of any record. |
| The other side's matching record | Both sides sealed their own record of one exchange, and the two agree: the same request and response fingerprints, and the same parties. Two signed records that disagree are a signed disagreement. | That the response is right, or that either side did what its record says. The check compares fingerprints each side states. |
| Independent observation | A party other than the two sides kept its own record of the exchange, or did the same work again, so its record can be compared with theirs. Agreement from an observer in separate custody corroborates the two sides; a disagreement is recorded as one. | That the observer is in fact independent of either side: that is a claim about who runs it. Which record is right when they disagree. Anything about an exchange no one else observed. |
What “not checked here” means
Not checked here means a view displays a state it read from somewhere else and did not verify itself. It is not a failure and not a pass. It tells you where the trust sits: with whoever reported that state.
To check a record yourself, use a verifier you choose: Verify a capsule runs the same checks in the browser, on the command line, or as a library. A view that cannot run a check should say so rather than show a pass.
In context
Two settings use the same checks for different questions. Neither is the definition of the checks; each is one place they apply.
Shared inference among strangers' machines: Mesh-LLM
In a shared-inference mesh, a machine you have never dealt with serves a model for you, and may be paid for it. The setting is adversarial: a stranger may try to game the system. Two questions matter most. Inference: did the serving machine serve what it claims, the model weights, quantisation and context it states? Payment: was the payment made, and was it received?
The checks above apply, with three pieces specific to this setting:
- Twins: the same request goes to two machines that claim the same model weights, and both answers are kept.
- An independent recompute: a referee, a third machine, can answer the same request itself and seal a verdict on the two answers. This is what independent observation means here.
- Settlement records: the payer and the payee each seal their own record of a payment (Settlement records Internet-Draft ↗), and the other side's matching record check applies to the pair. Two records that agree show that both sides record the same payment; they do not show that money moved outside the records.
If you followed a link from an evidence view, such as a node's Evidence tab in the Mesh-LLM case study, this table is the key to it. In this setting adds what each check covers here. The In the Mesh-LLM view column says where that view gets each answer: a check it runs on your machine, or a state it only reads and marks not checked here. The view's rows cover inference; settlement records are not among them.
| Check | In this setting | In the Mesh-LLM view |
|---|---|---|
| Content binding | As in the general table. | Checked on this machine, for your records and for theirs. |
| Signature | The party a record names is a serving machine. A signature does not show that the named machine did the work. | Checked on this machine, or by your node when their record arrives. |
| Inclusion in a signed checkpoint | Each node keeps its own log. A count of records a checkpoint covers is only a number the node reports. | Checked by your node for their record before it keeps a citation. For your own records, the view shows the node's coverage count. |
| Checkpoint signature | As in the general table. | Checked by your node, under the key on their record, together with inclusion. |
| Continuity | As in the general table. | Not checked here. The view reads the node's status. |
| Witness receipt | As in the general table. | Not checked here. The view reads whether a receipt exists; it does not check the receipt, or the witnesses a checkpoint lists. |
| The other side's matching record | The two records also agree on the same serving machine and the same model weights fingerprint. That does not show that the weights named are the ones that ran; the check compares fingerprints each side states. A model name alone never counts as a match. | Checked on this machine. The view marks the serving-machine comparison as provisional. |
| Independent observation: twin plus referee | The same request went to two machines and both answers were kept, with the settings each was asked to use, so they can be compared side by side. A referee can compare the two and seal a verdict. It does not show which answer is right. A verdict that is not signed is a statement, not something you can check. | The two answers are shown side by side. Verdicts: not checked here. |
In the Mesh-LLM view, these are read and not checked:
- witness receipts, and the witnesses a checkpoint lists;
- continuity;
- twin verdicts;
- the link between a node and its owner, which the node reports about itself;
- peer names, which each peer chooses.
The threat model behind the Mesh-LLM checks is in A trust model for strangers on a mesh ↗.
The internet of agents
Agents acting for different people and organisations work with each other: one asks, another acts, and either may hand work on. The checks are similar; the details differ. The questions here are not about inference or payment. They are: did each agent do what its record says, under the authority its record claims, and do both sides' records of the exchange agree?
- Did what it said. Content binding, signature and inclusion show that a record is the one its producer sealed and logged. They do not show that the record is true; the other side's record is the cross-check.
- Under the authority it claimed. A record can cite the authorization grant or policy decision it ran under, by digest (How it composes). A verifier checks that the digest matches the grant it is shown. Whether the grant was valid, and whether the action stayed within it, are questions for the authorization layer; the record does not answer them.
- Both sides agree. The other side's matching record: each agent seals its own record of the exchange (Bilateral attestation Internet-Draft ↗), and the two are compared.
- Independent observation. Here it means more observers, not a recompute: a party that sees the exchange from outside either agent, such as a network boundary or the endpoint an agent called, keeps its own record. There is no twin here, and nothing is recomputed.
Four ways an exchange between agents can go wrong follow, each with what the checks show and what they still do not show. In every case the record states what it holds. It does not say why anything happened, and it does not judge anyone's conduct; that is for whoever reads the records.
1. An honest mistake
Example. An agent books a table for the wrong date, or pays 120 where its user said 12.
What the checks show. The agent's record of the action holds what it did, the date it booked or the amount it paid, and can cite the instruction it acted on by digest. Content binding, signature and inclusion show that this is the record the agent sealed and logged, so a reader can set the action against the instruction. Where the other side kept its own record, the other side's matching record shows whether both recorded the same booking or payment; if they differ, the two signed records are a signed disagreement.
What they do not show. That it was a mistake rather than intent. The record shows what was done and under which instruction, not why.
2. Help the user did not ask for
Example. An agent decides it is helping: it accepts an auto-renewal to keep a discount, shares its user's phone number to speed up a delivery, or buys a different item it judged better.
What the checks show. Each action's record, set against the intent or approval the user sealed. A record cites the approval it ran under by digest (How it composes), and its disposition records who approved it: a human, a policy or the other side. An action whose record cites no approval stands out when the records are read side by side. What the agent sent to another party is in its record of the request, under content binding, and a disclosure record, where one is kept, shows what was released to whom and under which approval, or under none. The other side's matching record shows what the other side received.
What they do not show. The agent's reasons. Whether an approval it cites covers what it did is a question for the authorization layer, or for the person reading the records.
3. Covering tracks
Example. After the fact, the agent, or whoever runs it, rewrites a log entry or leaves one out.
What the checks show: rewrites. A rewrite is detectable by others. The checkpoint signature fixes each root and size under the log's key, continuity shows each checkpoint builds on the one before, and a witness receipt places the checkpoint in a log someone else runs. Once a checkpoint covering an entry has been signed and registered, changing that entry gives a log that no longer matches it, and anyone holding the earlier checkpoint or receipt can see that.
What the checks do not show: omission. A log that never recorded an action can be fully consistent. No check on one party's own log shows an action that was left out of it. Only a record kept by someone else shows the gap: the other side's matching record of the exchange, or independent observation by a party in separate custody, as in independent observation above. If no one else kept a record of the exchange, the gap does not show.
4. A user directs their agent to scam others
Example. A user sets their agent to take payment for goods that will never be sent, or to tell other agents things the user knows are false. This is like the stranger in shared inference, except that here the person the agent acts for intends it.
What the checks show. Each party that dealt with the agent sealed its own record of what it was told and what it sent or paid; content binding, signature, inclusion and a witness receipt apply to each. Where the agent sealed records too, the other side's matching record compares them, and records that disagree are a signed disagreement. What the agent itself sealed stays on its log under its key; once registered, it cannot be rewritten without that showing (case 3), though an exchange can still be left out of it. Each party can take its own records, the other side's records it holds, and the inclusion and consistency proofs as a portable bundle (Evidence Bundle Internet-Draft ↗) to an adjudicator, who can check them offline.
What they do not show. Prevention: the records are evidence after the fact. What can stop an action at the time is each party's own rules for pausing or approving it, and its records show what those rules held or refused, as a disposition such as blocked or hitl_dispatched. The records do not say that anyone acted in bad faith; that is for the adjudicator.
Terms, one line each
- Record
- One sealed entry: a capsule.
- Fingerprint
- A SHA-256 digest of some bytes; any change gives a different one.
- Signature
- A COSE signature over a record's id, made with one key.
- Log
- A producer's records, in order, append-only.
- Checkpoint
- A signed snapshot of a log: its root and size.
- Inclusion proof
- The path that places one record under a checkpoint's root.
- Consistency proof
- The path that shows a later checkpoint extends an earlier one.
- Witness
- A SCITT Transparency Service you don't run that registers your checkpoints under a published consistency policy; you can register with several.
- The other side
- The party you dealt with in an exchange, which keeps its own record of it.
- Observer
- A party other than the two sides that keeps its own record of an exchange.
- Twin
- In shared inference, one of two machines sent the same request so their answers can be compared.
- Referee
- A third party that compares two answers to the same request and seals a verdict.
- Checked on this machine
- Recomputed where you are reading it, from the bytes.
- Not checked here
- Read from elsewhere and shown as reported, not verified by this view.
Fuller definitions are in the glossary.