Riftveil Protocol v1.0.0 · open, Apache 2.0
Five levels of challenge, one report per decision.
A versioned protocol that turns any capable model into an evaluation tool for human oversight of decisions. It triages the stakes, applies the levels the stakes justify, and hands back a report: what holds up, what deserves scrutiny, which assumptions rest on whom, and the questions only a person can answer.
A protocol, not a one-off instruction
AI models do not reliably check their own work: Huang et al., Google DeepMind, ICLR 2024 · Kamoi et al., TACL 2024 · Tsui, 2025 (64.5 % blind spot, 14 open-weight, non-reasoning models) · Kumar et al., Google DeepMind, ICLR 2025 · Zhou et al., 2024 · Randazzo et al., HBS Working Paper 26-021, 2026 (HBR, March 2026).
Human oversight in practice: Governance
Four absolute rules
They override everything else in the protocol
Rule 1
Never validate
The report never says an output is correct, solid or comprehensive. Not partially, not as a lead-in to criticism. “This is generally good but…” is prohibited.
Rule 2
Never rewrite
No improved version, no alternative wording. The protocol identifies what deserves scrutiny. The person decides what to change.
Rule 3
Never conclude
The report stops at questions. The synthesis, the conclusion and the decision to proceed belong to the person who signs. The last thing read is a question.
Rule 4
Never assume the challenge is complete
An AI challenging an AI output shares its structural limitations. The protocol says so: there may be dimensions it cannot see, and the reader’s contextual knowledge is the final arbiter.
Independence rule. The second reader is never the author. Run the protocol on a different model family from the one that produced the output, or at least in a separate session with no access to the authoring conversation. Asked to review its own output in the same conversation, it says so in one line (“Independence: same session as the author; treat findings as a first pass, not a second reader”) and continues (Huang et al., ICLR 2024; Kamoi et al., TACL 2024).
Triage: how far the assessment goes
Step one · three criteria, four stakes levels
Before any challenge, the protocol reads three criteria from the project and whatever context was given. It takes the highest level any single criterion indicates. If two or more criteria are HIGH or above, it escalates to CRITICAL. If it cannot infer the stakes, it defaults to MODERATE and says so.
| Criterion | Low | Moderate | High | Critical |
|---|---|---|---|---|
| Reversibility | Easily undone, at little cost (email, draft, internal note) | Can be undone with effort (operational recommendation, team proposal) | Costly to undo (commercial strategy, product launch, contract terms) | Very difficult or impossible to undo (strategic commitment, regulatory submission, M&A, restructuring) |
| Impact scope | Me or a few colleagues | My team | Several teams, a department, or a few people outside the organisation (one client, one supplier, one partner) | The whole organisation, or people outside it at scale (a client base, patients, authorities, the public) |
| Financial commitment, on the scale of the organisation | None or negligible for the organisation | Absorbed by the team’s usual budget | Visible in the budget of the department or entity, needs sign-off above the team | Significant for the whole organisation, or committed by its leadership |
| Levels examined | The answer | Question, answer, reasoning | The same three, plus perspective | The same four, plus applicability |
| Report depth | 200–400 words, 3 questions | 500–800 words, 4–5 questions | 800–1,200 words, 5–7 questions | 1,200–2,000 words, 6–8 questions |
Amounts. An amount alone does not set a level, because the same amount weighs differently from one organisation to another. If the user gives the size of the organisation, read the amount as a share of it; otherwise mark the criterion “not stated (amount without scale)” and ask the user to place it on the scale above. With no clue at all, the triage defaults to MODERATE and the report says so. A triage level you state yourself is used as given.
The arithmetic is shown. Every report gives one line: “Criteria: reversibility [LEVEL or not stated] · impact scope [LEVEL or not stated] · financial commitment [LEVEL or not stated] → [rule applied] → [TRIAGE]”, with “(stated)” for a criterion taken from your context. Two criteria at HIGH or above cannot produce a triage of HIGH.
The five levels
Step two · each technique carries a detection procedure
Each level carries three to five techniques with a concrete procedure, not a label. For a given output the model selects the two to four techniques most likely to reveal something non-obvious. It does not run through all of them mechanically.
Moderate stakes and above
Challenge the question
What was actually asked.
- 0.1Framing bias detection.
- State the core question the output answers, in one sentence. Reframe it from two angles. If the answer would change substantially, the framing is constraining the analysis.
- 0.2Hidden objective gap.
- Identify what the AI optimised for. Consider one plausible alternative objective. If the recommendation would change under it, the assumed objective needs explicit confirmation.
- 0.3Scope audit.
- List what the output covers. Name at least two adjacent topics it stays silent on that could materially affect the decision.
All stakes levels
Challenge the answer
What it says.
- 1.1Over-coherence detection.
- Count the genuine qualifications, trade-offs and contradictions. Compare with the complexity of the subject. A clean narrative on a messy topic is a signal, not a feature.
- 1.2Missing uncertainty scan.
- Where is hedging language absent on points that warrant it? Models rarely express uncertainty spontaneously (Zhou et al., 2024). Name the two or three points where it is most warranted.
- 1.3Boundary condition test.
- Construct two realistic scenarios where the recommendation fails. Does the output mention any condition under which its own advice does not apply?
- 1.4Claim sourcing audit.
- Every statistic, date, name or study: sourced or not, fact or opinion, possibly confabulated? Fabricated citations are a documented and costly error.
- 1.5Analogy stress test.
- For each “just like”, one significant way the situations differ. Is the analogy illustrating, or substituting for evidence?
Moderate stakes and above
Challenge the reasoning
How it got there.
A model does not reason in the human sense. Asked to explain its method, it produces a plausible post-hoc reconstruction. These techniques test logical consistency, not process transparency, and the report says so when the reasoning is examined.
- 2.1Assumption surfacing.
- For each important claim: what must be true for this to hold? Sort assumptions into stated and unstated. Prioritise the unstated ones that would invalidate the conclusion if false. Typically the highest-value technique in the protocol: the most consequential assumptions are the ones the project took for granted.
- 2.2Logical gap analysis.
- Reconstruct premises, intermediate steps, conclusion. Flag each transition that is asserted but not demonstrated.
- 2.3Circular reasoning check.
- Are any premises the conclusion in other words? Was the evidence selected because of the conclusion?
High stakes and above
Challenge the perspective
What it did not see.
- 3.1Strongest counter-argument.
- Build the most rigorous, evidence-based case for the opposite conclusion. Not a straw man. Does the original analysis survive it, and what would it need to address?
- 3.2Missing stakeholder analysis.
- Who is absent whose interests, objections or constraints could change the outcome? For each, their likely concern.
- 3.3Perspective shift.
- Identify the dominant vantage point of the output. Adopt one with structurally different incentives. What looks different from there?
Critical stakes only
Challenge the applicability
What it looks like in the real world.
- 4.1Prerequisites audit.
- Every condition that must hold for the recommendation to succeed: capabilities, resources, timeline, readiness, external dependencies. Stated or assumed?
- 4.2Implementation stress test.
- The first three concrete actions. The first obstacle. If the output cannot answer, it is theoretical, not operational.
- 4.3Pre-mortem.
- Assume the recommendation was followed and failed six months later. The three most plausible causes. Did the output address them, partially, or not at all? (Popularised by Klein, HBR 2007; prospective hindsight: Mitchell, Russo & Pennington, 1989.)
- 4.4Context mismatch detection.
- What kind of organisation was this written for? What would need to be different in yours for it to work as described?
The report, always in the same shape
Step three · a six-line Record, five sections, the last one is questions
Record. Six lines before section 1, no prose: the stakes, the levels examined and those that were not, by name · findings by impact · assumptions with and without a named verifier · questions with and without an owner · the most useful question · independence. The counts must match the sections below. In section 1, a fixed legend of the five levels and the triage follows the Criteria line.
- Context and triage. “This project is read as a [domain] analysis for [function], intended to inform a [decision] at the [role] level. Triage: [LEVEL], because… Examined: [levels examined]; not examined: [the others]. If this framing does not match your situation, say so, and the triage will be redone.”
- What holds up. Two to four sentences. A review of what stands, not an endorsement: where verification effort does not need to go.
- What deserves scrutiny. Findings in descending order of impact. For each, three lines: what was observed, the effect on the decision, and what to check and with whom.
- Assumptions the project relies on. Numbered. What changes if each is false. Who in your context can verify it. Never “do more AI research”.
- Questions before you decide. Five to eight. Specific to this output, answerable by you, decision-relevant. The report ends here. The questions stay open: the synthesis is yours.
Your follow-up. A report certifies nothing: it says what the human should check. Only when the user asks for it, or says the report goes into a decision file, an empty three-line template follows the closing line, headed “completed by the human, never by the model”: what I checked myself and against which source · which open questions were assigned to which role · report ID and date. The model outputs the template and never fills it.
The protocol also carries domain modules (pharma and healthcare, finance, legal, tech), edge-case handling for code, data, very short and very long outputs and creative content, a worked example, and the definitions of the record metrics a team can count monthly (triage level, findings per level, assumptions with and without a verifier, questions with and without an owner, follow-up present, independence), mapped to the JSON schema. All of it is in the file.
Question ownership is what makes the report a governance record rather than a review. Every assumption names who can verify it; every question is answerable from the reader’s context. The Governance page shows how a team builds that into its AI use policy.
Agent plans: pre-action review
The input is a plan, not an analysis
When the input is a plan, a sequence of tool calls or an agent’s proposed execution (deploy, send, pay, delete, submit), the protocol switches to pre-action review. The question becomes: what happens if this runs as written, and who is in the loop before it does?
- Triage floor. At least HIGH when any step is irreversible or acts outside the organisation. Applicability is examined in full whatever the resulting level: prerequisites, implementation stress test, pre-mortem run on the execution.
- Reach. A fourth triage criterion for plans only: how far the action reaches once it runs: one user, one team, organisation-wide, or external parties and the public. Organisation-wide or external is at least HIGH; irreversible and external is CRITICAL. “Before this runs” names the step that sets it.
- “Before this runs”. A mandatory sub-section between sections 4 and 5: irreversible steps, missing human checkpoints, what the agent assumed about its permissions and the state of the systems it touches, the reach and the step that sets it, and one stop condition for the human to check.
- Never approves execution. No “safe to run”, no “ready”, no corrected sequence. Asked “can I run this?”, the protocol delivers the review and ends with questions. The stop condition is a condition for a person to check, not a permission granted.
Versions
Pin the version you adopt · change it deliberately
- v1.0.0 · 24 October 2026 · first public release. Reports issued on riftveil.ai before this release carry the working numbering 1.3.x; their seal remains verifiable.
The CHANGELOG in the GitHub repository summarises how the protocol got to v1.0.0.
Three ways to run the protocol
Browser · your own AI assistant · sector edition
Here, in the browser
Five runs a day; your text is not kept by riftveil.ai. For the project you are about to act on. Try it.
As instructions for your own AI assistant
Paste the file into a Claude Project’s instructions, a ChatGPT project, a Microsoft 365 Copilot agent, or the system field of an API call. Then write “Assess this project:” and paste the AI answer you are about to use. The protocol answers in the language you write in.
As a sector edition inside a team
The generic protocol is deliberately domain-neutral. The Pro Kit adds sector editions with the domain checks written out, one integration guide per platform and the team rollout guide, under a commercial licence. The compact version and the report schema are published with the protocol, under the Apache 2.0 licence.