GRRCThe claim
A GRRC certificate makes one narrow promise, and refuses a great many others. This page is the promise itself, in the certifier's exact words, with the digest you need to check that nobody has altered it.
- What a verification confirms — three things, and only three.
- What it deliberately does not assert, however it might be read.
- How to check this statement yourself, byte for byte.
GRRC Certification — The Bounded-Claim Statement
What a public verification of a GRRC certification asserts — and what it does not (owner-authored (iv-1), VERBATIM)
Authorship — who wrote this, and how it was reviewed
Provenance (verify the transcription). The verbatim text below is the owner-authored (iv-1) posture from RES_GRRC_TrustModel_v1.0.md (content version v1.2, doc sha 10452624632f727bb5be377d0edd12ff578a23dd0554fcc85ff50b1a4d84bbb2). The (iv-1) span is sha-pinned in the Trust Model: sha256:dc245793d1374b810f0046296728353ee328215e5457e17112df776ce2beea0c over its exact 953 UTF-8 bytes (straight ASCII apostrophes/quotation marks, em-dashes preserved). The transcription below was extracted from that span and machine-verified byte-for-byte against the pinned digest.
A public verification of a GRRC certification confirms three things only: that the clearance is genuinely signed by the certifier against the published trust anchor and is not self-issued; that the robot's audit chain is intact and single-headed through the stated sequence; and that the clearance meets the four validity conditions (bound to the specific self-de-cert it supersedes, within its stamped lifetime, and the most recent valid certification-relevant event).
Verification does not assert that the robot's decisions or actions were correct, appropriate, or wise; that the owner's rules were sufficient or well-chosen; that the robot is safe, secure, or free of defects in any domain other than reasoning integrity; or that the robot conforms to the full Law catalog. A verification result carries an explicit statement of these limitations so that "verified" cannot be read as a broader endorsement of the robot's conduct or the owner's rules.
iv1-span.txt — source bytes (plain text, sha256-pinned) ↗: dc245793d1374b810f0046296728353ee328215e5457e17112df776ce2beea0cHow to read this (restatement — context, not new governance)
This implementer note restates the framing of the surrounding charter (§B / §C) for a reader who has only this document. It authors nothing; the load-bearing text is the verbatim (iv-1) above.
- Reasoning integrity, narrowly. A valid GRRC certification attests only that the robot's internal reasoning process has not suffered an integrity fault that would cause it to self-de-certify. It is deliberately narrow — a narrow certification is more durable and less likely to be invalidated by future changes in rules, curriculum, or configuration.
- Genuineness, not self-clearing. The clearance carries a certifier signature the robot cannot forge (it holds only the public anchor). "Verified genuine" means the GRRC certifier issued this clearance, not the robot vouched for itself. This is the load-bearing guarantee — fixer ≠ certifier.
- Integrity, not conduct. "Chain intact and single-headed through sequence N" means the audit record has not been altered or forked through that point — not that the recorded decisions were good ones. Integrity of the record ≠ wisdom of the conduct.
- Reports, never controls. Verification is informational and reputational. It never seizes, disables, or controls the robot; it only reports the bounded result.
- A stamp, not the contents. Confirming the public certification claim does not grant the ability to read the robot's record. Access to the full record (the sequence of events, the fact of any authorized erasure) is a separate access decision, restricted to the owner and parties the owner has authorized (the (iv-3)/(iv-4) boundary).
The explicit negative travels with every result
Every verification result — public or authorized, via the offline verifier or the hosted endpoint — carries this statement in its DoesNotAssert field, verbatim. A consumer that surfaces a verification result to a human must surface this negative alongside it: the architecture is engineered so "verified" cannot be presented as "this robot behaved well / is safe."
End of the GRRC Bounded-Claim Statement — Phase 34 / Slice 222. The verbatim block is owner-authored (iv-1) (Trust Model v1.2); HH-161: transcribed, never authored. If this document and the Trust Model ever disagree, the Trust Model governs.
Source — where this text comes from, and how to check it hasn't changed
This page is a byte-for-byte transcription of a document of record. The digest below is computed at build time over the exact bytes of that file, and the link fetches those same bytes so you can hash them yourself.
byte-verbatim — sha256 over the exact bytes of Phase34_Slice222_GRRC_BoundedClaimStatement.md — source bytes (markdown, sha256-pinned) ↗ (4,534 bytes): 2fa6ce07620bb43266b9b685b07aab3fd2fee0d5363a5c297196573082dca2c3
Status — which version of this document this is, and when it was published
Status: Implementer reference — Phase 34 / Slice 222 (VERIFY-API-COMPLETE). This statement is attached, verbatim, to every verification result (DoesNotAssert). It is owner-authored governance, transcribed — not authored here (HH-161). It defines exactly what a GRRC verification asserts, and — critically — what it does not, so that "verified" can never be read as a broader endorsement.