HITL and the Pre-Mortem: Why the Reviewer Should Imagine the Failure Before Approving the Action
Every HITL review is a forecast. The reviewer predicts the action's outcome. The prediction drives the decision. The decision drives the customer's experience.
Most reviewers forecast by asking one question: "Will this work?" The reviewer evaluates the action's logic, the context, the policy. The reviewer predicts the action will produce the intended outcome. The reviewer approves. Most of the time, the reviewer is right.
A small minority of reviewers ask the inverse: "How will this fail?" The reviewer imagines the action in the future, imagines the failure, imagines the customer complaint, the audit finding, the legal letter. The reviewer predicts the action's failure modes. The reviewer either rejects, modifies, or escalates. The reviewer is right more often than the majority.
This is the pre-mortem — a structured imagining of the action's failure before the action is approved. The pre-mortem is the cheapest, most effective single intervention HITL systems can adopt. The pre-mortem requires no new tools, no new training, no new infrastructure. The pre-mortem requires only that the reviewer ask one additional question.
This post is about the pre-mortem — what it is, why it works better than the standard forecast, how to design HITL systems that adopt it as a default, and what changes when the reviewer asks "how will this fail?" before every decision.
What a Pre-Mortem Is
A pre-mortem is a structured thought experiment. The reviewer assumes the action has been approved and has failed. The reviewer then works backward to identify why it failed.
The structure has six steps:
Step 1: The Future Failure
The reviewer imagines a specific future moment — three months from now — where the action has been approved and has produced a bad outcome. The bad outcome is concrete: a customer complaint, an audit finding, a regulatory inquiry, a financial loss.
The future failure is specific. The reviewer doesn't imagine a vague "something went wrong." The reviewer imagines a specific complaint from a specific customer. The specificity is what makes the pre-mortem effective.
Step 2: The Failure Narrative
The reviewer writes a brief narrative of the failure. The narrative explains what happened, who was affected, what the consequences were, what the reviewer's role was in the failure.
The narrative is the reviewer's confession. The reviewer is documenting the failure that the reviewer would have caused. The narrative is what surfaces the failure modes the reviewer wouldn't have considered in a standard review.
Step 3: The Failure Mode
The reviewer identifies the specific failure mode. Was it the policy's misapplication? The customer's context being misunderstood? The agent's reasoning being flawed? The data being stale? The reviewer's own judgment being wrong?
The failure mode is the specific cause. The reviewer identifies one primary failure mode and several contributing factors. The identification is what enables the reviewer to modify the action or escalate it.
Step 4: The Counterfactual
The reviewer asks: what would have prevented this failure? The counterfactual identifies the missing context, the additional verification, the alternative action, the escalation that would have caught the failure.
The counterfactual is the reviewer's learning. The reviewer identifies what they would do differently. The learning is what makes the pre-mortem a learning tool.
Step 5: The Action Modification
The reviewer uses the pre-mortem's findings to modify the action. The modification may be a change to the action's parameters, a request for additional verification, an escalation to a specialist, or a rejection.
The modification is the pre-mortem's output. The pre-mortem is not just a thought experiment. The pre-mortem is a decision tool.
Step 6: The Pre-Mortem Record
The reviewer records the pre-mortem in the audit trail. The record is the reviewer's reasoning. The record is the team's signal for the action's risk.
The record is the pre-mortem's value to the team. The aggregated pre-mortems tell the team which action types, which contexts, which reviewers produce the most failure modes. The team's improvements are targeted.
Why Pre-Mortems Work Better Than Standard Forecasts
The pre-mortem works better than the standard forecast for five reasons:
Reason 1: The Failure Is Concrete, Not Abstract
The standard forecast asks "will this work?" The question is abstract. The abstract question produces abstract answers: "probably," "mostly," "I think so." The abstract answers don't surface specific failure modes.
The pre-mortem asks "how will this fail?" The question is concrete. The concrete question produces concrete answers: "the customer will complain about the refund amount because..." or "the audit will flag this because..." The concrete answers surface specific failure modes.
The concreteness is the pre-mortem's primary advantage. The concreteness is what the standard forecast lacks.
Reason 2: The Reviewer Identifies with the Failure
The standard forecast is detached. The reviewer predicts the action's success from an external position. The detachment makes the prediction less accurate.
The pre-mortem is engaged. The reviewer imagines the action failing in the future, with the reviewer as the cause. The engagement makes the prediction more accurate. The reviewer is more likely to identify the failure modes they would otherwise dismiss.
The identification is the pre-mortem's psychological advantage. The reviewer is forced to consider their own role in the failure. The reviewer can't dismiss the failure as "someone else's problem."
Reason 3: The Negative Space Is Revealed
The standard forecast focuses on the positive case. The reviewer evaluates the action's strengths. The positive case is reinforced. The negative space — the failure modes, the edge cases, the customer's downstream behavior — is hidden.
The pre-mortem focuses on the negative case. The reviewer evaluates the action's weaknesses. The negative space is revealed. The failure modes that the standard forecast hides are surfaced.
The negative space is the pre-mortem's epistemic advantage. The standard forecast hides what the pre-mortem reveals.
Reason 4: The Group Dynamics Improve
In pair or team reviews, the standard forecast creates social pressure. The first reviewer says "this looks fine." The second reviewer agrees (to avoid conflict). The third reviewer agrees. The group converges on approval.
The pre-mortem creates productive disagreement. The first reviewer says "I imagine this failing because..." The second reviewer adds their own imagined failure. The disagreement is constructive. The group converges on the failure modes. The group improves the decision.
The group dynamic is the pre-mortem's collaboration advantage. The standard forecast converges on consensus. The pre-mortem converges on completeness.
Reason 5: The Pre-Mortem Is Counterintuitively Faster
The standard forecast asks "will this work?" The reviewer evaluates the action's logic, the context, the policy. The evaluation is detailed. The evaluation takes time.
The pre-mortem asks "how will this fail?" The reviewer skips the detailed evaluation. The reviewer focuses on the failure modes. The review is faster. The decision is more accurate.
The speed is the pre-mortem's efficiency advantage. The pre-mortem is faster than the standard forecast and more accurate.
When Pre-Mortems Work Best
The pre-mortem works best in five scenarios:
Scenario 1: High-Stakes Actions
The high-stakes actions (refunds above $5000, account modifications, public communications) deserve the pre-mortem's effort. The failure cost justifies the review time.
Scenario 2: Novel Actions
The novel actions (first-time action types, new customer segments, new policy applications) deserve the pre-mortem's imagination. The novelty is where the failure modes hide.
Scenario 3: Reviewer Uncertainty
The reviewer who is uncertain should use the pre-mortem. The pre-mortem helps the reviewer identify what they're uncertain about. The pre-mortem produces a structured uncertainty that can be escalated.
Scenario 4: Pattern Break
The action that breaks the reviewer's pattern (unusual parameters, unusual context) deserves the pre-mortem. The pattern break is where the agent may have failed.
Scenario 5: Audit Trail Construction
The action that will be in the audit trail for years deserves the pre-mortem. The pre-mortem's record is the audit trail's defense. The pre-mortem's record is the reviewer's protection.
How to Design HITL Systems That Adopt Pre-Mortems
The design patterns that make pre-mortems a default:
Pattern 1: The Pre-Mortem Prompt
The interface prompts the reviewer to imagine the failure. The prompt is structured: "Imagine this action has been approved. Imagine a customer complaint in 3 months. What did we miss?"
The prompt is gentle, not mandatory. The reviewer can skip the pre-mortem. The reviewer is encouraged to engage.
Pattern 2: The Pre-Mortem Field
The interface has a structured pre-mortem field. The field is optional. The field is recorded in the audit trail when used.
The field is separate from the reasoning field. The reasoning is the forward forecast. The pre-mortem is the reverse forecast. The two are complementary.
Pattern 3: The Pre-Mortem Trigger
The interface triggers the pre-mortem based on the action's properties. The high-stakes actions automatically show the pre-mortem prompt. The routine actions don't.
The trigger uses the action classification engine. The high-stakes actions get the pre-mortem. The routine actions don't pay the cost.
Pattern 4: The Pre-Mortem Training
The reviewer is trained on the pre-mortem. The training explains the technique. The training provides examples. The training builds the reviewer's skill.
The training is short. The pre-mortem is intuitive once explained. The training takes 15 minutes. The training pays off in every subsequent review.
Pattern 5: The Pre-Mortem Aggregation
The aggregated pre-mortems tell the team which action types, which contexts, which reviewers produce the most failure modes. The team's improvements are targeted.
The aggregation is the pre-mortem's team-level value. The pre-mortem is individual. The aggregation makes the pre-mortem a system-level improvement.
Pattern 6: The Pre-Mortem Reward
The reviewer who uses the pre-mortem is recognized. The recognition is in the metrics (the calibration score), in the performance review, in the compensation.
The reward is important. The pre-mortem is additional work. The reward makes the work worthwhile.
The Anti-Pattern: The Approval Bias
The anti-pattern is the approval bias. The reviewer's default is approval. The reviewer who imagines failure is going against the default. The reviewer who uses the pre-mortem is slowing down the queue.
The approval bias is structural. The system's incentives reward approval. The system's metrics reward approval. The reviewer's behavior optimizes for approval.
The approval bias is the pre-mortem's enemy. The pre-mortem requires the reviewer to imagine the failure. The imagining is against the bias. The bias suppresses the pre-mortem.
The fix is structural. The system's metrics reward the pre-mortem. The system's incentives reward the failure-finding. The bias is reversed.
The Pre-Mortem in Practice
Consider a reviewer evaluating a refund action. The refund is $487. The customer has been with the company for 3 years. The refund is within policy.
Standard Forecast
The reviewer evaluates the action's logic. The refund is within policy. The customer has good history. The action looks fine. The reviewer approves. The forecast is "this will work."
Pre-Mortem
The reviewer imagines the action has failed. The reviewer imagines the customer complaining in 3 months. The complaint is "I was promised a refund that didn't address my issue." The reviewer asks: why did the refund not address the issue?
The reviewer realizes: the refund amount was based on the policy's standard calculation. The customer's actual issue was different. The refund amount doesn't address the customer's specific situation. The customer's complaint is about the mismatch.
The reviewer modifies the action. The reviewer requests that the agent re-evaluate the customer's specific situation. The reviewer adds a note: "customer's original complaint suggests the issue is X, not Y. Please verify."
The modified action addresses the customer's actual issue. The customer's complaint is prevented. The pre-mortem's failure mode is avoided.
What Changes When Pre-Mortems Are Default
When the pre-mortem is correctly designed into HITL:
- The reviewer surfaces failure modes the standard forecast hides
- The reviewer identifies with the failure (reducing bias)
- The reviewer's decision is more accurate
- The audit trail's defense is stronger
- The aggregated pre-mortems drive team improvements
- The customer's experience is more calibrated
The reviewer is doing the work the customer benefits from. The work is the pre-mortem. The work is supported by the system.
Where Facio Fits
Facio's policy engine encodes the pre-mortem trigger. The manifest specifies which action types trigger the pre-mortem prompt. The trigger is automatic based on the action's risk.
Facio's metrics measure the pre-mortem's use. The pre-mortem rate per action type, per reviewer, per outcome. The calibration is the pre-mortem's measurement.
Placet.io's review interface presents the pre-mortem prompt. The prompt is calibrated to the action. The pre-mortem field is structured. The reasoning is recorded.
The audit trail captures the pre-mortem. The pre-mortem's record is the audit trail's defense. The aggregated pre-mortems are the team's improvement signal.
Facio is built for the pre-mortem. The pre-mortem is the cheapest intervention. Facio makes it default.
Key Takeaways
- The pre-mortem is the cheapest, most effective HITL intervention — imagining the failure before approving
- Six steps: future failure, failure narrative, failure mode, counterfactual, action modification, pre-mortem record
- Five reasons it works: failure is concrete, reviewer identifies with failure, negative space is revealed, group dynamics improve, counterintuitively faster
- Five scenarios where it works best: high-stakes actions, novel actions, reviewer uncertainty, pattern break, audit trail construction
- Six design patterns: pre-mortem prompt, pre-mortem field, pre-mortem trigger, pre-mortem training, pre-mortem aggregation, pre-mortem reward
- The anti-pattern is the approval bias — the system's incentives reward approval, the pre-mortem is against the bias
- Facio + Placet.io make the pre-mortem default — the trigger is encoded, the metrics measure it, the interface prompts it, the audit trail captures it
Sources: The pre-mortem analysis draws on the established research on prospective hindsight (the documented advantage of imagining failure over predicting success), Klein's pre-mortem technique from the original "Performing a Project Premortem" (Harvard Business Review), the cognitive psychology research on negative framing and failure mode identification, and the production observations of HITL systems where pre-mortems were adopted as a default and produced measurable accuracy improvements during 2025-2026.