Delivery accepts paid-invoice ownership architecture with durable consumer proof before activation
Delivery approves ADR-0049's proposed separation: Sales proves full invoice settlement through Revenue's exact assessment and publishes its conversion; Delivery takes operational ownership without inventing a first credit lock. Revenue remains the sole financial authority. This is an architecture acknowledgment, not consumer readiness or production activation approval.
The future consumer binding is the existing POST /api/dispatcher/inbox, using its HMAC verification and durable inbox, dispatching lead.handoff.completed@1 from Sales. Validate canonical envelope tenant separately from explicit payload organization. The new event must not inherit the existing first-lock subscriber's singleton organization fallback. No new financial mutation surface is required by Delivery.
Durable semantics
Persist an immutable logical receipt keyed by canonical tenant, Lead and Order, with a payload fingerprint. A distinct transport event ID with identical content resumes the same operation; conflicting content remains a reconciliation error. Upsert the organization-scoped Person customer and record payment ownership time/provenance separately from nullable first-lock fields. Later customer.handoff or credit.locked enrich the relationship without another onboarding.
Existing active customers retain their relationship. Repeat Leads have distinct receipts without duplicating customer or onboarding work. Inactive customers require visible reactivation work. Curated context must attach in either arrival order using tenant, organization, Person and exact Lead correlation, including nullable lesson/reservation references. A paid handoff with no booking creates an actionable scheduling need.
Persist preparation intent in the customer transaction and recover unfinished preparation after a crash or duplicate delivery. Enforce durable task uniqueness per logical receipt and step. HTTP acknowledgment alone cannot establish preparation success.
Implementation findings and sequencing
Current first-lock receipt keys require lesson/reservation facts. CustomerOrgMarketOwnership requires a reservation and firstLockedAt. Neither can honestly encode payment-only ownership. The current subscriber catches post-commit preparation errors and duplicate receipts skip preparation, while cadence task creation lacks durable step uniqueness. Existing negative preparation offsets with skip-past behavior can create no tasks at handoff time. These are implementation changes required for this accepted design, not reasons to synthesize financial facts.
ADR-0048 remains the active rehearsal. This bounded review follows Delivery's local checkpoint 1c11c73; ADR-0049 runtime edits remain sequenced after overlapping inbox/schema work is safe. No ADR-0049 code, schema, routing activation or flags changed during this review.
Proof must cover concurrent logical duplicates, conflicting payloads, active/inactive/repeat customers, both context arrival orders, no-booking handoff, lock-before-payment and payment-before-lock, and failures between receipt/customer commit and preparation completion. Consumer semantic proof and the coordinated isolated rehearsal precede producer activation. Production fanout, external-action runners and the Sales payment-handoff flag remain disabled.