Card lifecycle

Every intent becomes a card in chat. The card is driven by a state machine that rejects skipped, repeated or backward transitions, and validates every event against a schema.

States

drafting ─► planned ─► simulated ─► policy_checked ─┬─► executing ──────────┬─► submitted ─► validated
   │           │           │              │          │                       └─► validated
   │           │           │              │          ├─► awaiting_approval ─► submitted ─► validated
   │           │           │              │          └─► blocked
   └───────────┴───────────┴──────────────┴──────────┴──────► failed   (from any non-terminal state)

Terminal states: validated, blocked, failed.

What drives each step

1. drafting → planned: the intent is mapped to a builder call.
2. planned → simulated: the engine builds, preflights and simulates.
3. Your vault Policy.md is synced to policy.set if configured.
4. simulated → policy_checked: tx.execute runs the policy rules.
5. The engine's verdict picks the branch:
   • executed → executing → submitted → validated, then the vault is updated.
   • needs_approval → awaiting_approval; the card shows the exact transaction and an Approve button.
   • blocked → blocked; the card lists each failed rule.
   • failed → failed.

The model never chooses the branch.

Approving on a hardware wallet

The approval button reads Sign only for a software wallet and Approve on Ledger for a Ledger. On the Ledger path, under the 90-second v2 approval window, once fewer than 30 seconds remain (or the approval has expired) it becomes Rebuild and approve: a fresh build with a new idempotency key. An expired approval is never reused.

Trust receipt

Each card ends with chips that show provenance:

Mock modes append (mock); disabled features hide their chip.