Governed vs verifiable AI: check the rule and the receipt
Contents
Rule and receipt
One request, four separate claims
A contractor asks an assistant for a restricted budget. The answer says “access denied”, and the dashboard shows a matching event. That is encouraging. It still leaves two questions: did the system actually withhold the budget, and can the event be checked later? Governance and verification address different parts of that investigation.
The rule controls behavior; the receipt supports investigation
Governance includes the policies and controls that decide what a system may do. Verification examines evidence for a specified claim about what it did. These are capabilities to inspect, not mutually exclusive product categories. A governed system may have extensive audit evidence, and a signed record can describe a poorly enforced policy.
The verifiable AI definition explains the broader terminology. Here the practical task is narrower: decide whether one denied request has enough evidence to support the claim you want to make.
Read a complete, bounded request record
This example is fictional. A contractor, user C, belongs to the external-support group. Policy P7 permits that group to read public support instructions but denies the internal budget source B. At 14:10, request R42 asks to read B. The system returns no document body. The record says principal C, source B, policy P7, decision deny, request R42, time 14:10.
An investigator is given that event, the relevant policy snapshot, a trace of this request’s source response, and the verification material for a signed batch containing R42. Assume the signature check passes. This supports the integrity of the supplied record under the trusted key. The response trace separately supports that this checked path returned no document body.
| Claim | Evidence required | Result in this example |
|---|---|---|
| The supplied event has not changed since signing | Record, signature and independently trusted key | Supported under the stated verification assumption |
| P7 denies C access to B | P7 snapshot and identity/group mapping at request time | Supported if those supplied records accurately describe the serving state |
| R42 returned no budget on the checked path | Request/response trace tied to R42 | Supported for this path |
| No contractor ever received B | Complete coverage of relevant paths, identities and time period | Not established by this one event |
Find what could be missing before trusting the conclusion
Could a search preview expose the budget while a full-document request is denied? Could a cached answer use a different policy snapshot? Could a second endpoint omit events? These are questions for a concrete deployment, not claims that it has those defects. They explain why one clean event cannot establish a universal negative.
A record also relies on capture: the software must bind the right identity, source and decision to the event. Signing a mistaken event preserves the mistake. Test the mechanism with harmless allowed and denied requests and compare the independently observed responses to the exported records.
Ask cryptography a precise question
RFC 9162 provides a useful example of distinct log guarantees: an inclusion proof concerns membership in a committed tree; a consistency proof concerns the relationship between tree states. It is a certificate-transparency protocol, not evidence that an AI product uses that protocol or captures every relevant access.
For R42, a useful verification claim might be “this event is included in the specified signed batch”. “No data ever leaked” needs much more evidence. Independent audit anchoring can strengthen a commitment’s reference point without solving incorrect capture or missing requests.
Make the acceptance decision explicit
For the fictional deployment, accept the demonstrated record-integrity check. Keep the broader access claim open until previews, cache paths and other serving endpoints are covered. Assign those checks to the operator who can observe them. That is a useful result: the review identifies what works and the exact evidence still missing.
Apply this distinction to HeyBrain or any other product without assuming its name establishes an implementation. Ask for the offered configuration, an export and a bounded demonstration. A roadmap item, a marketing promise or a screenshot of a green check is not the same evidence.
Editorial method
HeyBrain Editorial Team revised this article with AI assistance using the primary sources linked in the text. Examples are hypothetical, not product test results. This article does not establish that HeyBrain implements the described evidence mechanisms.
Frequently asked questions
Can a system be governed without cryptographic logs?
Yes. It can enforce access rules and retain ordinary operational records. Cryptographic evidence may add useful integrity checks, but it does not define whether access controls exist.
Can a signed record prove the answer was correct?
A signature helps verify a record’s origin and integrity under a trusted key. Correctness of the source, policy, capture process and answer require their own checks.
Use a precise claim and evidence that can actually test it. Read the verifiable AI guide
