skills/selective-intelligence/references/first-checkpoint.md

# First checkpoint

The first checkpoint prevents expensive drift when meaning or consequence justifies a lock. It is not the default first response to every request that creates or changes something.

## When it fires

Use a checkpoint headed **What I understand you want** before action only when at least one condition applies:

- material ambiguity remains and plausible readings lead to meaningfully different outcomes;
- the request locks a new whole product, system architecture, migration, or cross-system contract;
- the next action is public, irreversible, expensive, destructive, permission-changing, or exposes sensitive data; or
- the person explicitly asks to lock intent before execution.

A clear correction, focused document change, reversible local edit, bounded feature repair, routine repository continuation, or ordinary research task stays Lean. The existence of a user, persistent file, or durable result does not by itself fire this checkpoint.

## The checkpoint artifact

Include only the fields needed to prevent the identified drift:

1. **Outcome and user** — the real-world result and who must be able to use it.
2. **Non-negotiables and prohibitions** — what must be preserved and what must not happen.
3. **Scope and boundaries** — the complete affected surface, including explicitly excluded areas.
4. **Outcome slices and proof** — for a whole-product lock, the bounded parts and observable evidence that make each part real.
5. **Canonical reuse map** — existing owners to reuse or change before creating another one.
6. **Build or action sequence** — the dependency order that avoids partial or contradictory work.
7. **Authority split** — reversible work the AI may perform and exact consequential actions reserved for the person.
8. **Constraint reconciliation** — material conflicts among requirements, capabilities, privacy, time, and cost.
9. **Human-only activation steps** — only actions the person truly must take, expressed in plain language without technical setup homework.

Do not inflate a narrow consequential action into a whole-product essay. For example, a publish checkpoint may need the target, artifact, visibility, and rollback implication—not nine repeated sections.

## Information sufficiency

Infer from active conversation, existing artifacts, authoritative evidence, and established decisions before asking. Ask one compact question only when the missing answer changes the outcome, authority, sensitive-data boundary, consequential cost, or irreversible choice and cannot be resolved safely.

Whole-product locks should resolve their genuinely blocking inputs together. Later unknowns that do not block the next reversible slice stay visible; they do not prevent useful local progress. Do not trickle-ask questions that inspection can answer, and do not claim that an unverified inference is approved intent.

## Approval surface

Present the checkpoint in short human language. Keep the complete machine-checkable record internally when the runtime needs it.

- **Platynum:** the product may provide wired Approve and Correct controls bound to the current checkpoint identifier and intent hash.
- **Outside Platynum:** use the text gate `APPROVE` or `CORRECT: <instruction>`. Do not render decorative buttons or emoji controls.

Approval unlocks only the described action and scope. A correction reopens affected meaning, invalidates dependent work and proof, and creates a revised checkpoint where the trigger still applies.

## Enforcement boundary

- Do not perform the gated consequential action before valid approval.
- Reversible inspection and preparation may continue when they do not pre-commit the disputed choice or create an external effect.
- Do not require approval again for every harmless step under the same approved boundary.
- A deadline never authorizes a consequential action or false completion claim.
- If the delivered result does not match what the person wanted, reopen understanding even when narrow tests pass.

The SI checkpoint runtime can bind and interrupt governed session work. Do not claim it stopped arbitrary third-party model streams, tools, or workers unless product wiring proves that effect.

## Relationship to execution lanes

Lean work normally has no checkpoint. Guarded work uses one only when a trigger above is present. Council work commonly includes one because its selection conditions often involve ambiguity or consequence, but Council status alone is not a reason to repeat already settled approval.

The checkpoint locks meaning or authority; it does not require seven roles, a Start Pack, a queue, or a Resume Packet. Those artifacts are separate tools used only when the selected workflow genuinely needs them.

## Measure

Track two outcomes:

- **avoidable checkpoint rate** — clear reversible tasks stopped for approval without a trigger; target zero;
- **correction rounds to correct consequential checkpoint** — user corrections needed before a triggered lock matches intent; target zero.

Both matter. A gate that catches costly drift is useful; a gate placed before every harmless edit is token and interaction waste.