Three parts. Each one useful on its own.
A record is plain JSON. Any assistant, tool or register can write it, and any auditor can read it without the tool that made it.
What was examined
The project, its context and the second reader's report, word for word: triage and its criteria, findings ranked by impact, assumptions with a named human verifier, questions with their owners. A structured form for registers is planned.
content.project · content.contextcontent.report
What the signer did with it
Filled in by the signer, never by a model: who checked, what they checked themselves, who owns each open question, the decision and a signature, with its own fingerprint and seal. Planned: one closed answer per finding, and months later the outcome.
follow_up · decision · signatureThat it was not changed
A SHA-256 fingerprint recomputed from the file by every verifier, and the issuer's seal on it. A timestamp by a qualified trust service is planned. The fingerprint reveals nothing of the content. No ledger, nothing that the right to erasure would forbid.
proof.fingerprint · proof.sealFrom a review to a proof anyone can check.
Six steps, three actors. A second reader writes the review, the signer fills the follow-up, and the issuer seals the fingerprint. Nobody needs the tool that made the record to check it.
No model fills the follow-up. A record leaves step 2 with every follow-up field empty; only the signer fills them in step 3.
The fingerprint follows a published profile. Anyone can recompute it from the file. Canonical JSON (RFC 8785), for a hash independent of the tool that wrote it, is planned.
Verification starts on the file. Recompute the fingerprint from the proof file, then check the issuer’s seal (one call, fingerprints only). Never trust a fingerprint as written.
The format in three drawings.
The target data model of the format. Draft 0.1 implements the proof file: the texts, their fingerprint and seal, and the follow-up with the decision. The structured fields drawn here are planned for the register entry.
1 · Data model
2 · Proof chain
The texts have not changed since the issuer sealed them, at the time its server gives. A timestamp by a qualified trust service, independent of the issuer, is planned.
That the review was good, that the decision was right, or that the project is what it claims to be. The proof dates a record; judgment stays human.
3 · Chain of second readers
A project may pass through several second readers before the signer: a protocol, a specialist agent, a human expert. Each one is named in the record with its type, model family and session, so the rule that the second reader is never the author can be checked, not just claimed.
Countable. Checkable. Never the project itself.
The record holds the structure of the review, not the project under review. Counts must match their lists, so a script can check a record without understanding the business behind it.
A signature is only as good as the judgment behind it.
Fluent AI output reads like the work of someone who already checked. People who supervise reliable automation check less: automation bias is a documented finding of human-factors research, not a hypothesis.
Article 14(4)(b) of the EU AI Act asks that people overseeing high-risk AI systems be enabled to remain aware of automation bias. Assay Record gives that oversight a trace. It is a format, not a compliance claim.
Who uses a record
Shows the diligence behind a signature
What was checked, what was deferred and to whom, dated and unaltered. An open point declared honestly protects the person who signed.
Measures oversight, never people
Share of findings treated, questions owned, open points closed, sign-offs without reservation on critical reviews. Aggregated per team of five signers or more, never per person.
Checks any record, from any tool
One schema, one fingerprint to recompute from the proof file, one seal to check. A PDF alone proves nothing: the proof file does.
Example records
ILLUSTRATIVE, NOT REAL CASES · PER-FINDING ANSWERS AND OUTCOME PLANNEDEach card summarises one record. The file holds its structure, follow-up and proof. None contains the project.
Four ways to keep records
Every record is produced the same way. What changes is where it is kept, and who is responsible for it: always the organisation, never the format.
With the report
Individuals, first useThe signer keeps the exported report (PDF) and its record (JSON) in their own files. No register, no set-up.
FreeIn your tenant
Teams on Microsoft 365A register kit: SharePoint list, item-level permissions, Purview retention, Power Automate notifications. Half a day for a SharePoint administrator.
Included in the Riftveil Pro Kit · data stays in the tenantOn your infrastructure
Organisations with their own ITA documented procedure for your IT team: storage, access rules, fingerprint and timestamp steps, on systems you already run.
Procedure on request · your responsibilityBy Riftveil, in the EU
Teams without an administratorRecords stored for you, in the EU. Only the record, never the project.
PlannedTools that write records
Implement the specificationOpen protocol that challenges an AI output before a human signs. Produces the record on riftveil.ai, and registers reports made in ChatGPT, Claude or Microsoft 365 Copilot.
REFERENCEA review tool, a GRC platform or an agent framework can write records. Until conformance checks exist, the bar is simple: proof files valid against the JSON Schema, verifiable by their issuer.
OPENFour steps, all on open standards.
Licence and governance
Open to use, protected in name. The specification opens further as it matures; it never closes.
Free to use and share with attribution. No modified versions while the format matures.
Free to use, adapt and build on, with attribution.
Free to use in any product, with an explicit patent grant.
The name of an open format. Free to use for tools that write valid records.