Revenue supports scoped scheduling authority and requires exact bind evidence and recovery decisions

Assignment ADR-0052/revenue/001; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. Revenue is a review participant. This memo is prepared in the Revenue coordination clone for the coordinator's collected publication batch. It has not been published or indexed.

Revenue supports separate Sales soft-create and Revenue bind workload policies, current human admission at Sales, and fresh service authority for durable retries without forwarding or persisting a human cookie. Revenue withholds full approval of ADR-0052 until the following exact decisions are incorporated and accepted by the affected owners. There is deliberately no acknowledges field. No implementation or release commitment is created.

Source findings

Revenue 5f10755c031897b6598a051f915c6864ee0901e1, modules/sales-ordering-surface/routes/close.routes.ts and lib/auth/platform-jwt.ts, authenticate the incoming Sales close with the Revenue-audience token, exact sales subject, revenue.sales-ordering.close scope, tenant and Organization reach. That token cannot authorize Delivery. modules/workbench/delivery-client.ts:273 sends the bind body and key without Cookie or service bearer. Caller-domain and deployment-protection headers are not authority.

At that pin, both close motions in modules/sales-ordering-surface/service.ts mint a reservation, persist it alongside the order, and then bind before the committed payment charge or reserved invoice issuance. The association exists in Revenue: Order.creditReservationId, reservation lessonId/Organization/window and the credit account's Person/OrgMarket. Nullable reservation Participant/type/site context is not evidence of absence of a valid close; Delivery resolves its own Participant-to-Person and lesson context. lib/mutating-api-idempotency.ts writes the completed response after the handler returns. A failure or crash after association commit but before response caching therefore needs explicit recovery of that association, rather than rerunning the handler's fresh-ID path.

Delivery 75589fa499b3c62ef94ef5702d5470c4781a1059, modules/lesson-hold/repo.ts, checks the bind response cache before lesson/resource checks. That cache lookup is keyed by Organization/key and scope, without request-body comparison. findOrCreateRequestedLockForHoldCreate can create a local requested lock from the supplied reservation ID without a canonical Revenue lookup. A local lock or a valid workload identity cannot establish the requested Revenue association.

Required contract decisions

1. Exact issuance and available proof. Amend service-auth v1.7.0 additively for the proposed delivery.scheduling.reservation.bind selector/single scope, aud: delivery, proposed output sub: system:revenue, fixed tenant and explicit Organization reach. Platform must approve the output subject and exact production Revenue proof subject, issuer and exchange audience, rather than infer them from the project name. Include Revenue as a workload caller. The reviewed Platform workload policy code has no Revenue scheduling policy. Specify how each admitted Revenue runtime, including unattended recovery, obtains a fresh proof with the exchange's exact audience. Production Vercel, preview, local and cron availability are separate evidence; no root mint secret, operator-token fallback or borrowed Sales proof. Retain RS256, audit-before-return, no-store and maximum 300-second service-token lifetime.

2. Delivery-verifiable association. Amend scheduling sections 4.1b and 8.5, not only 8.5. Require Delivery to verify Revenue's committed order-to-reservation-to-lesson association, exact tenant/Organization, account Person and Platform Market, reservation lesson/window, and Delivery's Participant-to-Person plus canonical lesson context before a new bind. Same Person or same Organization alone is insufficient. New binds require an active reserved reservation; do not require funded, since committed close binds before charging and reserved close can be pending funding. Released, forfeited, consumed, refunded, wrong-market and unrelated-order cases cannot initiate a new bind.

   Revenue recommends an explicit authenticated read interface, proposed GET /api/v1/reservations/{reservation_id}/scheduling-bind-evidence?organization_id=...&lesson_id=..., returning only canonical tenant_id, organization_id, order_id, reservation_id, lesson_id, credit_account_id, person_id, platform_market_id, window, lifecycle/funding state and a defined freshness/revision marker. Revenue derives these fields from its association, rejects absent or ambiguous order linkage, and never trusts caller-supplied association facts. Delivery compares them to its locked lesson and records the evidence reference with the bind. Prefer a separate Delivery-to-Revenue selector and single revenue.reservations.bind-evidence.read scope, with system:delivery as the only subject. This is a proposed additional read policy, requiring Platform and Delivery approval and exact schema/errors, not authority implicitly granted by the two scheduling selectors. A different evidence mechanism is acceptable only if its trust, freshness, outage and cancellation-race semantics are equally explicit. No shared database access or general Order read is implied. Missing/inaccessible linkage should remain nondisclosing; unverifiable evidence fails closed without a lock, key reservation or event.

3. Exact retry authority. Before the first outbound bind, Revenue must durably associate the admitted close and stable bind key with its original order/reservation/lesson and normalized business request. Recover those same IDs after issuance failure, process death or response loss. A new bearer/jti must not alter the command identity or historical request/receipt bytes. Delivery must authenticate and authorize the exact resource before every cached response, reject same-key/different-body requests, and return the immutable original receipt for an authorized exact replay without re-holding, re-emitting or pretending the current lifecycle is still held. New-bind eligibility and historical successful replay predicates must be distinct. Define serialization/fencing for bind versus reservation release or closure so a read-time eligibility snapshot cannot authorize a later contradictory mutation. Expiry, 401/403, timeout or issuance outage is not proof of noncommit and must not trigger a fresh reservation, compensation or new charge by itself.

4. Bounded compatibility and cutover. Preserve the existing bind business-body shape where possible by deriving evidence from the reservation/lesson, retain original keys/receipts, and publish exact error distinctions for authentication, scope, linkage conflict and transient evidence/issuance failure. Pin contract versions, accepted owner decisions and rollout order before implementation. If temporarily disabling close admission or bind is necessary, obtain the affected owners' explicit decision. No unauthenticated fallback, silently disabled bind gate, or automatic expansion into inspection, cancellation, closure, refund or Coaching eligibility. Existing post-bind charge/invoice failure compensation remains a separate authority dependency; the new bind token does not authorize hold-cancel.

Acceptance criteria

Prove real Revenue runtime exchange and the exact bind route with accepted policies, canonical pending-funded and funded associations, and separate denial cases for missing/expired/not-yet-valid proof/token, preview or wrong subject, wrong issuer/audience/tenant/Organization, closure scope and a valid nonempty unrelated scope. Denials must not persist a Delivery lock/idempotency entry/event or start a downstream charge/invoice. Revenue associations already committed before issuance fails remain recoverable pending state.

Prove wrong order, reservation, lesson, Person, Participant, market and window linkage; evidence outage/staleness; bind racing release/closure; and exact same-key replay after response loss and after the initiating human session expires. Inject a crash between Revenue association commit and close-response caching and verify original IDs are recovered with no duplicate reservation, order, provider charge, lock or event. Changed-body replay must fail before disclosure or mutation. Successful historical replay must not recreate a released hold. Test post-bind financial failure and separately authorized compensation without borrowing bind scope. Distinguish local substitutes, source proof and deployed evidence.

Reviewed pins and publication handoff

Canonical coordination HEAD 2ac56cfb4de72b1725bf522d537b5bec16ba0ea6, ADR-0052, its request memo, service-auth v1.7.0, sales-scheduling-surface sections 4.1b/8.5, credit-reservation-lock, and Revenue scope/module conventions. ADR SHA-256: 040c11e2fa3f992eb8638f2f2a34dc51d227cc4775e54b196a1ab0ef2acb8cad.

Platform audit checkout 8f877adca494d1fd23cc404cf64423d06a35565d, docs/adr0050-scheduling-session-boundary.md (SHA-256 a7f04b4ac34c1c155d1a725db34851cc5f69e2c9627c11d1db39bdeef9f8d558) and modules/service-auth/workload.ts; audit Sales pin d31ddf1a4bd233c3d4e2714350452de8b7cbc878. Direct Revenue and Delivery pin inspections are stated above. The current Revenue checkout HEAD is fecab1cc63c5ef46aad551b3bb4a438ff3606a21 with unrelated uncommitted work; no runtime edit or production claim is made.

Live ledger/inbox checked at 2026-10-02T23:52:24Z; the ADR-0052 owner request is open and declares no commitments. This draft does not close its approval handshake. The coordinator retains publication, indexer and freshness responsibility for the collected batch. No token issuance, database mutation, service restart, deployment or rehearsal occurred.