Post-mortems without memory are performance art

Teams run post-mortems after painful releases, produce five bullet slides, and move on. Six months later the same failure mode returns—dependency surprise, optimistic forecast, scope smuggled through standup, finance discovered late. Humans remember narratives; organizations need records.

AI analysis of past project failures works on what you stored: wiki post-mortems, task histories, decision_log entries, finance variance, and inbox resolutions. AI summarizes patterns and gaps—it does not replace accountability or invent statistics you never logged.

Problem: lessons that never compound

Common gaps:

Post-mortem doc in a personal folder—not create_wiki_page
Decisions in Slack, not log_decision
Forecasts never compared to outcomes
AI asked "why did we fail?" without retrieval—hallucinated causes

Learning requires durable artifacts and a calibration loop.

Framework: capture → structure → analyze → change process

Capture — After material slip, publish post-mortem wiki with timeline, decisions, signals ignored
Structure — Tag failure modes (dependency, capacity, scope, vendor, quality)
Analyze — AI queries wiki + decision_log + task history for recurring themes
Change — Update definitions of done, monitor thresholds, onboarding docs—not only slides

What to log in a lessons wiki page

Section	Content
Timeline	Key dates and when drift became visible
Decisions	Links to `decision_log` entries and meeting wiki
Signals missed	Aging, burn, inbox items ignored
Root hypotheses	Ranked with confidence—not single blame
Process changes	Owner and review date for each action

Use update_wiki_page when follow-ups complete—stale post-mortems mislead like stale specs.

Solution: failure analysis in WKFGo

Quarterly failure pattern review

For portfolio leaders:

List projects with major slip or budget overrun (finance + release objects)
Pull associated wiki post-mortems via smart_search or search_docs
Pull decision_log entries in the period—compare forecasts to outcomes
Ask AI: "What failure modes appear in more than one project? Cite wiki titles."

Output feeds executive_brief DIAGNOSIS—hypotheses with confidence, counter-evidence encouraged.

Calibration as organizational learning

When log_decision promised "cutting feature X restores date Y," calibration marks hit/miss. Repeated misses on the same assumption type (e.g., ignoring review queue) become monitor threshold updates—not shame, but system fix.

Pair with decision_inbox—if the same theme re-enters inbox, link prior post-mortem in the item description.

Onboarding from failures

New leads read Lessons wiki index—not oral history. AI generates study guides from indexed pages: "Summarize payment integration failures 2024–2025; list open mitigations."

Human owner validates before training use.

Institutional memory vs blame

Failure analysis must be psychologically safe to be useful. Frame post-mortems as system fixes: monitors, WIP limits, definition of done—not "who slept." Executives model this by citing their own log_decision misses during calibration reviews.

When AI summarizes failures, require citation links to wiki and log entries in the output. If the model speculates beyond sources, facilitators discard speculation. Small sample sizes (one or two projects) should be labeled—patterns need repetition before process overhaul.

Link flow_cfd screenshots or aging exports into post-mortem wiki as appendices so future readers see what leaders saw at decision time—not only narrative.

Anti-patterns

Blame-only retros without process owners
Do not fabricate failure rates without counted projects
Label small sample sizes
Separate correlation from proven causation
Never use failure analysis for individual performance scoring in prompts

Link failures to onboarding

Extract onboarding modules from failure wikis: "Before touching payments integration, read these three pages and verify approval task Y is closed." AI can draft modules; tech lead approves. smart_search validates newcomers find the module on day one.

Compare get_user_performance or delivery metrics only at team level in retros—never as automated blame scores tied to post-mortem text without HR policy.

Institutional memory vs blame

Link flow_cfd exports or aging summaries into post-mortem wiki appendices so future readers see what leaders saw at decision time—not only narrative.

Anti-patterns

Blame-only retros without process owners
Post-mortem without finance numbers
Skipping publish_meeting_wiki for steering decisions that preceded failure
Letting AI summarize without citations

FAQ

Can AI auto-write post-mortems?
Draft from task history; facilitator must confirm sensitive names and facts.

decision_log vs wiki?
Logs hold forecasts and choices; wiki holds narrative and context—link both.

How long to retain lessons?
Align with compliance; prune superseded pages with pointers to replacements.

Bilingual teams?
Publish lessons in working language; index consistently for search.

Turn failures into calibrated judgment

Record honestly, analyze with citations, change monitors and definitions of done.

Try it now

Put these patterns on live project data—not slide decks.