The plan
The working surface behind the site: the ten promises v1.0 must hold, the twenty-six component canvases that keep them, the dependency structure between them, the decision spaces still open, and how the work splits across teams. Newcomers should start at the overview; this page is for working the plan.
The promises
Ten user-facing invariants that v1.0 must hold. Each is stated as something a user (or ecosystem partner) can rely on, with falsifiable invariants underneath. Click any card to see its full statement, the testable invariants, and the components that serve it.
How we got here — from the secure-onboarding six to the working ten
Pass 1 of the planning work started from the six principles in the secure-onboarding document — Key-bound TEE; ZK witnesses, Single seed, three wallets, Chain abstraction via intent, One key per device, Privacy-by-design identity, and Seedless UX. The ten promises above are not a different vision — they are the same six pressure-tested for falsifiability, with mechanism statements peeled off and previously-implicit assumptions made explicit so each can be individually tested. Every promise traces back to something the original document said or assumed; nothing here is invented.
| Original principle | Disposition | New mapping |
|---|---|---|
| #1 Key-bound TEE; ZK witnesses | Split, abstracted | TEE specificity removed; ZK witnesses move to mechanism layer. |
| #2 Single seed, three wallets | Dropped | Implementation specification, not a v1.0 invariant. |
| #3 Chain abstraction via intent | Preserved, promoted | Same concept, now stated as a v1.0 promise instead of a later-milestone concern. |
| #4 One key per device | Rewritten, split | Mechanism statement; surfaces multi-device peerage, no exfiltration, and scoped grants as separate principles. |
| #5 Privacy-by-design identity | Kept, renamed | Renamed for sharper testability. |
| #6 Seedless UX | Split | No-mnemonic UX is P1; total-loss recovery without seed is P5. |
Five made explicit — promises that were implicit in the original document and surfaced as their own principles by Pass 1's pressure-testing.
- Named— the original mentioned the named-account handle throughout, but never elevated naming to a principle.
- Peer-device— implicit in #4; multi-device peerage was the premise of the device-add flow.
- Revoke-and-continue— implicit in the multi-device story; the QR-code device-add flow shadowed a revoke-old-and-continue mode.
- Scoped grants— function-call keys appeared as a sub-feature of #4 but were never named as their own primitive.
- Chain-only— assumed throughout the document (no operator was required for any flow), but never stated as a constraint.
The components
Every functional surface Passport needs to deliver, in a single searchable list. Filter by promise, category, or open-decision status. Click any row to open the component's full canvas — outcome, dependencies, alternatives, open questions, failure modes.
| ID | Component | Category | Serves |
|---|
The dependency graph
Hard-precedence edges between components (B must be settled before A); the identity-and-account core is collapsed into one super-node — click it to see what it contains. Click any other node to open its design space. Toggle the associations to see softer "interacts-with" edges.
The interactive graph needs its CDN-loaded layout library, which did not load here. The component table above and the parallelisation chart below carry the same dependency data.
The decision spaces
Five decision spaces whose answers cascade into multiple component canvases — one resolved, one partially resolved (the fee mechanism is settled, the operator model is open), three open. Each open card names where the decision actually gets made. The bigger the fan-out, the more downstream design unlocks once the question is answered. Click a card for the full framing, its cascade, and its cross-couplings.
What remains, by lane
Everything still between here and a ratified, feature-complete v1.0 — standards to draft, reviews commissioned as acceptance criteria, evidence still to gather, client policies to pin down, and the workstreams that remain open decision spaces. Component chips open the canvas in place.
Waiting on — one row per external party
Parallelisation — streams × sequence
How v1.0 work splits across teams: six streams plus a discovery lane, laid out left-to-right by global dep-depth (longest chain to each component, computed from data.js). Streams are not synchronised — gaps are real, indicating where a stream is idle waiting on something elsewhere. The thick red ribbon traces the longest dependency chain (the critical path); whatever sits on it sets the project's minimum duration. Two pivots are flagged: C1 (the bidirectional core that everything identity-shaped flows through) and C8 (the cross-cutting hash-discipline gate). Specified and decided components render dimmed, so the bright band is the staffable frontier. Below the streams sits the Demo phases lane; click a phase bar to spotlight its components.
Components in the identity-and-account core (see data.js core_scc) all sit at the same depth — their internal ordering is a build-order choice, not a strict precedence. The critical path's representative through the core is C1. Node positions and depths recompute whenever data.js changes; the critical-path ribbon itself is a hand-maintained representative chain, revisited whenever the dependency data moves.