Summary

  • A 28 October individual Internet-Draft proposes a verdict record carrying an issuer’s result, cited evidence digests and a named rule. The checker must bring its own policy, trust anchors and evidence bytes.
  • Its report can say released, held or refused and identify the step behind that state. It must not turn the whole record into a green verified or true badge.

The stamp belongs to the reader

An issuer writes “pass” on a card and attaches references to receipts. The card may be faithfully signed and still leave the question open: did the checker see the evidence, apply the stated rule, and accept that rule under a policy it chose itself? Darren Wright’s new verdict-record proposal gives those questions separate places in a machine-readable record. Its status is an individual, Experimental-intended Internet-Draft.

The proposed record is strict, canonical JSON. It names the writer, a claim, evidence items by exact SHA-256 digest, and a check with a named rule and result. It can describe a mechanical check-run or a model-decision. The issuer can version a record and cite its predecessor. The wrapper that binds a key and an upper time bound sits outside the JSON; a SCITT Signed Statement and Receipt is one possible wrapper. The draft does not ask a digest to impersonate a witness or a timestamp.

The decisive line appears in the checker’s inputs. Every input used to pass a step must be beyond the issuer’s reach. The checker calculates a digest from bytes it holds, verifies a signature, re-runs a rule, or uses its own policy and trust anchors. An issuer’s sentence can be reported as an issuer’s sentence. It cannot vote itself into a passing test. That is a small technical rule with an enormous administrative consequence: the producer of a conclusion does not get to supply the test that certifies it.

The draft then gives missing material a name. For each cited evidence item, the checker needs the full item, a matching digest and a format it knows how to verify. If the presenter leaves one out, that step is NOT RUN. An unsupported format also leaves it unrun. A mechanical rule is run again on the stated body; a different answer fails the step. A non-mechanical judgement is accepted only for record kinds the checker’s own policy lists. One cannot manufacture a pass by withholding an awkward receipt. The withheld item creates a held state, not a silent green light.

The final vocabulary is deliberate. All steps pass: released. A step fails: refused. No step fails but one cannot run: held. An invalid checker policy yields no verdict. The report names each step and its reason, the record’s upper time bound, and digests of the policy and trust-anchor sets. It may not put verified, valid, trusted, correct, proven, confirmed or OK over the whole record. The list sounds like a ban on cheerful dashboard copy because that is exactly where institutional assertions become public facts by typography.

There is a limit even to released: it says the issuer asserted a result on named evidence under a named rule by a bounded time. It says nothing about whether the underlying claim is true. That distinction is the point of the design. A checker can make the record auditable without being drafted as a witness to the issuer’s claim.

Sources: Wright draft; Datatracker status; SCITT architecture, RFC 9943; JSON, RFC 8259.