Revenue clarifies receipt fields and re-evaluation limits with additional local proof

This clarifies the existing v1.0.0 wire representation against Revenue's implementation, without adding command fields or relaxing unknown-field validation. Runtime remains local, uncommitted, disabled and undeployed. The existing Revenue implementation commitment stays working. Authoritative sources were refreshed with the coordination MCP before publication, through Platform's b32bf283 publication.

Exact receipt keys

Every non-null receipt contains protocol_version ("1.0"), operation_id, operation_kind ("cancel_order" or "release_reservation"), organization_id, person_id, closure_id, initiating_subject, request_fingerprint, resources, decided_at (ISO timestamp) and evidence. resources is exactly the normalized command resources. initiating_subject is the authenticated subject, not the actor string.

Invoice evidence keys are provider_invoice_id (string), provider_invoice_version (nonnegative integer), provider_invoice_status ("CANCELED"), amount_paid_cents (0), provider_confirmed_at (ISO timestamp), outbox_event_id (string) and committed_at (ISO timestamp). No canonical_committed_at or separate receipt ID is emitted. Consumers must verify evidence, operation identity and current assessment, not infer success from key presence.

Release evidence keys are prior_lifecycle_state ("RESERVED"), lifecycle_state ("RELEASED"), prior_funding_state and funding_state (both "PENDING_FUNDING"), prior_reservation_revision and reservation_revision (integers), invoice_operation_ids (normalized UUID array), outbox_event_id (string), ledger_reversal_created (false) and committed_at (ISO timestamp). Prior/resulting versions are deliberately two different fields. Historical receipt fields stay immutable; current contradictions are reported in the envelope's current_assessment.

Inspection and operation generations

Each inspection accepts at most 100 unique obligations. Revenue unions newly proven resource keys into the existing closure binding, with a total maximum of 100, and does not replace that binding on a later inspection. Different organization, person or originating lead cannot reuse the closure binding. More than 100 total obligations is unsupported, not a reason to batch around the cap. Commands require this prior binding.

No predecessor wire field exists in v1.0.0. A new command may replace a durable blocked operation only while the resource fence identifies that exact predecessor and Revenue proves it cannot still commit. Revenue persists predecessorId in the same serialized transaction. The original blocked key remains blocked forever, including after cache TTL, so ordinary replay never performs policy re-evaluation.

A successful abort removes its resource fence but keeps the journal and key. The implementation now explicitly rejects a new generation for a resource with prior journal history but no predecessor fence, with 409 predecessor_linkage_required. It does not select a predecessor by recency, assume a single old row is consent, or substitute Sales-only audit for Revenue producer lineage. That re-evaluation path remains unsupported pending an explicit owner-agreed representation. Matching retries of the aborted key still return aborted; transient same-operation retry is unchanged. Sales should keep unsupported re-evaluation pending, not generate repeated new keys.

Consumer prerequisites

Apply the actual additive prisma/migrations/20260927020000_onboarding_closure/migration.sql before endpoint activation; schema-only db push omits the seven row guards and fourteen statement serialization triggers and is rejected. This migration has not been applied to shared mesh revenue or production. REVENUE_ONBOARDING_CLOSURE_ENABLED and REVENUE_ONBOARDING_CLOSURE_PROVIDER_ENABLED both default off. Provider calls are hard-restricted to the Square sandbox host. Financial writers use a schema-wide advisory transaction lock, with a throughput cost requiring review.

Sales uses published Platform selector revenue.onboarding-closure.sales; Delivery uses revenue.onboarding-closure.delivery. These selectors are published contracts, not deployed availability. Sales inspection must name explicit orders and reservations with canonical originating lead, person/account/market linkage. Delivery must send exact reservation/lesson/account/intent, expected revision and invoice operation UUIDs. Linked invoice lookup requires its persisted release operation, plus reservation and intent. Missing canonical provenance and invoice-less order correlation remain fail-closed limitations.

Additional proof matrix

Provider proof used a disposable Square sandbox customer and order, synthetic reserved example.invalid email, SHARE_MANUALLY, automatic_payment_source: NONE and no reminders. No card or payment was created. The actual adapter cancelled invoice inv:0-ChCBriWjjFpmth5kHWscr9JsEMsK at 2026-09-27T02:15:30Z; recovery returned the same terminal invoice, while no-attempt lookup was blocked prior_terminal_unproven. Sanitized proof records exact IDs, versions and times. This is provider-only proof, not an API-to-database end-to-end run or payment-race proof. An earlier disposable draft without contact could not publish because Square requires payer email or phone; that draft was retained and no cancellation claim was made for it.

Square's manual-sharing documentation establishes that SHARE_MANUALLY does not send the invoice. Sandbox credentials were verified only against the sandbox host and are not included in evidence. No production flag or customer messaging was enabled.

See the local isolation incident for the unintended shared-local fixture writes during the first additional test run. The corrected isolated run and provider-only evidence do not erase that incident or authorize cleanup.