Materiality Prompts

Calibration prompts for the materiality dial (Chapter 13). Two failure modes the prompts guard against: over-rigging (heavyweight discipline on trivial work) and under-rigging (one-shot prompt on a deploy-class decision).

Stakes-assessment prompt

Use at the start of a task when stakes are unclear. Names the three axes the dial uses; produces a single low / medium / high verdict.

Before starting this task, name the materiality along three axes: 1. STAKES (consequence if wrong): - Low: cosmetic, easily reverted, no audience. - Medium: affects one team's work; reversible but visible. - High: production / customer / regulatory / irreversible. 2. REVERSIBILITY (cost of undo): - Easy: git revert, file restore, ctrl-Z. - Medium: requires investigation to undo; some collateral. - Hard: state changes propagated, public artifacts created, external systems touched. 3. OBSERVABILITY (chance of catching a mistake): - High: tests cover it; reviewers will see it. - Medium: humans will notice eventually. - Low: silent failure mode; may not be detected until downstream consequences surface. Verdict: the HIGHEST tier across the three axes is the operating materiality for this task. Apply discipline matched to that tier (see calibration table below).

Why "highest of three": low-stakes work that is hard to reverse OR low-observability still warrants medium discipline. The dial is not an average; it is the conservative choice across axes.

Calibration table - discipline by materiality

Materiality	Frame-before-solve	Maker / checker	Visible verification	Confirmation gates
Low	Skip (or one-line restatement).	Skip; self-review is fine.	Output is the evidence.	None.
Medium	Brief restatement; surface 1 alternative.	Light: re-read your own output once with the explicit goal of finding a hole.	Name the check that passed; cite the source.	Gate at first network call or first file write to shared paths.
High	Full restatement + 2+ alternatives + named falsifier per alternative.	Separate verifier (different prompt / different model / human).	Full audit trail: every claim cites the specific source line; every action is logged.	Gate at every side-effect class transition; explicit user approval for every write to shared resources.

Autonomy-posture selector

Use when granting an agent autonomy on a task. Names the three postures explicitly so the user can pick rather than have it implied.

Before granting autonomy, declare the posture: POSTURE A - Supervised - I (the human) approve each action before it happens. - Suitable: high stakes, low observability, unfamiliar territory. - Cost: high attention load; slow. - Example: production database operations, public-facing communications, anything that creates a permanent record. POSTURE B - Bounded - I (the agent) act autonomously within a named scope; I escalate on scope-class transitions. - Suitable: medium stakes, well-defined scope, known patterns. - Cost: requires upfront contract on what "scope" means. - Example: refactoring within a module; updating docs; running test suites and reporting failures. POSTURE C - Autonomous - I (the agent) act without per-action confirmation; the harness records actions for after-the-fact review. - Suitable: low stakes, high observability, reversible actions. - Cost: requires monitor model or audit log for review. - Example: linting fixes; formatting; minor documentation edits; spike work the user explicitly marked as throwaway. Declare posture at task start. Posture cannot be silently upgraded mid-task; if you need to move from B to C, surface the change and get approval.

Failure mode prevented: ambient autonomy. The agent silently escalates from supervised to autonomous because the conversation feels collaborative. Naming the posture explicitly forces both parties to agree.

Materiality re-check (mid-task drift detection)

Use periodically during a long-running task. Materiality can change mid-task as the work surfaces new information.

Materiality re-check (run every N iterations or at any natural breakpoint): 1. Has the SCOPE of what I am touching grown since I started? (More files? More environments? More external systems?) 2. Has the REVERSIBILITY of my actions changed? (Did I just create a public artifact? Send an email? Push a remote branch?) 3. Has the OBSERVABILITY changed? (Did I just touch a code path that has no tests?) If any axis shifted, RE-VERDICT the materiality. If the new verdict is higher than the original, escalate discipline to match the new tier BEFORE the next action. The cheapest place to fix a materiality miss is at the moment the scope shifts, not after the action that drifted has already shipped.

Why this re-check is necessary: tasks routinely start "low materiality" and drift into "medium" or "high" as the partner discovers what the work actually involves. The original calibration is wrong by the time the drift completes. The re-check is a Tenet IX visible-discipline move at the loop level.

Practitioner notes

The dial is not symmetric: over-rigging burns attention; under-rigging risks outcomes. When in doubt, err high on the dial for irreversible actions and low on the dial for purely reversible ones.
The autonomy posture should be declared before the task starts. Mid-task posture changes are a smell; surface them explicitly.
If the stakes-assessment lands "high" and your harness does not support the corresponding gates and verification, do not run the task. Get the gates first.
See Chapter 13 for the 3×3 grid (stakes × autonomy posture) and its diagonal / off-diagonal framing.