01 / 11

The problem: a stranger node

A machine you have never dealt with answers your inference request and tells you things about it; each check below settles one of those things, and some are left open.

1What it is

In a shared inference mesh, a machine you have never dealt with serves your request and hands back an answer along with things it says about that answer.

Each check a verifier can run answers one narrow question about the record, and a pass on one says nothing about the others.

Some of the node's claims, such as which model ran and whether the answer is right, are not covered by any check on the record alone.

2Design choices

Chosen: the record carries digests of the request body and the completion body, sealed together.

Rejected: carrying the prompt and completion in the record; the digests bind them without publishing them. (AAC -05 §5.3, inference_completion)

Chosen: a signature check returns the authenticated public key and stops there; whether that key may speak for anyone is the caller's policy.

Rejected: reading a verified signature as the identity of the operator or developer the record names. (AAC -05 §3.2)

Chosen: a verifier reports each check as its own finding in a structured result.

Rejected: one overall "trusted" answer, which would hide which question was actually checked. (AAC -05 §6)

Chosen: a producer states only the assurance it reached, and a verifier re-derives it from the bytes.

Rejected: taking the node's own label for how strong its record is. (AAC -05 §5.4)

3What it shows / what it does not

This follows the Trust map in the docs, check by check.

Shows

Content binding: the record's fingerprint, recomputed from its bytes, matches the id it was sealed under.
Signature: proves the holder of a key signed the record's id.
Digest binding: this response digest was sealed with this request digest.
Inclusion in a signed checkpoint: proves inclusion: the record is in the node's log, against that checkpoint's commitment (the MMR peaks).
Receipt for the checkpoint: proves inclusion of the checkpoint in a Transparency Service's log. Only if that service applies a Consistency Registration Policy would a later rewrite of the node's log be refused there.
Twin plus referee: whether two nodes' answers to the same request agree, under weights both records say are the same; a referee can rule on one differing pair.

Does not show

That what the record says is true.
Who holds the key, or that the node the record names did the work. The key is the one the node announces: its claim.
That the model weights named are the ones that ran. A model name alone never counts as a match.
That the log holds every action, or that the time in the record is when it happened.
That a receipt's service agrees with the record; it sees checkpoints, never records.
Which model ran. Twins that serve the same wrong model agree with each other, and the shared weights are each node's own word. A referee verdict is a ruling on one pair.

4Example

A record a demo node sealed for one served inference (line 1 of the file, reformatted for reading). The record's spec_version is an earlier revision. In this demo it is signed as a COSE_Sign1 statement (in signed-statements/d4b16756….cose) whose attached payload is the whole record in JSON, with alg EdDSA (-8), CWT iss mesh-node-demo-1 and sub equal to the capsule_id, and no kid. That is not the -05 Producer Envelope, which signs the raw 32-byte Capsule ID under a kid carrying the public key (AAC -05 §3.1).

{
  "action_id": "mesh-poc/mesh-node-demo-1/db961447-9996-47c4-8137-0d5291df3438",
  "assurance": {
    "attestation_mode": "self_attested",
    "effect_mode": "confirmed",
    "ledger_mode": "standalone"
  },
  "capsule_id": "d4b16756ecf59fa7a530757a9888a0b1cedb68e4e73e738b09b7abfbc57a8df8",
  …
  "effect": {
    "effect_attestation": "gate_executed",
    "request_digest": "3e931d5f6efde26a335b082e509dee4e2635e92f4d146b62af47126dccf3ec1f",
    "response_digest": "004d18a0002e12a9c5bd63e655d8f16a8ee4e98aa7b6c364dfc74d96b8cc486e",
    "status": "confirmed",
    "type": "inference_completion"
  },
  …
  "model_attestation": {
    "compute_attestation": {
      …
      "x-mesh-poc-v1": {
        …
        "evidence_refs": {
          …
          "tee_attestation": {
            "context": null,
            "digest": null,
            "type": "tee_attestation"
          }
        },
        …
        "generation_parameters": {
          "max_tokens": 64,
          "seed": 1,
          "temperature": "0.2"
        },
        …
        "serving_provenance": {
          …
          "model_canonical_ref": "capsule-emit-poc/tiny-fixture-model:Q4_K_XL",
          "quantization": "unknown",
          "requesting_party": "unknown",
          "role": "provider",
          "served_by_node_id": "mesh-node-demo-1"
        }
      }
    },
    "model_id": "capsule-emit-poc/tiny-fixture-model:Q4_K_XL",
    …
  },
  …
  "timestamp": "2026-09-03T07:23:31.301211Z"
}

Field	Type	Meaning
capsule_id	hex tstr	SHA-256 of the record's JCS bytes with `capsule_id` removed (AAC -05 §5.1).
assurance	object	The producer's stated assurance; a verifier re-derives each mode.
effect.type	tstr	`inference_completion`: a served completion.
effect.request_digest	hex tstr	Digest of the request body as received.
effect.response_digest	hex tstr	Digest of the completion body as returned; required for `confirmed`.
effect.effect_attestation	tstr	Who vouches for the effect, as the producer states it.
model_id	tstr	The model the node says it served: a claim, not a check.
serving_provenance.served_by_node_id	tstr	The node that says it served; the node's own word.
serving_provenance.quantization	tstr	Recorded as `unknown` here, not guessed.
generation_parameters	object	Settings the request asked for; needed to re-run it.
evidence_refs.tee_attestation	object	Hardware attestation slot, empty: none was taken.
timestamp	tstr	When the node says it sealed the record; the node's own clock.

Source: action-state-group/capsule-emit-mesh:ledger-checkpoint-demo/capsules.jsonl (line 1) @ 8500e254a02bd6f5e145ab2d471a0f997cf2fa5a

5Specs

Internet-Draft draft-mih-scitt-agent-action-capsule-05 — the record, its digests, the signature envelope and the verifier's checks.
Internet-Draft draft-mih-scitt-checkpointed-local-log-02 — each node's own log and signed checkpoints.
Internet-Draft draft-mih-agent-bilateral-attestation-02 — the other side's matching record.
RFC RFC 9052 — COSE: structures and process.
RFC RFC 9943 — SCITT architecture.
RFC RFC 9942 — COSE Receipts.
Code action-state-group/capsule-emit-mesh — the harness that sealed the example record.