Authoritative assessment reaches a verified local checkpoint

Revenue implements the accepted payment-handoff-assessment v1 interface at GET /api/v1/orders/{order_id}/payment-handoff-assessment. Source remains uncommitted on Revenue main at base fecab1cc63c5ef46aad551b3bb4a438ff3606a21, with exact working-tree hashes in the source and verification checkpoint. This is not a standalone ADR-0049 source commit; shared ADR-0048 changes and unrelated working-tree edits remain preserved. No production deployment, migration or activation is claimed.

The endpoint verifies Sales subject, Revenue audience, exact read scope, canonical tenant separately from organization, and source order/Client/Person/reservation/account/market linkage. All responses are uncached. It takes the financial advisory lock within a read-only transaction. Forty-two statement triggers across twenty-one source tables serialize writes and advance a conservative monotonic revision. Reads never create a revision or repair eligibility; missing guards and incomplete linkage fail closed.

Full-settlement evidence is recorded atomically with actual payment writeback and its source outbox event. Cumulative payment facts determine when the total became fully paid, including delayed and out-of-order installments. Old Order paidAt alone is not trusted. Confirmed offline settlement and invoice-less settlement require positive source evidence. Refunds, admitted external actions and unresolved closure operations/fences prevent eligibility. Explicit reservation linkage resolves the correct account when a Client has multiple accounts.

Actual HTTP and financial evidence

The private runtime uses its own dependencies and 50-model client against adr0049_rehearsal_87e1d984f24647b98ec94310d4c98273.revenue_adr0049_test. Both URLs, generated schema and actual database are verified. Loopback Revenue 3492 was restarted after the final local issuer 3490 key rotation. Twenty-one actual HTTP checks passed with real RSA/JWKS verification, without a verifier seam. A valid token retaining six other scopes but omitting revenue.orders.read returns 403. Bad signature, expired token and wrong audience return 401; wrong tenant/org/Person/market and ambiguous query controls fail without cross-scope facts.

Nine preserved financial cases cover full internal payment, partial payment, positively invoice-less cash, unresolved closure, pending/full refunds, ambiguous historical paidAt, missing order scope and zero-price rejection. These cases use internal synthetic cash writeback or explicitly labeled negative fixture rows. They are not Square payment/refund proof.

Primary Order ord_01a0e0d6-b18b-7167-8653-cc5fe9cd38c2 is linked to reservation crr_01a0e0d6-b153-77a1-9c29-766f532070c9. Its preserved full-settlement time is 2026-09-27T03:41:37.057Z. Actual source event evt_01a0e0f5-259a-7a06-800f-45a5c5e2b6d5 was exported directly from persisted outbox data for Sales. No payment writeback was replayed. Sales owns its actual handler/handoff and Platform/Delivery own signed delivery, DLQ and duplicate evidence in their companion memos.

Real PostgreSQL concurrency boundaries

modules/payment-handoff-assessment/service.test.ts uses real Revenue services, installed guards and transactional outbox rows. Its test transport writes into the same database transaction; provider behavior is mocked where stated. The separate joint fixture run uses the actual dispatcher SDK.

• Three concurrent actual payment calls, 400 cents, 600 cents and duplicate 600 cents, commit 1,000 cents and exactly two payment events with the correct full-settlement time. Changed duplicate payloads conflict.
• Payment-first overlap pauses the actual payment transaction after outbox insertion. An independent read-only connection observes the cleanup or assessment participant waiting on the actual PostgreSQL advisory lock. Releasing the writer lets cleanup reject cancellation of the paid order and lets assessment read committed full settlement. Separate two-participant runs respect the application's two-connection pool.
• Closure-admission-first overlap holds a mocked provider adapter after real admission. Real payment writeback commits while that operation remains unresolved. Assessment reports pending with a later revision. After the adapter reports cancellation, the canonical writer re-reads payment facts, refuses to cancel the paid Order and produces no closure receipt.
• Ordered safe-abort cases prove paid rejection remains pending until durable abort; later truthful payment does not silently clear an existing closure fence. Revision rolls back with source mutations, and repeat reads do not advance it.

The initial overlap harness incorrectly required three domain participants plus its observer through a two-connection pool and timed out. The corrected harness uses two domain participants and an independent read-only observer; it verifies actual lock waiters, not sleep-based ordering. No production code change was needed.

These checks prove the described local writer boundaries. They do not prove randomized provider races, every ADR-0048 writer family or every crash boundary. The separate ADR-0048 process proof covers one real kill/restart boundary with a local fake provider.

Compatibility source events

Delivery confirmed its two allocated lessons were still uncreated and supplied a fresh future window, September 30 03:41:26.865Z through 04:11:26.865Z. Revenue created new scoped accounts, +3 synthetic-credit adjustment entries and local lesson mirrors. The actual reservation service verified funded balance and produced FUNDED/LOCKED rows, one real lock debit and three persisted events for each control. This is actual producer reserve/lock proof on synthetic funding, with no payment or provider-charge claim.

The checkpoint includes full source credit.reserved, credit.locked and customer.handoff envelopes, exact lesson/Person bindings and ledger rows. Delivery owns creation and verification of its corresponding rows; Revenue edited no other domain's data.

Validation and remaining gates

The current combined Revenue full suite passed 609 tests across 78 files. Three subsequent test-only overlap cases passed in the 75-test focused group across four files. Runtime behavior was unchanged after the full run. Typecheck, eight-family dispatcher smoke, diff checks and the private ledger audit passed; four ledger entries had zero append-only violations. The source checkpoint records commands and log hashes.

The live ledger was checked September 29. Revenue's implementation commitment remains working pending source integration and final joint acceptance. The production readiness event remains uncleared. Deployed capability issuance, migration/cutover, global serialization throughput, consumer compatibility acceptance, financial history policy and explicit activation stay separate. Fanout, outbound runners and production flags remain disabled. No customer communication, historical obligation cleanup or primary payment replay occurred.