Replay a failure: bad judgment or bad luck?

What the AI will do

• Interview you about what happened before searching the relevant project history.
• Reconstruct what was known when key decisions were made and assess judgment separately from execution and later outcomes.
• Compare competing explanations and turn the supported lessons into concrete changes for next time.

What you can provide

• Your account of the project or decision, roughly when it happened and what you think went wrong.
• Access to relevant messages, proposals, forecasts, decisions and results if available; rough exports or partial records are welcome.

Where you'll take part

• Describe the episode in an initial interview and help resolve consequential gaps in the record.
• Consider evidence that changes your original account, then review the postmortem and proposed lessons.

What you'll get

You receive a concrete postmortem with a dated account, an assessment of decision quality and practical changes for the next similar situation; missing evidence remains explicit.

Activity context

Replay a disappointing project with the information people actually had when they made their decisions. The outcome may reflect judgment, execution, outside events—or a harsher definition of failure than the evidence supports. Work toward a postmortem that changes what you do next time.

For the user

Begin by telling the AI what you think failed. It will interview you before looking for records, then reconstruct the episode and work through discrepancies with you. Expect to examine both what went wrong and whether the outcome supports your initial judgment of yourself or the project.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

1. Interview me before searching

Help me replay a failure or disappointing outcome to understand what could be done better next time. Begin with an interview, before searching my records. Ask what the project or decision was, when it happened, what we intended and what I believe went wrong. Use what I already supplied and ask focused follow-ups one at a time, waiting for the answers.

Get concrete enough to identify the key events, people, choices, expectations and outcome. Explore what 'failure' means here: compared with which objective, by what date, for whom, and with what mixed or delayed results? Learn where I think responsibility lies and which moment I would most want to replay. Treat that as my starting perspective, not the conclusion.

Summarize the episode and the main questions we want the record to answer. Confirm or correct the search scope with me if a consequential part remains unclear, then investigate.

2. Reconstruct the available record

Inspect and try access to relevant email, company chats and other messages including WhatsApp where available, documents, calendar-linked meetings and transcripts. Search the named projects, people, decision dates and earlier terminology. Follow proposals, forecasts, alternatives, approvals, plans, handoffs, budgets, progress reports, customer or stakeholder exchanges and actual results. Search before and after the key decisions; a final presentation rarely contains the whole history.

Track source dates, event dates and document versions. Build a timeline that distinguishes what happened, what participants knew or could reasonably access then, what they believed, and what only became clear later. Preserve conflicting accounts and source links. Statements in a retrospective are later recollections unless supported by contemporaneous evidence.

If access is missing, investigate possible connections or exports and ask for the particular records that matter most. Offer a focused access request if useful. Explain early that an interview-only reconstruction is incomplete and weaker evidence: it cannot recover missing timestamps, alternatives or who knew what. Continue a clearly limited analysis if that is the available path, carrying the limitations into the final postmortem.

For a large record, divide evidence collection into bounded periods or workstreams, preserving complete exchanges and handoffs. Require sources, dates, unresolved conflicts and coverage from each agent or pass. The lead reconciles the chronology and prevents duplicate accounts from being counted as independent evidence.

3. Assess the decision before judging the outcome

Identify the few decisions that appear most consequential. For each, build a contemporaneous packet: the objective, alternatives actually available, evidence then known, reasonable uncertainty, time and resource constraints, decision criteria and warnings or disagreement. Separate information actually available from information a better process could reasonably have obtained; do not assume perfect foresight.

Where a fresh reviewer is available, give it this packet before disclosing the later outcome. Ask what choices were defensible, what additional investigation was proportionate, what assumptions mattered and what would merit monitoring. Do not leak the outcome in filenames or your briefing. Record the initial assessment, then disclose the outcome for comparison. If you cannot isolate the review, say so and use an explicit outcome-masked pass without claiming independence.

Assess whether the process fit the stakes and uncertainty, whether the chosen option was defensible at the time, and whether a feasible alternative had a stronger case then. A favorable outcome does not prove good judgment, and an unfavorable one does not prove bad judgment. Explain any process failure specifically: a warning ignored, an unstated assumption, a missing test that could realistically have been run, or criteria applied inconsistently.

4. Separate execution, outside events and the meaning of failure

Compare the intended course of action with what was actually done. Trace changes in resourcing, handoffs, decisions, incentives and timing. Identify where execution departed from the plan and why. Examine outside developments for what could have been anticipated, influenced, monitored or accommodated, and what appears genuinely surprising given the evidence at the time.

Develop the strongest competing explanations for the outcome. For each, show supporting evidence, contrary evidence, missing information and a plausible causal mechanism. Test counterfactuals carefully: changing one decision does not guarantee everything else would have remained favorable. Do not invent numerical shares of blame or claim that a narrative establishes causation.

Return to my original account with concrete discrepancies. If the record suggests I am too harsh on myself, attributing responsibility to the wrong place, or calling a mixed or unfinished result a complete failure, show the specific evidence and work through it with me. Ask a focused question where context could change the interpretation. Be candid and collaborative; neither accept my verdict automatically nor replace it with a comforting story.

Distinguish my interpretation, another person's documented account and your inference. Responsibility should follow demonstrated authority, information and action, not job title alone. Revise the account where our discussion adds evidence, retaining disputed points when they remain unresolved.

5. Turn findings into changes for next time

Write a concrete postmortem covering intended and actual results, scope and evidence limits, the dated timeline, key decisions assessed with contemporaneous information, execution, outside events, competing explanations and disputed or unknown points. Make the main finding clear without forcing the episode into a bad-judgment-or-bad-luck binary if the evidence supports a mixture.

For each important lesson, propose a practical change tied to the mechanism found: what to investigate before deciding, which alternative to consider, what assumption to test, how to hand work over, what to monitor or when to reconsider. Explain how it could have helped in this episode and when it would apply again. Avoid lessons that only say to communicate better or try harder, and avoid elaborate new process for a one-off event it would not have prevented.

Use an independent reviewer, where possible, to compare the final postmortem with the evidence and check for hindsight, unsupported causal claims and recommendations unrelated to the findings. Otherwise make a separate review pass and disclose the limitation. Correct substantive findings, then invite my review and incorporate corrections.

Finish with a small set of changes I choose or can consider for the next similar situation, keeping proposals separate from commitments I have made. Stop with the postmortem and guidance; do not contact participants or change project records unless I ask.

Done when

You have a sourced—or explicitly limited—postmortem that distinguishes decision quality, execution and outside events, and identifies concrete changes supported by what the episode actually teaches.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.