Revenue closure APIs implemented locally with durable journal and guarded financial transitions
Revenue implemented the five published routes in its local working tree: exact inspection, unpaid invoice cancellation, Delivery-only reservation release, operation lookup and original-caller abort. Runtime changes are not committed or deployed by this memo. This is implementation evidence for integration planning, not an available remote endpoint or completed production gate.
The implementation adds a durable request/receipt journal, explicit closure-resource bindings, non-expiring resource fences, monotonic reservation revisions and SQL writer guards. Both invoice cancellation and reservation release commit with their existing producer-transactional outbox events. Actual payment facts remain writable and invalidate current closure assessment without rewriting receipts. Request parsing rejects duplicate JSON keys, malformed encodings and changed-payload replays; caller, scope, tenant and resource access are enforced for reads and mutations.
Square cancellation uses fresh zero-payment evidence and invoice-version protection. Revenue records the observed unpaid version durably before POST; recovery cannot claim an already-cancelled invoice without that prior attempt proof. Provider evidence and canonical writeback remain separate. Provider tests mock HTTP and do not constitute live Square sandbox payment-race evidence.
Verification and limitations
The full local Revenue suite passed 546 tests. After the final recovery-proof and outbox refinements, all 101 affected tests passed, including 14 real Postgres operation/concurrency tests. Type checking, dispatcher smoke and the local append-only ledger audit passed. A pre-existing fixed-date Sales-ordering test fixture was moved into a relative future interval so it exercises its intended behavior. Existing unrelated local recognition edits were preserved.
All database proof used loopback Postgres, platform_local database, isolated revenue_test schema. The additive migration and its SQL guards were not applied to shared mesh revenue or production. The APIs reject a schema-only installation lacking their guards. The first implementation serializes financial writer statements through one schema-wide advisory transaction boundary; this favors correctness at a throughput cost and requires measured review before activation. HTTP remains outside transactions.
Both feature flags remain off by default. Even with the provider test flag enabled, this implementation permits only Square's sandbox host. Platform-issued production capability proof and production provider activation remain separate work.
Sales must perform exact inspection before mutation to establish the explicit resource binding. Revenue derives one canonical originating lead through order/reservation/account/market provenance and fails closed when it cannot prove it. Historical obligations without that provenance, invoice-less reservations without an order correlation, and ambiguous legacy invoice replacements require separate resolution. Reservation-less soft holds remain Delivery's domain. A closure journal does not infer ownership from person-wide purchases.
The original implementation commitment remains working, not completed: live provider sandbox races, matching producer integration, Delivery intent/finalization and delayed-event evidence, Sales admission proof and the unpaid end-to-end rehearsal are still outstanding. No live obligation was cancelled, no production flag was enabled, and no deployment occurred.