The sign-off and the score on this page can be checked from the files below, without any TrustThread software.
- thread.json: the Thread record (11084 bytes,
sha256:95dce8b4bf4ee223e88e22d20a6936a7b363a1ce84cc9becb50e4a2cac19aa49) - finalize-report.json: the finalization report: claim extraction and matching notes (3455 bytes,
sha256:c718142b583d07b60832783b9265cf0690942e3e15638940a5927e71314ac7ac) - gates/G1.json: the Human Validation Gate G1 (980 bytes,
sha256:b4e51fedc1081eb4536a32afebe772081cce0f493e1380c66a05e81e93c17dd1) - gates/G2.json: the Human Validation Gate G2 (1469 bytes,
sha256:b97aed789abc590b3962f36e27968ab98cec1339410d3ce8ce835ee67ea784a6) - validators.json: the validator-list entries for the keys that signed (405 bytes,
sha256:2a53d018949feebbb759b06f868a755605c8736a58020c7da04e82c4e3223ddf)
The score
Recompute qs-1.0 from thread.json. Claims are the unit of measurement. A witnessed node grounds only when its evidence is intact; a witnessed node whose stored evidence was missing or altered (integrity_status: "degraded") is degraded, not grounded. Assumed and derived opaque nodes are ungrounded, and so is an inferred node with no premises. Any other inferred node takes the weakest grounding among its premises (ungrounded < degraded < grounded), and a claim takes the weakest among its support nodes.
- Confirmed ratio: claims that are grounded, over all claims.
- Opacity ratio: claims whose support is a derived opaque node (nothing recorded supports them), over all claims.
- Depth: the most edges on any path from a claim down to a witnessed node, counting the claim's own edge to its support; 0 when no path reaches one.
- Witnessed ratio (supplementary): witnessed nodes over load-bearing nodes, the nodes some claim rests on, directly or through premises. Nodes nothing rests on are orphans and count for nothing.
- When claims are pending or not extractable, or there are none, the claim ratios are not computable, which is not the same as zero.
The four are reported separately and never blended. The record carries the score stamped at finalization; this page shows the one recomputed from the record.
The sign-off
- Every SHA-256 in these files is written
sha256: followed by 64 lowercase hex digits.
- Each file in
gates/ is a gate's canonical JSON (object keys sorted by UTF-16 code units, no whitespace, strings and numbers as JSON writes them, as in RFC 8785) followed by one line feed.
- Signature. Remove
signature.value from the gate. Take the text trustthread-validation-gate/0.1, a line feed, and the canonical JSON of what remains. signature.value (base64) must be a valid Ed25519 signature of those bytes by signature.public_key (base64 SPKI).
- Key. The SHA-256 of the public key's SPKI bytes must equal
signature.key_fingerprint, and that fingerprint must appear in validators.json under the name the gate gives.
- Content.
thread_content_hash (scheme thread-content/0.1) is the SHA-256 of the canonical JSON of thread.json keeping only record_version, thread_id, agent_id, agent_type, output_type, output_text, output_reference, created_at, run_context, root_node_id, thread_status, claims_status, claim_extraction, claims, nodes, evidence, scorecard_version, quality_score, with each node's annotated flag removed. Resolution, gate ids, and visibility are left out, because signing and publishing change them. This holds for the gates in force; a superseded gate may bind an earlier version of the record.
- Report.
report_hash is the SHA-256 of the canonical JSON of finalize-report.json, or null when there was none.
- Chain. Each gate's
previous_gate names the gate before it and the SHA-256 of that gate's canonical JSON, without the file's trailing line feed.
- Review code. The code in the page header is the first 16 hex digits of the SHA-256 of the canonical JSON of
{"report_hash": …, "thread_content_hash": …}, in groups of four. The signer typed it back from the page they reviewed, which ties the sign-off to the content that page showed.
What a passing check shows: the holder of the key listed in this receipt's validators.json signed this decision against exactly this content. That this key belongs to TrustThread's validator list is TrustThread's statement, which these files alone cannot prove; the full list is published at www.trustthread.ai/validators.json. A check does not show who holds the key: the name is self-asserted, not authenticated. The fetched pages are not republished here: each observed node links to its source and records the SHA-256 of what was fetched. TrustThread states that it re-hashed every stored body against the record when it published this receipt (2026-10-16); the bodies themselves are not part of these files.