Doing the work is the first half. Proving you did it, to a stranger, eighteen months later, under scrutiny, is the half nobody warns anyone about — and it is the half that decides how the story ends. If you have not yet looked at what your own surface would show, the risk calculator takes about twelve questions.
Picture the moment the evidence is actually consumed. An underwriter is working a renewal file. A diligence team is grinding through a data room. An auditor is sampling records eighteen months after the fact. Someone hands them an AI governance document, and the professional reflex fires: says who? The usual answers are all bad. “Log into our compliance platform and see for yourself” — nobody grants an outsider tenant access, and no outsider wants the liability of having it. “Trust the letterhead” — a well-formatted document and a fabricated one look identical. The verification URL exists to give that moment a third answer: paste this into any browser and check the record yourself.
Stage one: Generation
When a customer generates an Executive Risk Report or an AI Acceptable Use Policy, the system computes a short verification ID derived from the artifact’s essentials — its kind, its generation date, a fingerprint of the inputs, and the model version that produced it — and writes a small verification record: the artifact kind, the generation date, the model version, the AI-endpoint registry version the assessment ran against, and, only if the customer opts in, the company name. The URL carrying that ID is printed on the document itself. (Scope note: the verification URL is carried on the Executive Risk Report and the AUP; the one-page Board Memo is a derived summary and does not carry its own.)
Stage two: Query
Anyone holding the document can visit the URL — no account, no login, no request to the customer. The public page returns the record: this artifact kind was generated on this date, by this model version, against this registry version. The record is retained for five years, which is the horizon evidence actually lives on — renewal files, audit samples, and disputes all reach back years. You can try it now on the sample report and the sample policy.
Stage three: Validation — and the trust boundary
Here is the architectural decision that makes the system trustworthy in both directions. The verification record holds metadata only. It never stores the report’s contents, the customer’s inputs, the network-log data, or any finding. The outsider gets exactly what they need — independent confirmation that a dated artifact of this kind exists and what produced it — and nothing they should not have. The customer gets to hand out proof without handing out exposure: no tenant access, no confidential contents on a public endpoint, nothing for an attacker to harvest. The boundary between exposed metadata and never-stored payload is not a limitation of the design. It is the design.
Equal honesty about what validation means: the URL is dated, third-party-verifiable evidence that the artifact was generated, when, and against which registry and model. It is not a certification, not a compliance guarantee, and not a claim that the organization followed the policy on any given Tuesday — those are questions for the program, the auditor, and the record keeping around it. A verification that overclaimed would be worse than none. This one is deliberately narrow, which is exactly why a skeptical professional can rely on it for what it says.
Not “trust our summary.” Check the record yourself.
The underwriter-facing walkthrough, including how the URL travels inside a renewal questionnaire, lives at /insurers. Data-handling details for the verification subsystem are on the trust page.