Adopting the Riftveil Protocol as an internal standard.
A rule, not a tool: no AI-generated output above a stakes threshold informs a team decision without a Riftveil record attached. The record never says what to decide. It says what was not seen before deciding. The team still decides, and is still accountable.
The “Riftveil before review” rule
Who runs it, and whenThe record 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 record alone, first, and addresses what they can before anyone else sees it. The reviewer receives the output, the record, and the author’s answers to its questions. Review time drops because the predictable objections were already surfaced; review quality rises because 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 record and your answers to its questions travel with it.”
The sentence for your wiki, your CLAUDE.md, or the pinned message of the team channel.
Triage thresholds, mapped to real decisions
Translate once, write it down, put it where people workThe 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 | Riftveil record |
|---|---|---|
| LOW | Internal emails, meeting notes, first drafts nobody acts on yet | Optional. Level 1 if you want the habit. |
| MODERATE | Sprint plans, vendor shortlists, internal recommendations, analysis shared with one other team | Yes, by default. Levels 0–2. |
| HIGH | Anything that goes to leadership, commercial proposals, contract terms, architecture changes, hiring plans, budgets €10k–100k | Yes, mandatory. Levels 0–3. |
| CRITICAL | External submissions (regulators, clients, public), strategy commitments, anything affecting patients, customers or the public, budgets over €100k, irreversible changes | Yes, mandatory, with a named challenger. Levels 0–4. |
What goes in the decision file
ADR folder, decision log, PR description, memo, wiki pageWherever the team keeps decision records, add a fixed block. Keep the raw report as an attachment, or in the JSON form if there is tooling for it. Never file the record 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. Two people reading the same record catch more than one.
## Riftveil record — <date> — Protocol v1.3 — Model: <which model ran it> Triage: <LEVEL>, Levels <x–y>. Context line used: "<role / decision / stakes>" Findings kept for action: <n of total> (paste the report or link to it) Assumptions — verified / still open: <n> / <n> Questions — answered / assigned / open: <n> / <n> / <n> Challenger (CRITICAL only): <name, other than the author>
Question ownership
The questions are the deliverable · treat them as work itemsAnswer 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 failure modes 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 30-day pilot
One team of 5–15 · one decision type · one tool routePick 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 record 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 pilot 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 records in the decision file. Baseline for metric 2. |
| 2 | Apply the “Riftveil before review” rule to the pilot decision type only. Owners assigned to questions. | Reviewers report on review time and quality. |
| 3 | Add a second decision type, or raise to HIGH stakes. Run one CRITICAL with a named challenger if one occurs. | Metrics 1–4 collected. |
| 4 | Review 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 record. |
Five adoption metrics
Weekly during the pilot, monthly afterwards · simple enough to count by hand- Metric 1CoverageShare of MODERATE-and-above AI-assisted outputs that reached review with a record attached. Target by week 4: above 80 % for the pilot decision type.
- Metric 2Assumptions caught before the decisionUnstated assumptions surfaced that the author confirms they had not considered. Track the average per record. If it trends to zero, the outputs are trivial or nobody reads the records.
- Metric 3Questions closed before the decisionShare of questions answered or explicitly parked, with a reason, before the decision was taken. Target: above 70 %.
- Metric 4Decisions changed or delayedDecisions where a finding, assumption or question changed the decision, its timing or its scope. This is the value metric. One per month on HIGH stakes pays for the pilot.
- Metric 5Review cycle timeMedian time from “output ready” to “approved”, before and during the pilot. Expect a small rise in weeks 1–2 and a drop by week 4, as reviewers receive pre-challenged material.
Eight anti-patterns
What a rollout looks like when it is failing- 1Running it on trivia. A record on a two-line message trains people to skim records. Use the triage table; LOW is optional.
- 2Treating the record as a verdict. “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 record that cannot end on a verdict — and puts a human verifier on every assumption. It mitigates; it does not remove.
- 4Editing the protocol to be nicer. Someone adds “start with what is good about the output”. Rule 1 dies and the record 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 role, decision and stakes, the protocol guesses and defaults to MODERATE. A CRITICAL submission triaged as MODERATE never gets the pre-mortem.
- 8Keeping the record and losing the answers. A record 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 tiersThis page condenses the operating model. The full rollout guide in the Pro Kit adds the platform setups (Claude Project, Custom GPT, Copilot agent, Gemini Gem, API), the three standard tests, the thirty-minute onboarding script, the five-minute quickstart, the JSON report schema for the decision file, and a one-paragraph team announcement to copy and send.