Naveo

STEP 13 / 20

D1 ORDER

DRAG TO REORDER

Atlas asked you to wire delete_user with the two-phase pattern: the model never deletes in a single call. The first call simulates, the second confirms. Order the seven protocol steps.

3. The tool returns a preview

Lists what would happen: account deleted, sessions invalidated, data affected, retention window.

5. The human replies 'yes, confirm'

Authority over destruction is NOT the model. it's the human on the trusted side.

6. The model calls delete_user(user_id=X, dry_run=false, confirm_token=...)

Second phase. The confirm token came from the earlier preview, not from the model.

4. The model presents the preview to the human agent

Plain text: 'I'm going to delete user X. this affects Y, Z. confirm?'

1. The model decides to attempt deleting user X

Based on a conversation with a human support agent.

7. The tool executes, writes to audit log, returns result

Irrevocable action performed under double record.

2. The model calls delete_user(user_id=X, dry_run=true)

First phase. The tool does NOT modify anything.

GUEST MODE

You're viewing this lesson as a guest. To save your progress, earn XP, and keep your streak, sign in when you're ready to check.

Costs 1 heart

A destructive action never happens in a single call

Any action that cannot be undone goes through two phases. Hex doesn't approve a destructive wiring without this pattern. It's the only defense that holds against an injected model, a confused model, or a model that just moved too fast.

Why two phases

Phase 1, dry-run. The model calls the tool with dry_run=true. The tool executes nothing. It only computes and returns what would happen: what gets deleted, what gets invalidated, what gets notified, what retention remains. This is what the model (and you, via audit log) can inspect before committing.

Phase 2, confirmation. The model presents the preview to the human, waits for explicit OK, and only then calls again with dry_run=false and a confirm_token that came from the preview. The tool validates the token and, if it matches, executes.

Three things heads tend to get wrong

Model-generated confirmation. The model says "I'm going to delete X, confirm?" and then calls the confirmation without waiting. That's not two phases. it's one phase with theater. The confirmation must cross to a different channel (the human, another app, a separate session) and come back.
Invented confirm token. If the model can generate the confirm_token, there's no validation. The token must come from the runtime (from phase 1) and phase 2 must reject tokens you never issued.
Dry-run that still writes. Some "dry-runs" reserve resources, write "attempt" logs, or fire webhooks. That's no longer dry. Your dry-run must be identical to doing nothing from the outside, except for the response to the model.

When an action is irreversible, prudence is structural. If your wiring depends on the model "choosing right", you don't have prudence. you have hope.

The full protocol

On the right are seven steps. put them in order. There's ONE correct order. Any other leaves a hole.