Revenue accepts durable bind fencing and specifies financial handoff and revision corrections
Assignment ADR-0052/revenue/002; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. Review of canonical batch e09826ffa22aab5ae3e817df9d7c0e9f7ebb1c30. This is a Revenue-authored second architecture position, prepared for the coordinator's publication batch. It creates no implementation commitment or other owner's approval. The Revenue coordination clone is still 2ac56cfb4de72b1725bf522d537b5bec16ba0ea6; the new canonical materials were inspected read-only in Platform's clone.
Architecture decisions accepted by Revenue
Revenue accepts a durable local scheduling fence, atomic original close/order/reservation/lesson admission, narrow authenticated evidence GET, and separately authorized Delivery bind settlement with permanent committed-or-noncommitted evidence. A timeout, expired JWT, missing receipt, hold expiry or lost settlement response never releases the fence. No distributed transaction, remote fence-acquire route, expiring safety lease or shared database is required. Permanent exact command identity and immutable receipts/tombstones are necessary; historical uncertainty stays quarantined rather than converted into new work.
Revenue accepts reserved reservations with either pending funding or funded allocation as bind-admission candidates, subject to normal eligibility and canonical association checks. Pending funding is a supported close state, not missing authorization. Bound historical receipt replay may occur after later lifecycle advancement without recreating a hold. Financial progression requires current business readiness, not merely that historical receipt.
Revenue confirms the proposed DESIGN pin owner:jack-allreds-projects:project:revenue:environment:production, proof issuer https://oidc.vercel.com/jack-allreds-projects, scalar exchange audience https://platform.sguildswim.com/api/auth/service-token/exchange, and output system:revenue. The two Revenue-to-Delivery policies are separately scoped bind and settle, audience delivery; evidence-read is Delivery-to-Revenue with system:delivery, audience revenue. Tenant is tnt_sguild, reach is exactly [org_01900000-0000-7000-8000-000000000001]. Revenue accepts the four-route policy map, fresh audited token per outbound attempt, no credential persistence, and the stated maximum residual 300 seconds plus at most 30 seconds tolerance after issuance disablement. This confirms the intended policy identity, not an observed production OIDC subject or available exchange. Actual production proof acquisition/exchange remains an implementation gate.
Revenue accepts the explicitly delegated service-owned recovery rule: valid immutable admission survives later initiating-human expiry, Organization switch or membership/permission removal, while those changes block new human admission. Current workload/Organization/resource authority and financial restrictions remain mandatory. Revenue has no objection to Sales' exact active-Organization sales|owner|admin permission conjunctively with fresh matching-user Platform app access; Platform owns ratification of that permission surface.
Concrete corrections required in the proposed protocol
Financial fence handoff. Replace the unconditional “record bound and clear scheduling fence” progression clause with: after verifying committed Delivery evidence, Revenue atomically records bound and either retains its protection or transfers protection to the exact close's financial execution fence under the common serialization boundary. Before admitting any new provider charge/invoice work, it verifies current booking authority and no competing release/closure/financial operation. The durable provider attempt and its stable provider key are admitted before external dispatch. Response loss resumes that attempt; it cannot admit another charge. A later release cannot race between bind-fence removal and financial-attempt admission. If booking readiness is unavailable or cancellation already won, retain pending/reconciliation state and initiate no new collection. Where no financial continuation is admitted, fence removal still requires a serialized decision that prevents that old close from later starting collection without rechecking current authority.
Incoming money truth. Reject any interpretation that the scheduling fence blocks recording a genuine provider payment/refund or rolls back an externally completed fact. Preserve provider-success versus internal-writeback separation. Persist verified incoming financial facts and their proper producer-transactional events; defer or reconcile conflicting reservation allocation, locking or terminal transitions while bind remains unresolved. A funded account balance may change without changing bind identity. Refund/provider reconciliation cannot silently release, consume, forfeit, repoint or resurrect the fenced reservation. Exact writeback staging and recovery must be specified and proved before activation.
Revision semantics. Use the existing authoritative reservation closureRevision as reservation_revision, rather than a second competing reservation clock. Capture immutable admission_reservation_revision in the bind admission/evidence alongside the current monotonic reservation_revision. Add an intent-owned intent_revision for compare-and-set settlement transitions. The immutable identity/fingerprint and original admission revision never change; current reservation/intent revisions can advance. A legitimate payment writeback must not make a later exact committed/noncommit settlement permanently fail a stale admission-revision equality check. Settlement validates the exact intent, retained association, evidence and allowed current state under lock, then CASes its current intent revision. Pending evidence permits only the original bind. Bound/noncommitted evidence permits authenticated history checks, not new admission.
Revision and fence coverage must include association changes outside the reservation row: account Person/Organization/market repointing, Order-to-reservation provenance, and mirrored lesson/window changes. Such writers either deny the change while unresolved or serialize a permitted change and update the coherent reservation/evidence revision. as_of and a local lock alone are not that proof. Never manufacture canonical market from a legacy label or require nullable Revenue Participant/type/site fields as admission evidence.
All invalidating writers. Revenue ratifies common database serialization and enforceable writer exclusion across ordinary release, void, forfeit, attach/repoint, lock, funding/refunding/refunded transitions, consume/no-show, outcome corrections, duplicate-corruption repair, generic repository status resolution, and guarded onboarding release/recovery. Include related account/market repointing, Order/invoice/provider association and financial-attempt writers, lesson-mirror updates, cron/inbox jobs, administrative scripts and obsolete deployed binaries. The concrete source inventory includes modules/credit-reservation/service.{release-pg,release-api,void-pg,forfeit-pg,attach-lesson-pg,lock-pg,funding-pg,duplicate-corruption}.ts, modules/credit-reservation/repo.ts, modules/lesson/service.consumed-pg.ts, modules/lesson-outcome-correction/service.ts, modules/onboarding-closure/service.ts, and modules/market/repo.ts. This is an initial inventory, not proof that every writer is covered. Old workers must be drained or database-rejected before admission resumes; an application-only check is insufficient. Ordinary reservation resolution must not bypass the fence because it uses a generic repository path.
Settlement verification and unknown outcome. Revenue requires a fresh authenticated exact-settle response, with strict variant validation and equality of tenant, Organization, intent, reservation, lesson, original bind-key digest and fingerprint. Committed evidence additionally binds original lock/version/event/receipt digest; noncommitted evidence requires null receipt and permanent producer tombstone. The returned proof is persisted atomically with the intent's terminal transition and fence transfer/removal. Retry the same settlement ID after response loss. A contradictory response, unknown variant, inaccessible evidence or proof/receipt mismatch stays unresolved/reconciliation, never a blanket unlock. Freeze new bind sends before settlement, but permanent Delivery serialization/tombstones must also defeat already delayed in-flight sends. Retained terminal association evidence must remain readable after Revenue clears the fence, subject to current exact ownership checks, or receipt replay would deadlock.
Release and ADR-0050 integration. Ordinary release returns its existing 409 error envelope with conflict_reason: scheduling_bind_pending; it does not cache that transient denial as a permanent financial receipt or convert it into release success. While the fence exists, a new guarded release fails eligibility admission; under ADR-0050 strict child admission this is the existing immutable current_eligibility_blocked rejection with the scheduling reason in the allowed assessment, not an admitted operation that later silently executes. An existing admitted guarded release retains its journal/head/generation and fence, reports blocked current assessment containing scheduling_bind_pending, and cannot execute release, claim completion or infer safe abort/noncommit from this reason. Already completed historical receipts remain unchanged; later assessment can report a new conflict without changing history. Once scheduling is settled, re-evaluate using the existing operation-version and explicit successor rules. Never auto-resurrect a rejected candidate, reallocate its key, clear a closure fence, or repurpose an ADR-0050 NoncommitProof as scheduling settlement. Invoice cancellation and financial dispatch share the same association/execution protection so cancellation cannot race an admitted collection. These are ADR-0052 integration requirements, not a new ADR-0050 assignment in this chat.
Version classification and gates
Revenue accepts scheduling v2.0.0 for mandatory protocol admission, changed-body rejection and permanent replay identity; service-auth v1.8.0 is additive for four isolated policies. Credit-reservation-lock v3.5.0 is suitable for the additive evidence/fence sub-spec and new fail-safe release conflict without changing lifecycle/funding/event vocabularies. Amend reservation-release-api v1.1.0 to name scheduling_bind_pending and its same-key retry behavior. Existing consumers already must fail safely on unknown release reasons; do not claim they understand automated scheduling recovery until upgraded.
Sales-ordering v2.9.0 is suitable for internal durable association/provider-attempt recovery and additive integration only while preserving existing close request/success/terminal-receipt shapes and historical command identity. A mandatory new Sales-to-Revenue request/header, changed success schema or reinterpretation of a previously terminal close outcome requires v3.0.0, not a minor label. Explicitly resolve the old hold_bind_conflict fresh-key/re-soft-hold guidance: it may initiate a replacement only after exact noncommit and separately authorized resolution of the prior reservation, never merely after timeout or a current replayed receipt. Schemas and compatibility examples must demonstrate which wire behaviors change.
Revenue accepts the cutover architecture of paused new admission, writer inventory/barrier, exact reconciliation or quarantine, coordinated issuer/producers/callers, and rollback that preserves protection and cannot restore unfenced writers. The actual pause interval, migration/deprecation window (within the organization standard), deployment order and producer/caller readiness remain explicit owner release decisions. This review does not approve a live pause or deployment.
Revenue accepts the core architecture clauses above but rejects unconditional fence clearing and financial-truth suppression, and requires the stated revision/assessment corrections in the canonical decision. Full ADR acknowledgment remains withheld, rather than attaching a conditional blanket acknowledges. Acceptance of future strict schemas/examples is a separate contract gate; runtime and rollout proof are separate activation gates.
Required later proof includes all covered writer races, genuine incoming payment during unknown bind, release versus bind/settlement/charge admission, lost responses and delayed binds after tombstone, crash before close cache, permanent replay beyond 24 hours, and settled replay after later lifecycle advancement. Verify one original order/reservation/provider attempt/charge, exact ReceiptRef/event association, no denied mutation/disclosure, current-revision versus admission-revision behavior, new-human denial with admitted service recovery, and rollback preserving every fence/journal/tombstone. No runtime test suite was run for this review-only memo.
Evidence and handoff
Reviewed canonical e09826ffa22aab5ae3e817df9d7c0e9f7ebb1c30: ADR-0052, Delivery fenced revision, Platform admission/revocation and initial authority positions, Sales admission/recovery supplement, credit-reservation-lock v3.4.1, service-auth v1.7.0, scheduling v1.12.0, sales-ordering v2.8.0 and existing release/ADR-0050 sub-specs. Prior immutable source pins remain Revenue 5f10755c031897b6598a051f915c6864ee0901e1, Delivery 75589fa499b3c62ef94ef5702d5470c4781a1059, Platform audit 8f877adca494d1fd23cc404cf64423d06a35565d, audit-derived Sales d31ddf1a4bd233c3d4e2714350452de8b7cbc878. Supplemental writer/trigger inventory inspected current Revenue HEAD fecab1cc63c5ef46aad551b3bb4a438ff3606a21 plus existing uncommitted work, specifically the closure migration's revision/serialization guards; that working tree is not claimed as a deployed or accepted implementation.
Live ledger checked 2026-10-03T00:07:09Z (October 2 in America/Chicago); no ADR-0052 implementation commitment was completed by this review. Only this new memo was authored. No implementation, token issuance, database mutation, service restart, deployment, independent publication/indexer or ADR-0049/0050 runtime work occurred. Coordinator retains collected publication, indexing and freshness checks.