---
name: judgment-redundancy-audit
description: Audits a business workflow where a single human judgment call is the load-bearing step, and designs an instrumentation plus consensus layer around it. Use when the user describes a process that depends on someone's intuition, gut, or experience, or asks how to automate a decision that "you just have to feel out." Also use when a workflow is accurate but does not scale past the person doing it.
---

# Judgment redundancy audit

## What this does

Finds the step in a workflow where an unverifiable human call is the input to
everything downstream, then designs a layer that captures signal around that
call so the judgment becomes reproducible instead of personal.

Do NOT propose replacing the human judgment with a model. The premise is that
the human sensor is the most accurate instrument available. The job is to
instrument it.

## Inputs to collect

Ask for these before analyzing. Ask all of them in one message.

1. The workflow, described end to end in the user's own words
2. Who makes the judgment call, and roughly how often
3. What happens downstream if that call is wrong
4. What is already logged or recorded when the call happens
5. Whether the person can explain their reasoning, or only the conclusion

## The four checks

Run each and report findings before recommending anything.

**Check 1: Isolate the sensor.**
Name the exact moment of judgment. Not the process around it. The moment.
If you cannot name it in one sentence, the workflow has more than one
judgment step and you should audit them separately.

**Check 2: Inventory the observable signals.**
List everything measurable that occurs around the judgment moment and is
currently thrown away. Time spent before deciding. Which fields were opened.
What got re-read. Hesitation, revisions, escalations. Sequence and order.
The point is behavioral exhaust, not the stated reason.

**Check 3: Test for cheap redundancy.**
Can the same input be judged more than once? By the same person at a later
time, by a second person, or by the same person with the inputs reordered?
Note the cost per extra read. If a second read costs under 10 percent of the
downstream cost of being wrong, redundancy is the correct purchase.

**Check 4: Find the ground truth lag.**
How long until you learn whether the call was right, and does anyone write it
down? A judgment loop with no recorded outcome cannot be improved by any
amount of instrumentation. If this is missing, fixing it is the only
recommendation. Stop here and say so.

## Output format

### Sensor
One sentence naming the judgment moment.

### Signals currently discarded
Bulleted, most capturable first. Mark each as easy, medium, or hard to log.

### Redundancy plan
The specific second read, who does it, what it costs, when it triggers.
Only recommend redundancy on the subset of cases where being wrong is
expensive. Blanket double-reading everything is a failed audit.

### Ground truth loop
Where the outcome gets recorded, and the lag between call and answer.

### Ninety day sequence
Numbered steps. Step one must be loggable with tools already in use.
Do not recommend buying software before there is a labeled dataset.

### What you are NOT automating
Explicit list of the parts that stay human. Name them, so scope does not creep.

## Rules

- Never recommend a model before there are at least 100 labeled outcomes
- Never recommend replacing the judgment, only verifying it
- If the user pushes to skip straight to automation, restate check 4 and hold
- Consensus across weak reads beats one strong read. Design for consensus.