skills/selective-intelligence/references/friction-ladder.md

# Friction ladder

Use this reference only when the correct execution lane is unclear. Friction follows consequence, not the mere existence of persistent files, real users, or a named project. A durable task can still be clear, bounded, reversible Lean work.

## Guardrails at every lane

1. **No unauthorized external effect.** Do not send, publish, push, merge, delete, purchase, provision, deploy, disclose sensitive data, or change access without exact authority.
2. **No unproven completion claim.** Do not call work tested, deployed, live, verified, or complete without corresponding evidence.

These never scale down. Everything else is proportional ceremony.

## Lean — default

Use Lean when the outcome is clear, the work is bounded, and the next actions are reversible. Examples include a correction, focused research, a document edit, a local code repair, a routine repository continuation, or a small feature with an existing owner.

- Use one context and the minimum relevant evidence.
- Begin useful reversible work without an intent checkpoint.
- Do not create a Start Pack, queue, Resume Packet, or Council packet merely because the result will persist or has users.
- Validate the actual result proportionately and report only meaningful proof or limits.

Persistence changes what must be checked; it does not by itself require multiple agents.

## Guarded — material but reversible

Promote to Guarded when the work crosses several owners or surfaces, changes a durable contract, or could create broad drift while remaining reversible and outside a high-stakes boundary.

- Keep a concise outcome, scope, prohibition, and proof record.
- Inspect affected dependencies and competing owners.
- Use one fresh Objector or verifier only when it can catch a material failure that deterministic checks cannot.
- Reconcile the finding in the working context. Do not automatically add Planner, Queue Manager, Aligner, or Reserve roles.

Guarded is a bounded review step, not a complete Council workflow.

## Council — exceptional

Promote to Council only when the person explicitly asks for it or at least one condition applies:

- competing interpretations lead to materially different costly outcomes;
- a whole product, system architecture, migration, or cross-system contract is being locked;
- money movement, credentials, permissions, private customer data, security, regulated claims, or destructive operations are central;
- a public or hard-to-reverse action carries meaningful harm;
- a repeated failure survived Lean and Guarded correction; or
- an existing human governance rule requires independent review.

Council uses the minimum sufficient roles. A Worker and one independent reviewer are the normal starting pair. Add an Aligner only for conflicting findings and a Reserve only for genuine capacity or continuity risk.

## Checkpoint trigger

A user-visible **What I understand you want** checkpoint is separate from the lane choice. Use it only for unresolved material ambiguity, a whole-product or architecture lock, an exact consequential action, or explicit user request. Outside Platynum use `APPROVE` or `CORRECT: <instruction>` for that triggered gate.

A clear bounded local action does not become risky merely because it mutates a file. Consequence, reversibility, authority, and scope determine the gate.

## Choosing under uncertainty

Choose the lightest lane that preserves the two guardrails. Record the trigger when promoting. If inspection resolves the concern, return to Lean rather than carrying higher-lane ceremony through the rest of the task.