Revenue requires verified original admission and protected compensation before ADR-0053 approval

Assignment ADR-0053/revenue/001; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local; participant 01a0ff07-dae9-7ed3-9b27-0fd2c4dcc6fe. Reviewed Proposed ADR-0053 and its approval request at 3225646710eb3073a4e8e5e5f8a6fb9f07eeb1cf, and Platform/Sales positions at 74904433fe7c873288697a87aebd8ff0024232de. Revenue supports the bounded direction and withholds acknowledgment pending the exact assembled package. This is a design recommendation, with no acknowledges field, implementation commitment, policy issuance or activation approval.

ADR-0052 implementation is paused at Revenue candidate d24da76a84e7fc72dc909a1d84c748e9d11d8d65, following b99be092ffff43e1c5f4bb19574bfe0fa0e96b7d. The checkout and isolated fixtures are unchanged. Integrating released ADR-0049 account identity 5417 and ADR-0050 closure correction 689e8b9 remains a later ADR-0052 dependency after explicit handback. This review does not complete that integration.

Revenue source facts and compatibility decision

Accepted ordering v2.9.0 and its scheduling-bind-recovery v1.0.0 preserve original close bodies, headers, normalized equality and immutable terminal outcomes. Recovery of a Revenue-admitted request is an internal capability; those contracts supply no credential-free Sales recovery command or proof that an unseen key came from a valid Sales admission. Permanent bind settlement is not permanent close settlement.

Revenue candidate modules/sales-ordering-surface/service.ts:722-739 persists the original normalized close, Order, reservation and bind association in its guarded transaction before external preparation. Lines 746-770 retain the original inline request and consume a link handle with durable original token association. modules/scheduling-bind/service.ts retains attempts/results and only dispatches collection under bound/protected continuation. Existing closeHash commits to the full original request, including capture credentials. It is neither the proposed shared non-secret digest nor an independently verified Sales admission artifact. The schema normalizes offer-items and omits historical_booking unless true; this normalization must remain authoritative. Customer preparation in d24da76 adds original provider requests/results and bridge writeback, but does not close the Sales lost-response gap.

Recommend ordering v3.0.0, with a mandatory immutable, signed, non-secret Sales admission descriptor on both the original close and recovery. Agree with Sales that an existing header's capacity for a new key prefix does not make unseen provenance verifiable. The new original requirement is a major change even if the recovery route is additive. Preserve inline and link, existing normalized close equality, original financial keys/IDs, and reserved/committed/failure replay. Declare the new original request selector/field and migration explicitly; do not retrofit descriptor requirements or fabricate descriptors for v2/legacy receipts.

There is a sound alternative to a Sales signing protocol: a separate authenticated Revenue pre-registration operation can validate the descriptor against approved Sales admission evidence, permanently store the exact identity/digest and issue a non-secret Revenue registration receipt before any original close send. Original execution must require that registration and consult the same registry; recovery can then settle registered-but-unexecuted commands rather than infer unseen provenance. This moves trust to a durable registration, but adds a route/policy, a response-loss recovery protocol and another network prerequisite. Merely registering an arbitrary Sales assertion does not validate human admission. A pre-registration design still needs an independently approved admission predicate and enforced original-writer barriers. It cannot be called additive if existing original callers are made to require registration. Revenue prefers the signed descriptor major-version construction for this package, subject to the verification objections below, rather than adding a fourth business capability here.

Proposed original identity, digest and recovery surface

Recommend Platform's exact POST /api/v1/sales-ordering/close-recoveries, authenticated by the new dedicated sales-production-to-revenue-close-recovery-v1 policy, subject sales, audience revenue, sole scope revenue.sales-ordering.close.recover. It authorizes only this recovery route. Original close remains separately authorized. Current workload proof, tenant/Organization reach and service entitlement precede descriptor verification and any retained response disclosure. Use the exact production pins and fresh audited issuance in Platform's position, with no human cookie, persisted bearer, issuer proof or payment credential in Sales.

Propose one closed recovery request containing protocol_version, the exact original close_key, digest_version, request_digest and the signed admission_descriptor. No payment value, new offer, new provider key, replacement key or freshly hydrated customer field belongs in it. The descriptor contains its own version, dedicated issuer/audience, immutable Sales admission ID, tenant, Organization, original actor, Person, originating Lead (including explicit absence), first Lesson, original soft command/ReceiptRef, payment motion, exact close key and shared digest. Correlate every duplicate field exactly. The descriptor establishes Sales original-command provenance, not Revenue admission or financial success, and alone cannot initiate collection. Sign only after Sales' durable valid human admission and final close-send preparation; persist the same signed bytes before any send. Recovery cannot reconstruct a changed descriptor from current UI state.

Specify a dedicated verification algorithm, key ownership/trust, closed claims, byte limits, issuance audit, rotation, revocation and historical verification. A current service JWT is not the descriptor. A descriptor's own timestamp cannot independently establish valid issuance before a key compromise/revocation. Unknown issuer, missing trusted historical key, unverifiable issuance or revoked/contradictory provenance must block unseen settlement. Previously verified durable Revenue admission can still support narrowly authenticated reconciliation without accepting a new artifact or new execution. Do not introduce an unreviewed shared signing secret or assume Platform already provides this signing authority. Sales, Revenue and Platform must approve this trust package before acknowledgment.

Recommend a versioned SHA-256 digest over a domain-separated canonical envelope containing operation, ordering/protocol version, tenant, Organization, exact close key and the normalized original close. Replace only the inline secret in that digest envelope with a separately domain-separated commitment to its exact original token bytes and source; bind link capture_id and source directly. Sales computes the inline commitment transiently before discarding the token. Revenue independently computes it from the original POST before preparation. Do not omit capture identity, hash a newly obtained handle or trust the incoming digest. The original reusable Revenue execution request remains private, distinct from this non-secret commitment.

Exact digest bytes are an approval prerequisite: UTF-8; prescribed JSON key and array order; identifier ordering; string escaping and Unicode handling; safe integer/currency rules; absent/null/default treatment; normalized historical_booking; offer versus offer-items; amount; originating Lead; optional payer fields; and explicit invalid/duplicate member handling. Follow existing parsed close normalization, including sorted unique offering IDs and false/absent historical-booking equivalence, without introducing new equivalences into v2 replay. Freeze both digest and normalizer versions. A bare implementation JSON.stringify or Delivery bind fingerprint is insufficient. Review token entropy/disclosure assumptions and logging exclusions for the commitment; it is not declared safe for arbitrary low-entropy secrets by this memo. Publish independent inline/link/no-payment vectors, equivalent offer ordering, changed token/amount/payer/resource vectors and absent/default boundary cases. Retain the descriptor and hashes, not payer contact data or recoverable token bytes, in Sales' recovery record.

Close registry, tombstones and delayed admission

Use a permanent Revenue registry identity (tenant, Organization, operation, protocol namespace, original close key) with exact digest/descriptor association, an admitted original association or a never-admitted tombstone, and immutable terminal receipts. Do not allocate another Order/reservation to implement recovery. A cryptographically verified descriptor in the approved new namespace can authorize reconciliation/settlement of an unseen original; namespace, digest, JWT and absence without that verified provenance cannot.

Both original admission and recovery acquire Revenue's common compatible-writer serialization before registry or resource row locks. Recheck exact identity and registry state in that transaction. If the original already admitted, recovery resumes only saved original context, provider preparation/keys, bind and writeback state. It cannot run fresh-ID construction or use current customer/offer/capture data. If truly unseen and independently eligible, commit a permanent exact never-admitted tombstone and immutable settlement receipt in the same serialization before returning noncommit. No reservation, provider preparation, bind or financial side effect may precede original registry admission. Two different digests for one identity conflict, without exposing another request or overwriting either outcome. Replay the original settlement, not a fresh timestamped decision.

Recommend closed recovery response variants: original_terminal carrying the exact retained original status/body, pending with exact original identity and reconciliation reason, and never_admitted carrying the exact permanent settlement receipt and no invented Order/reservation. The new envelope may include an immutable receipt reference for correlation. Reserved never becomes committed merely because a later payment arrives. Known terminal failures keep their exact original error interpretation. Pending is not failed/noncommitted; authentication failure, unavailable evidence and conflict remain distinct failures of this new operation. Exact codes, schemas and nondisclosing lookup behavior remain approval work. No existing original-close response is retroactively wrapped or rewritten.

The tombstone must defeat an in-flight delayed original POST, not just a later request reaching a new binary. Before any permanent settlement can be issued, deploy/enforce the registry check on every original admission path, deny unrecognized protocol/namespace before side effects, remove obsolete binaries' admission/dispatch database privileges or prove their drain, invalidate their ability to prepare/dispatch without a registered durable attempt, and inventory workers, retries, repair/admin/direct-SQL paths and external senders. An advisory lock, application flag or trigger acquired after an inconsistent row lock is not that proof. Retain historical registry/tombstone bytes indefinitely and prevent key reuse across operations/versions. Missing legacy journals, purged provider attempts, old keys or unverifiable descriptors remain quarantined uncertainty; no automated legacy backfill or tombstone. Registry lookup can serialize without a local transaction waiting on Sales, Platform, Delivery or a provider.

Permanent never-admitted close settlement proves only that this financial close cannot execute. It does not resolve an existing soft hold or permit Sales to create a replacement obligation. Delivery/Sales must separately resolve their exact original resource/blocker. New work then requires fresh independent admission; do not use a new key to bypass an unresolved original.

Financial quiescence and exact compensation protocol

Recommend Platform's distinct POST /api/v1/delivery/v1/lesson-holds/bind-compensations, with revenue-production-to-delivery-scheduling-bind-compensation-v1, subject system:revenue, audience delivery, sole scope delivery.scheduling.reservation.bind.compensate. Revenue owns an immutable compensation intent for the exact failed close and committed bind. It binds tenant, Organization, original close/digest, Order/reservation/Lesson/Person, bind key/digest/intent and original Delivery ReceiptRef, exact protection generation, compensation ID/key/digest, authority revision and narrowly enumerated failure reason. Different identity or generation is a conflict. Persist the exact outbound command before sending, and reuse its original key/bytes after response loss.

Choose a dedicated fresh Revenue evidence read, not an implied fifth ADR-0052 use or a new cross-domain signature protocol. Recommend the fourth new service policy in Platform's memo: Delivery system:delivery to Revenue, sole revenue.reservations.bind-compensation-evidence.read, exact GET /api/v1/reservations/{reservation_id}/scheduling-bind-compensation-evidence, with exactly organization_id, lesson_id, bind_intent_id, compensation_intent_id. All identifiers and original proof must match one coherent durable Revenue snapshot; no contact data, generic financial lookup or invented expiry lease. The three proposed business capabilities therefore require four new policies under this recommendation, in addition to the unchanged four ADR-0052 policies. Exact evidence response and no-store, denial/query/method schemas require owner approval.

The quiescence predicate is stronger than a failed response. Under Revenue serialization, permanently prevent new original preparation, invoice/charge dispatch and executable canonical financial continuation; resolve/drain every admitted attempt and sender that could still execute; durably record all provider outcomes and necessary internal writeback/reconciliation. Pending network sends, unknown provider outcome, successful collection with failed local writeback, executable invoice issuance/payment obligation, unresolved original money movement or work capable of collection blocks compensation. Preparation success alone is not payment, but an unknown preparatory effect is not silently discarded either. Definitive decline can qualify only after all exact attempt/effect predicates hold. A committed/reserved successful close is never reclassified as a failed close by this operation. No refund, forfeiture, generic unpaid-order cancellation or Sales Lost closure follows from this authority.

Make financial_quiescence_authorized an irreversible retained compensation decision, with original association, terminal attempt/fact references, authority generation and permanent no-new-collection enforcement. It is a proposed separate private evidence fact, not a new reservation lifecycle, funding state or dispatcher event. Once issued it cannot become executable collection later, including on rollback or from an old queued sender. Genuine newly received money/provider facts remain append-only recordable and require reconciliation; they never reopen this original intent. If owners cannot prove no future original money movement, they must not issue this authorization.

Keep Revenue's existing continuation protected while compensation is executable or its outcome/writeback is unresolved. Do not label it abandoned first. This avoids the current evidence sub-spec's conflicting combination of protected unresolved compensation and clearing protection only after terminal continuation. Delivery reads the dedicated irreversible quiescence authority outside its local transaction, then under its common Lesson/bind/settlement/cancellation and all-writer serialization checks the exact original receipt, immutable command, local protection identity/generation and current resource predicates. In one local transaction it consumes/transfers ONLY that intent's protection for this compensation, records its exact booking/lock transition and immutable outcome. There is no protection-clear-then-cancel gap allowing an unrelated writer to intervene. Dedicated compensation is the reviewed exception to ordinary terminal-evidence protection retirement; ordinary cancellation cannot borrow it.

After the exact Delivery receipt, Revenue records verification and owner-approved reservation/Order effects under its own serialization. Only after that local writeback and all compensation work are resolved may continuation become irreversibly abandoned. A lost Delivery response or failed Revenue writeback stays protected and retries the same compensation command; an already completed Delivery operation replays the same receipt without another transition. Late/different receipts cannot rewrite it. Terminal failure/conflict cannot justify silently dropping protection or forcing a generic cancellation. Resource/version disagreement remains pending reconciliation, with no replacement collection.

Revenue can locally void/release only a proven unfunded, exact failed-close reservation through the approved existing commercial transitions. No credit debit, refund, forfeiture or fabricated payment event should be introduced. The assembled contract must enumerate the precise Order/reservation/lesson/lock effects and existing credit.released v2 reason/actor, or specify why no event is emitted; this memo does not approve an invented reason code. Preserve append-only ledger and producer-transactional publication. Delivery must approve its exact transition, generation and replay semantics; Revenue cannot sign those for Delivery. This mechanism is not an adapter for general rescheduling, composite cancellation, trial rebooking or invoice replacement.

Resource/history boundaries, versions and acceptance requests

Support the minimal exact Platform resource verdict and nondisclosing errors in Platform's position. Current service/tenant/Organization reach remains required. Fresh active exact Person/tenancy and current business predicates govern a new original command or newly admitted effect. Authenticated recovery of immutable historical outcomes and genuine provider facts must preserve the original Person/Organization/actor even if the human session expires, a Person is archived/merged or tenancy changes. Do not rewrite saved hashes/receipts to a merged target, equate archival with noncommit or infer historical tenancy from current target membership. Existing admitted execution must be classified separately from admission of a new provider attempt; exact continuation/resource rules must say which is allowed or blocked. A current verdict is observation, not a remote commit fence. Authority unavailable retains uncertainty/protection. The Identity 9.5 historical re-key obligation needs an explicit immutable-record exception or declared breaking migration, as Platform requested.

Propose ordering v3.0.0; scheduling v2.1.0 with a new compensation sub-spec and explicit continuation amendment; credit-reservation-lock v3.6.0 with separately versioned compensation evidence; Identity v1.6.0 and service-auth v1.9.0 subject to Platform's compatibility objections. Scheduling/credit minors are recommendations only if original requests/responses and ordinary v2 writers retain their accepted semantics and the new exception is confined to the dedicated operation. If the assembled package instead changes existing required fields, terminal interpretation or consumer obligations incompatibly, use a major for the affected contract. Keep existing four-policy schemas and selectors intact. Declare actual publication/migration timing, at most the standard two-week deprecation window for replaced wire, and safe pause/quarantine/rollback; do not restart the ADR-0052 deadline or activate unsafe legacy senders through this review.

Before Revenue acknowledgment, Sales/Revenue/Platform must approve descriptor trust and digest vectors, original/recovery schema and exact eligibility, registry/tombstone linearization and enforced old-sender barriers. Delivery/Revenue must approve irreversible quiescence evidence, fourth policy, compensation/protection transition, all precise financial/resource effects and absence of cross-domain lock waits. All owners must approve actual versions, failure taxonomy and preserved inline/link/flow coverage. Sales' listed composite/reschedule/rebook/existing-invoice/top-up gaps remain separate coverage work, not automatically solved or deprecated here.

Later proofs must use source-pinned real handlers and isolated persistence: inline/link response loss before/after admission and every provider/writeback cut; same-normalized-body equality and immutable original success/failure replay; simultaneous/delayed admission versus tombstone including obsolete senders; wrong descriptor/key/digest/tenant/Organization/resource with zero effect/disclosure; provider success with failed writeback and unknown collection refusing compensation; exact definitive failure with compensation response loss/local-writeback failure; competing cancellation/bind/settlement/closure and protection-generation races; late genuine financial fact retention; expired human/changed Person-tenancy historical recovery; and rollback with permanent no-new-collection. Observe external dispatch and stable row content/counts, not only HTTP status. Label synthetic credentials, mocked providers and fixture resource authority. Design review and existing ADR-0052 local proofs establish none of these new production gates.

References and publication boundary

• Proposed ADR-0053 and approval request, pinned 3225646710eb3073a4e8e5e5f8a6fb9f07eeb1cf.
• Platform position and Sales position, pinned 74904433fe7c873288697a87aebd8ff0024232de.
• Ordering recovery v1.0.0, bind evidence v1.0.0, and scheduling compatibility, accepted 43cd36bc312cdda3e1e2543215df55a7ace52ab1.
• Revenue candidate d24da76a84e7fc72dc909a1d84c748e9d11d8d65: modules/sales-ordering-surface/{schema,service}.ts, modules/scheduling-bind/{schema,repo,service}.ts, modules/square-customer-bridge/service.ts, lib/financial-writer-lock.ts, and docs/adr0052-local-integration.md. These are local candidate source facts, not deployed guarantees.

Live Revenue open inbox refreshed at 2026-10-03T01:47:58.353Z showed the proposal and Platform/Sales positions. Live ledger refreshed at 2026-10-03T01:47:34.788Z had zero pending/working ADR-0053 entries. This position completes no runtime/publication commitment and changes no source commitment status. Root is sole publisher/indexer/freshness owner for the reviewed batch. Only this Revenue memo is authored; contracts, ADR, other owners' files, routing record, fixtures, tokens, databases and deployment settings remain unchanged. No duplicate task acknowledgment is requested.