Governance · the operating model
Building the Riftveil Protocol into your AI use policy.
A rule, not a tool: no AI-generated output above a stakes threshold informs a team decision without a Riftveil report attached. The report never says what to decide. It says what was not seen before deciding. The team still decides, and is still accountable.
The “Riftveil report first” rule
Who runs it, and when
The report is produced before the output goes to a reviewer, an approver or a meeting, and it is produced by the person who generated the output, not by the reviewer.
The order matters. The author reads the report alone, first, and addresses what they can before anyone else sees it. The reviewer receives the output, the report, and the author’s answers to its questions. The aim: the predictable objections are already on the table, and the reviewer starts from the assumptions, not from the polished surface.
Two rules keep the threshold honest. Escalate on doubt: if people argue about whether it is MODERATE or HIGH, it is HIGH. The author does not pick the level alone: the person who will sign picks it, or the two agree.
“If an AI helped produce it and it is MODERATE or above, the Riftveil report and your answers to its questions travel with it.”
One sentence to copy into your team wiki, your AI assistant’s standing instructions, or the pinned message of the team channel.
Triage thresholds, mapped to real decisions
Translate once, write it down, put it where people work
The protocol triages on reversibility, impact scope and financial commitment. Those criteria are generic. A team translates them once into the decisions it actually makes. The examples below are a template; replace them with yours.
| Stakes | Your team’s decisions that fall here | Is a Riftveil report needed? | What the report examines |
|---|---|---|---|
| LOW | Internal emails, meeting notes, first drafts nobody acts on yet | Optional, to build the habit. | The answer only (what the project says). |
| MODERATE | Sprint plans, vendor shortlists, internal recommendations, team proposals | Yes, by default. | The question (what was actually asked), the answer (what the project says) and the reasoning (how it gets there). |
| HIGH | Anything that goes to leadership or to a single client, supplier or partner, commercial strategies, contract terms, architecture changes, hiring plans, budgets visible at department level that need sign-off above the team | Yes, mandatory. | The same three, plus perspective (what the project did not see). |
| CRITICAL | External submissions (regulators, public), strategy commitments, anything affecting a client base or the public, commitments significant for the whole organisation, irreversible changes | Yes, mandatory, with a named challenger. | The same four, plus applicability (what it looks like in the real world), with a pre-mortem. |
What goes in the decision file
Technical decision record, decision file, pull request, memo, wiki page
The report and the team’s answers document the examination of each decision. When your AI use policy or your auditors ask for more, the record file is added: for each decision, an AttestScope Record signed by riftveil.ai. Together, these files form an audit trail. Never file the report without the answers: a list of open questions with no owner is noise after a week.
For CRITICAL decisions, a named challenger runs Riftveil independently of the author and records their own reading.
Months later, the decision file still shows what was submitted, how far the examination went, what remained open and who owned it, and who decided.
What the decision file contains
The project examined · in the PDF
The text produced with AI, as it was submitted, and the context given: the version examined, not one edited afterwards.
The Riftveil report · in the PDF
The stakes level assigned and its criteria; what was examined, and what was not; the findings, ranked by impact; the assumptions the project relies on, and who can verify them; the questions to settle before deciding, with an owner when the report can name one. It opens with the Record, six lines that summarise it. It never says what to decide.
The signer’s follow-up · in the PDF
What they checked themselves; who each open question is assigned to; their decision (proceed, proceed with conditions, do not proceed), their conditions and their signature. Completed by a person, never by the model.
The record file · in addition, alongside the PDF
An AttestScope Record, signed by riftveil.ai: the text of the project, the context and the report, the follow-up once completed, the fingerprints, the seals and the signatures. This file, not the PDF, is what you check to confirm that nothing has changed.
The team’s answers · in the decision file
The written answer to each question, with the person who gave it; for a CRITICAL decision, the named challenger’s reading. Added by the team.
A report produced in your own AI assistant, then registered: the report goes into the decision file, with its record file for the decisions you will have to answer for; the follow-up is completed in the block the protocol provides on request.
Checking that a report is intact
Record ID, seal, record file
Every report run on riftveil.ai receives a Riftveil record ID (date, time, random characters) and a seal. The export gives two files: the PDF to read, and the record file to verify. File the PDF; keep the record file with it for the decisions you will have to answer for.
The rule: a report is verified on its record file, never on a printout, a screenshot or a PDF alone. Anyone can copy an ID onto an altered document; nobody can alter the text of a record file without the check failing. Drop the file on riftveil.ai/verify and compare the text shown with the document you were given.
A report produced with the protocol in your own AI assistant (Microsoft 365 Copilot, ChatGPT, Claude…) can be registered: only its fingerprint leaves your browser. Its record file then says “registered with Riftveil”; the record file of a report assessed here says “generated on riftveil.ai”.
What a valid seal proves
- That riftveil.ai assigned the ID, at the time shown by its clock (UTC, to the second).
- That the text has not changed by a single character since.
- Its origin: generated on riftveil.ai, or registered.
- The seal is checked on riftveil.ai. The signature, however, is checked with riftveil.ai’s public key: anyone can do it, without going through us.
What stays with the person who signs
- The seal covers the date and the integrity of the text. The substance of the project, how the protocol was applied and the decision remain those of the person who signs: they attest what they examined, and within what limits.
For technical teams
For your own tools: POST https://riftveil.ai/api/verify with { id, fingerprint, seal }, and a verification widget for any page: <div data-riftveil-verify></div><script src="https://riftveil.ai/embed/verify.js" defer></script>
An owner for every question
The questions are the deliverable · treat them as work items
Answer in writing
Under each question, one line is enough. “Unknown” is a valid answer, and often the most useful one.
Assign every open question
Name and date. The protocol only asks questions the reader’s context can answer, so there is always someone who can. Each assumption names who can verify it: that person is the owner.
Mark what blocks the decision
If the answer would change the decision, the decision waits for it. If it would not, note that and move on.
Close the loop
When a question is answered, note whether the answer changed anything. That record is how the team learns which traps recur in its domain. And no model answers its own questions: the point is that a person with context supplies what the model could not.
A first rollout, in four weeks
One team of manageable size · one decision type · one tool route
Pick one team, one decision type that is clearly MODERATE or HIGH and frequent enough to see ten or more instances in a month, and one platform. Budget about fifteen minutes per report for the author and five to ten for the reviewer. If it takes more, the output is too long: focus on the three to five sections that matter, or split it.
| Week | Do | Output |
|---|---|---|
| 0 · prep, two days | Set up Riftveil on your platform and run the standard tests. Write the triage table. Name a rollout owner and, for CRITICAL, a challenger. | Tool works; table published; five-minute guide shared. |
| 1 | Everyone runs Riftveil on one real output, alone. Thirty-minute debrief: what surprised you? | First reports in the decision file. Baseline for metric 2. |
| 2 | Apply the “Riftveil report first” rule to the decision type of the first rollout only. Owners assigned to questions. | Reviewers say how long the read-through took them and how much it improved quality. |
| 3 | Add a second decision type, or raise to HIGH stakes. Run one CRITICAL with a named challenger if one occurs. | Metrics 1 to 4 collected. |
| 4 | Go through the metrics. Decide: extend, adjust the triage table, or stop. Write a one-page decision, and run Riftveil on it. | A go, adjust or stop decision with its own Riftveil report. |
Five adoption metrics
Weekly during the first four weeks, monthly afterwards · simple enough to count by hand
Metric 1
Coverage
Share of MODERATE-and-above AI-assisted outputs that reached the reviewer with a report attached. Target by week 4: above 80% for the decision type of the first rollout.Metric 2
Assumptions caught before the decision
Unstated assumptions surfaced that the author confirms they had not considered. Track the average per report. If it trends to zero, the outputs are trivial or nobody reads the reports.Metric 3
Questions closed before the decision
Share of questions answered or explicitly parked, with a reason, before the decision was taken. Target: above 70%.Metric 4
Decisions changed or delayed
Decisions where a finding, assumption or question changed the decision, its timing or its scope. This is the value metric: the number that justifies the exercise, or does not.Metric 5
Sign-off cycle time
Median time from “output ready” to “approved”, before and during the first rollout. This is the figure that will tell you whether the rule saves your team time, or costs it.
Eight anti-patterns
What a rollout looks like when it is failing
- 1Running it on trivia. A report on a two-line message trains people to skim reports. Use the triage table; LOW is optional.
- 2Taking the report for a conclusion. “Riftveil found only three things, so it is fine” is exactly the coherence trap the protocol is built against. There is no pass or fail, and nobody should add one.
- 3Letting the model challenge itself without the protocol. Asking the model that wrote the output “are you sure?” is not Riftveil. Without external feedback, self-correction can degrade performance (Huang et al., ICLR 2024; Tsui, 2025). The protocol is not that feedback; it changes the model’s role (adversarial reviewer, fixed procedures, a report that cannot end on a conclusion) and puts a human verifier on every assumption. It aims to mitigate this risk, without removing it.
- 4Editing the protocol to be nicer. Someone adds “start with what is good about the output”. Rule 1 dies and the report becomes a compliment sandwich. Lock editing rights to one or two owners.
- 5Answering the questions with more AI. The questions exist to pull in human context.
- 6The reviewer runs it instead of the author. Then it becomes a gotcha tool and people hide their AI use. The author runs it first; the reviewer reads it.
- 7Skipping the context line. Without a stated role, decision and stakes, the protocol has nothing to place the triage on: it defaults to MODERATE. A CRITICAL submission triaged as MODERATE never gets the pre-mortem.
- 8Keeping the report and losing the answers. A report with unanswered questions is an open risk register nobody owns. Record answers and owners in the decision file.
Where the full guide lives
Pro Kit · team licences
This page condenses the operating model. The full rollout guide in the Pro Kit adds the platform setups (Claude Project, ChatGPT project, Microsoft 365 Copilot agent, API), the three standard tests, the thirty-minute onboarding script, the five-minute quickstart, how to use the report schema, published with the protocol, in the decision file, and a one-paragraph team announcement to copy and send.