Revenue accepts exact paid-handoff assessment architecture with authoritative settlement evidence
Revenue approves ADR-0049's architecture and the proposed payment-handoff-assessment v1.0.0 path and response schema as the implementation target. Full settled payment can establish Sales-to-Delivery operational handoff while Revenue's first-lock and financial events retain their actual meanings. This is an architecture acknowledgment, not an assertion that the endpoint exists or that financial proof is complete.
The exact read is GET /api/v1/orders/{order_id}/payment-handoff-assessment with explicit organization, Person and Platform Market query identifiers. Platform's existing revenue.sales-operations selector, subject sales, audience revenue and revenue.orders.read scope are sufficient. Verify canonical tenant and organization separately, plus Person and market against source associations, on every uncached read. A valid token or person/account membership does not make a replaced or unrelated order eligible. No Client, Credit Account, reservation, payment action or revision may be created by this read.
Required source semantics
Use one coherent financial and operation assessment under the same serialization discipline as the relevant writers. The monotonic nonnegative revision must advance for every load-bearing change to settlement, invoice linkage, refunds, admitted actions and correlated ADR-0048 journal/fence state. It cannot be a wall-clock timestamp, a maximum of unrelated updatedAt values, a read-time increment, or just an Order-row version. The current schema does not yet supply this complete projection; it requires implementation.
paid_at means the transition to fully settled payment, not the first installment, invoice creation, provider attempt or most recent arbitrary mirror update. Current modules/order/repo.ts permits upstream paidAt alongside the supplied payment/status update, so its mere presence is insufficient provenance. Historical ambiguous timestamps remain null and defer transfer. Confirmed offline settlement is eligible only when its authoritative committed settlement facts satisfy the same full-payment predicate. Provider success without Revenue writeback is not payment completion.
refund_status=none requires positive absence of pending or completed refunds across the exact correlated financial surface. Partial/full/pending refunds block handoff. Unresolved, recovering, or rejected-but-unsettled ADR-0048 cancellation/release work and admitted external actions keep cancellation_pending=true; timeout or absence from a list cannot clear uncertainty. Proven safe abort is different from an unknown provider outcome. Terminal receipts and non-resurrection protections remain intact.
When exact ownership, total/currency, invoice association or coherent operation evidence cannot be established, return nondisclosing unavailable/error evidence as appropriate, rather than synthesize an eligible response. Nullable invoice_status is reserved for a positively proven invoice-less settlement; it is not a fallback for a missing invoice read. Sales' freshness, selected-invoice and Lead-lock checks remain necessary; later refunds stay Revenue/Delivery responsibility and do not reopen Sales.
Sequencing and proof
This review is read-only with respect to Revenue runtime, at the ADR-0048 HTTP readiness checkpoint. No ADR-0049 endpoint, schema, financial writer or production flag was changed. Runtime work is sequenced after the active ADR-0048 isolated rehearsal to avoid overlapping schema and cancellation-evidence changes. The accepted interface remains disabled until actual implementation and proof.
Proof must cover full and partial payment, confirmed offline settlement, refunded-to-zero and pending/full refunds, wrong or replaced/unrelated org/Person/market associations, full-settlement timestamp provenance, coherent monotonic revision across all load-bearing writers, and both winners against unresolved ADR-0048 work. Do not infer proof from a synthetic Sales adapter seam. No production deployment, historical fanout, financial cleanup or customer communication is authorized by this acknowledgment.