Decision Rule Capture

---
name: decision-rule-capture
description: Interview an expert before a task gets automated or handed off, and turn scattered instinct into named decision rules with worked examples. Use before automating, delegating, or documenting judgment-heavy work.
license: All-Rights-Reserved
metadata:
  author: Zain Haseeb
  version: 1.0.1
  changed: "2026-09-08"
  category: ai-workflows
  tags: [expertise, interviews, decision-rules, automation]
---

# Decision Rule Capture

Capture an expert's judgment as named, checkable decision rules before that judgment disappears into an automated system or a departed employee.

## Critical behavior

1. Interview from a real recent example, not from an abstract description of the job.
2. Ask what the expert noticed, ruled out, and what would have changed their call at each step.
3. Push past "it depends" and "you just know" by asking for the specific signal that made the difference.
4. Ask for at least one case where the obvious rule would have been wrong.
5. Separate rules the expert stated directly from rules you inferred from their examples, and label the inferred ones.
6. Report contradictions between what the expert said and what their example shows instead of smoothing them over.

## When to use

Use this before a task is automated, before an expert leaves or changes roles, or when a workflow's quality depends on judgment that only lives in one person's head. It is most valuable when the same person keeps getting pulled back in to make "one more call" that nobody else can make confidently.

Do not use it for tasks that already have a written procedure everyone follows; interview effort should go where the knowledge is tacit, not where it is already documented.

## Run the interview

Confirm permission to use the case and share the resulting rule sheet with its intended audience or AI service. Ask for minimized, anonymized accounts; do not copy private messages, transcripts, customer or personnel identifiers, or contract terms without authorization. Preserve the decision-relevant condition without sensitive particulars. Record source and freshness through non-sensitive references. If the necessary detail cannot be shared, record the evidence gap instead of inventing a case.

### 1. Start from a real example

Ask the expert to walk through one recent, real case step by step, in the order they actually experienced it. Do not start with "how do you generally approach this," which produces polished generalizations instead of real decision points.

### 2. Find the signal at each step

At every step, ask three questions: what did you notice, what did you rule out, and what would have had to be different for you to decide the other way. The third question is where the real rule usually surfaces.

### 3. Find the exception

Ask for one case where following the "obvious" version of the rule would have produced the wrong outcome. This exposes the actual boundary condition, not the textbook one.

### 4. Separate stated from inferred rules

Write down every rule the expert said out loud as stated. Write down every rule you had to infer from watching their example play out, and mark it inferred until the expert confirms it.

## Output format

Return a decision rule sheet with, for each rule:

- Trigger condition
- Resulting action
- Override signal (what would flip the decision)
- One worked example from the interview
- Source: stated by expert, or inferred and unconfirmed

Close with the two rules most likely to be wrong without more examples, so whoever inherits this work knows where to be cautious first.

## Example

An operations lead is training a junior planner before automating routine scheduling. The interview surfaces a rule the lead never wrote down: reschedule requests from a specific client type get priority regardless of queue position, because that client's contract has a penalty clause. That rule would have been silently lost in a purely time-ordered automation.

## Troubleshooting

- If every answer is "it depends," ask for the specific example that made it depend, not a restated abstraction.
- If the expert cannot produce a counter-example, ask about a time they were surprised by an outcome instead.
- If two rules conflict, do not average them into a vague middle rule. Report the conflict and ask which one governs.

## What not to do

- Do not write a rule you inferred as though the expert confirmed it.
- Do not resolve a contradiction on the expert's behalf.
- Do not accept a first-draft answer that describes the job in general rather than the decision at hand.
- Do not skip the counter-example question, since it is usually where the real boundary lives.