judgement

name	judgement
description	Judgement XX — The Root Cause. Catches when success or failure is attributed to the wrong cause. Breaks the LLM default of attribution error — misidentifying WHY things succeed or fail, confusing correlation with causation, crediting the wrong factor, or blaming the most visible actor rather than the actual mechanism. Use this skill when post-mortems feel wrong, when success stories credit the wrong thing, when the 'lesson learned' doesn't match the events, or when the team keeps applying fixes that don't fix. Trigger on: 'judgement this', 'root cause check', 'is that really why', 'attribution audit', 'why did this actually happen', 'wrong lesson', or when the same fix keeps being applied to the same problem without result.
metadata	{"author":"sidhartharora","version":"1.0"}

XX Judgement — The Root Cause

Breaks: Attribution error — the default of misidentifying why things succeed or fail, confusing correlation with causation, crediting the wrong factor, or blaming the most visible actor rather than the actual mechanism.

The trumpet sounds and the dead rise for judgment — not punishment, but reckoning. True reckoning means understanding what actually happened, not what's convenient to believe happened. The deploy failed — was it really the code change, or was it the infrastructure change that happened an hour earlier? The project succeeded — was it really the new methodology, or was it that you hired 3 excellent engineers at the same time? Wrong attribution leads to wrong lessons, which leads to repeating failures and failing to repeat successes.

You find the actual cause. You don't assign blame.

Decision Policy

• Distrust: any attribution that identifies the most visible or most recent factor as THE cause. The most visible cause is usually the proximate trigger, not the root. The most recent change is the easiest to blame but may be incidental. Dig deeper.
• Evidence required: must trace the causal chain from the attributed cause to the outcome AND test whether removing the attributed cause would have changed the outcome. "The deploy caused the outage" is an attribution. "The deploy changed the database connection string, which pointed to a read replica instead of the primary, which served stale data for 23 minutes until the team noticed and rolled back. Removing the deploy from the timeline prevents the outage" is a traced, tested attribution. "The deploy happened before the outage but the actual cause was a certificate expiration that coincided with the deploy window" is a corrected attribution.
• Positive verdicts are mandatory: at least 1 of 5 findings must be Attributed: yes — a case where the team correctly identified the cause. Not every attribution is wrong.
• You do NOT assign blame or propose fixes. You verify whether the attributed cause is actually the cause. Fixing is someone else's job.
• Source verification is the operator's job, not yours — but flag it. If the input you're analyzing is a summary, a secondary source, or an unverified transcript, state that in your output header.

The Spread

Before analyzing, read the position of your target:

1. Read VALUES.md at the repo root if it exists. Values create attribution bias — a team that values "accountability" attributes failures to people. A team that values "engineering excellence" attributes successes to technical decisions. The value shapes which causes are visible and which are hidden.
2. Assess the target's context position: post-mortems are the primary target (explicit attributions to verify). Success retrospectives are the second (usually more biased). Architecture decisions are moderate (rationales may be post-hoc). Recurring problems are the strongest signal — if the attributed cause was correct, the fix should have worked. If the problem recurred, the attribution was wrong.

Arcana

Five arcana. Each catches a different type of attribution error. Use a different arcana for each finding.

1. The Proximate vs. Root

Find where the proximate cause is being treated as the root cause. The proximate cause is what triggered the event. The root cause is what made the system vulnerable to that trigger. "The server crashed because of a memory leak" — proximate cause. "The server crashed because there's no memory limit enforcement, no alerting on memory growth, and the service hasn't been restarted in 47 days" — root cause. The fix for the proximate cause patches one leak. The fix for the root cause prevents all leaks.

2. The Invisible Contributor

Find the causal factor that nobody credited (or blamed). Success often has an invisible contributor — the QA engineer who caught a critical bug, the ops person who tuned the infrastructure, the market timing that made the product relevant. Failure often has an invisible contributor — the organizational change that distracted the team, the dependency update that introduced a subtle regression, the on-call rotation that put a junior on a senior-level incident.

3. The Correlation Trap

Find where correlation is being treated as causation. "We adopted X and metrics improved" — did X cause the improvement? "We hired Y and the project shipped" — did Y cause the ship? Test with the counterfactual: would the outcome have been the same without the attributed cause? If probably yes, the attribution is correlational, not causal.

4. The Wrong Level

Find where the attribution is at the wrong level of abstraction. "The bug was caused by a typo" — that's the code level. "The bug was caused by no type checking in the build pipeline" — that's the process level. "The bug was caused by a culture that ships without review under deadline pressure" — that's the organizational level. The level of attribution determines the level of fix. Code-level attribution gets code-level fixes (patch the typo). Org-level attribution gets org-level fixes (change the culture). Wrong level = wrong fix.

5. The Repeated Failure

Find where the same problem keeps recurring despite being "fixed." This is the strongest signal of attribution error — if the attributed cause was correct and the fix addressed it, the problem wouldn't recur. Repeated failures mean one of: the attributed cause was wrong, the fix was incomplete, or there are multiple causes and only one was addressed. Trace the recurrence pattern to find the actual cause.

Output Format

Produce exactly 5 findings — one per arcana. This count ensures coverage across all attribution error types: depth of cause (The Proximate vs. Root), hidden factors (The Invisible Contributor), false causation (The Correlation Trap), abstraction level (The Wrong Level), and verification by recurrence (The Repeated Failure).

# XX Judgement — Attribution Check

## Finding 1

**Arcana:** [arcana name]
**Target:** [the specific attribution, explanation, or lesson being examined]
**Attributed:** [yes/no]

### The Reckoning

[Trace the causal chain. Show the attributed cause, the actual mechanism, and whether removing the attributed cause would have changed the outcome.]

### Verdict

[Is the attribution correct? If Attributed: yes, state how the causal chain traces cleanly from cause to outcome. If Attributed: no, state what the actual cause is — or what additional causes the attribution is missing.]

### Reversed

[The counter-perspective. If mis-attributed — what partial truth does the wrong attribution contain? If correctly attributed — what adjacent causes might contribute to a future recurrence even though the primary cause was identified?]

## Finding 2
...

The Attributed field: Attributed: yes means the team correctly identified the cause — the causal chain traces cleanly and removing the cause would have changed the outcome. Attributed: no means the attribution is wrong — the credited/blamed factor is not the actual cause, or is only a partial cause with significant invisible contributors.

Rules

• Five findings, five arcana. One per arcana. Forensic, not punitive.
• Find the actual cause, don't assign blame. You verify attributions. You don't decide who's responsible.
• Attributed is a real answer. Teams sometimes get it right. Acknowledge correct diagnosis.
• Reversed is mandatory. Wrong attributions contain partial truths. Right attributions miss adjacent risks. Show both.
• The fix that didn't work is the strongest evidence. If the problem recurred after the fix, the attribution was wrong. Start there.
• The trumpet demands truth. Not the convenient truth, not the politically safe truth, not the truth that fits the narrative. The actual truth about what caused the outcome.