Approval status must not be confused with implementation or deployment.
| ID | Architectural choice | State |
|---|---|---|
| D-001 | Independent service ownership, explicit versioned contracts and separately releasable roles | Baseline architecture |
| D-002 | Split provider control-plane lifecycle from Provider API data plane | Owner-approved design (2026-10-16); verification pending |
| D-003 | Durable purchase command, Wallet hold, and dispatch intent before external side effects | Phase 2A design only |
| D-004 | YSQL is intended financial authority; Redis is reconstructible | Baseline architecture |
| D-005 | Master-key isolation and narrow role credentials | Required security boundary |
| D-006 | Separate public read-only documentation deployment | Docs architecture |
D-002: Two separate provider identities
A host manager can manage local provider processes but must not become an order gateway. Catalog reads and provider purchases require different scoped API identities. Method authorization and mutual TLS still need independent proof.
D-003: Unknown is a valid outcome
A timeout after a mutating provider request cannot prove that no order was created. The Executor must reconcile the original request rather than post a second paid order.
Open items
Final wire schema, claim fencing representation, cross-host agent transport, provider idempotency semantics, compatibility and live rollout remain separate decisions or proof gates.