Trust is a residue. Now you can measure it.

A verifying signature tells you one thing: the receipt wasn't altered. It tells you nothing about which parts of the claim you can check for yourself and which parts you're simply trusting the issuer about.

Those are wildly different kinds of assurance, and almost every attestation format smears them together. "Verified ✓" — verified how? Recomputed by you from first principles, or vouched for by a signature over someone's assertion? A naïve relier can't tell, so they either over-trust (treat a vouched claim as a proven one) or over-audit (re-check things the math already settled).

The fix isn't more crypto. It's making the seam visible — and turning the trust surface into a number you can put a policy on.

Re-derive everything you can. What's left is the residue.

Most of what we call "trust" is just unmade re-derivability — work that could carry its own proof but doesn't yet. A claim you can recompute needs no trust at all: who-said-it stops mattering, because you check it. Re-derive everything you can, and what survives is small. That residue — and only that residue — is where trust or accountability is the right tool.

So: grade every load-bearing field by how a relier gains assurance about it, and report the fraction that isn't re-derivable. That fraction is the trust surface, as a number.

Four grades

The attestation-envelope spec (§15) adds an optional assurance block that grades each field:

grade	meaning	do you trust anyone?
re-derivable	recompute/verify it offline from committed inputs	no — you check it
judgment	an irreducible call a principal made; you can only see later if it held	yes — a reachable accountable principal
mechanism	verify-by-construction one layer down (reproducible build, TEE quote, did:web)	no principal — re-derive it, delegated
asserted	the issuer's word only	yes — the floor

The judgment/mechanism split is the subtle one. After you re-derive everything, what's left isn't one thing: a judgment is a call someone made (accountability carries it); a mechanism is the blind substrate that just operates — no one to hold, you re-derive it a layer down. Point accountability at a mechanism and you've named a scapegoat; point re-derivation at a judgment and you've asked it to prove something that isn't a proof.

Declared + fireable (the honest part)

You can't prove the re-derivable/judgment split is decidable — you can always dress a judgment up as a derivation over hand-picked inputs. So the grade is not a computed verdict. It's declared and falsifiable, the same way a completeness manifest works:

• A field graded re-derivable whose in-envelope method doesn't reproduce the value is self-void.
• Anyone can fire a field they can show is mis-graded (--fire=/pointer) — it drops to the floor.

Honesty is enforced by contestability, not by a decision procedure. That's the whole trick.

A real receipt reads 0.75

Here's the assurance block from a live Glyt approval receipt (Glyt is confirm-as-a-service: a human operator approves a specific agent action, and you get a verifiable, action-bound receipt):

"assurance": {
  "profile": "declared/1",
  "fields": [
    { "pointer": "/witnessed_claim/action_digest", "grade": "re-derivable",
      "method": "sha256(JCS(the action you are about to run))" },
    { "pointer": "/issuer/id", "grade": "mechanism",
      "verify": "did:key self-binding — the id IS the ed25519 public key" },
    { "pointer": "/witnessed_claim/decision", "grade": "asserted" },
    { "pointer": "/extensions/.../summary", "grade": "asserted" }
  ]
}

Run the reference verifier on it:

$ python tools/assurance.py receipt.json

  deferred    re-derivable  /witnessed_claim/action_digest
  mechanism   mechanism     /issuer/id
  asserted    asserted      /witnessed_claim/decision
  asserted    asserted      /extensions/.../summary
  --
  TRUST SURFACE (not confirmed re-derivable): 1.0
  irreducible residue (judgment/mechanism/asserted/void): 0.75

Read that honestly. The action binding is re-derivable: you recompute the digest over your own action and check it matches — so a cheap "$1 approval" can't be swapped for the expensive "$10,000 transfer" you present. That's the one thing you never have to trust Glyt about.

But the human decision itself grades asserted — because a stranger cannot re-derive that a person actually chose. You trust Glyt witnessed it (and the operator is held accountable through the receipt's contest channel). That's real, and the number says it out loud: residue_surface 0.75. A human-approval receipt is mostly trust, with one crucial thing you can check yourself. Pretending otherwise would be the lie.

An honest number is a feature, not a confession

Most products bury their trust surface behind the words "immutable" and "verifiable." Publishing residue_surface = 0.75 is the opposite move: the receipt tells you exactly what you're trusting it for, per field. And because it's a number, a relier can put a policy on it — "for anything over $1k, require the action-binding to be re-derivable and reject a receipt whose decision grade got fired." The grade is signed inside the envelope, so nobody can quietly downgrade it without breaking the signature.

Verifiable systems have spent a decade saying "trust nothing." That was never achievable — some things (a human's choice, a model's judgment) genuinely aren't re-derivable. The honest goal is smaller and reachable: re-derive everything you can, and say out loud what's left.

Try it

• Spec + reference verifier: attestation-envelope-spec — tools/assurance.py, docs/assurance.md (§15).
• Live issuer: glyt.net — every approval receipt carries the grade.

Run it against your own attestations. If you grade a field re-derivable and it doesn't re-derive, the tool self-voids it — which is the point. Show me where I graded something wrong; that's a --fire away, and it's how the honesty holds.