Sales approves the scoped closure lineage design and retains runtime release gates

This acknowledgment is part of the atomic ADR-0050 decision and contract publication. It takes effect when the linked ADR, contracts and all four owner acknowledgments merge together and the merged source is indexed. An unmerged branch must not alter the live ledger.

Sales explicitly approves the scoped ADR-0050 design represented by the ADR revision and producer schema pins below. There is no remaining Sales design objection at this scope. Approval covers the immutable lineage and evidence model, producer-specific version interfaces, exact authority boundaries and Sales consumer behavior. It does not authorize production activation or claim that implementation, migration or release proofs have passed. Revenue and Delivery remain required deciders, with Platform's exact route review. The branch ADR records Accepted conditional on that atomic publication. Live canonical status remains Proposed until merge and indexing; runtime activation remains separately gated.

Exact reviewed pins

The ADR draft is Sales .cache/onboarding-closure/.tmp/ADR-0050-explicit-onboarding-closure-reevaluation-lineage-20261002.draft.md. Producer artifacts are in each owner's .tmp/adr0050-contract-20261002/; Platform artifacts are in .tmp/adr0050-auth-contract-20261002/. The canonical contract and ADR links below accompany these reviewed draft pins in the single coordinated publication PR. Changed normative artifacts require review of their delta; file names alone do not carry this approval forward.

Approved consumer decisions

Sales persists append-only per-obligation attempts, admitted generations and rejected keys, complete normalized requests, versions, fingerprints and allocated IDs before sending. Retry resumes the same saved step/key/body. Explicit Re-evaluate cancellation records a separate operator decision, current scoped preview, predecessor selection and abort/reaffirmation steps before child admission. The preview must explain that retiring old work does not guarantee a successor is eligible. Successful abort followed by child rejection remains Closure pending.

Revenue's invoice HeadQuery is exact order/external invoice/org/person/closure scope. Available, verified-empty and quarantined history are distinct; missing or stale records never authorize an invoice child. Full NoncommitProof is required for strict1.1 admitted predecessors. Historical v1 reaffirmation appends a new safe audit fact using the unchanged v1 abort interface and separate version-aware proof read, without replacing historical requests, receipts or the first existing proof. Sales verifies recorded original binding and audit hash; later v1 retry wording cannot rewrite them.

Sales accepts Delivery's explicit migrated-root wrapper and authorized old-reader operation_version_mismatch response, separately from Revenue's version-specific base reads and nondisclosing404. Each producer has its own decoder/version matrix. Neither error proves settlement. Delivery's abort uses a distinct abort UUID and exact recovery read. Unknown outcome retains fences and pending closure.

Delivery owns release mutation, old-intent mapping, upstream abort/noncommit-proof and never-admitted key settlement. Sales receives full bound immutable upstream evidence via its exact Delivery operation/abort read and independently verifies the actual completed Revenue release through existing authorized linked reads. Sales requests no direct release noncommit-proof/key-settlement read or release mutation authority. Platform's reviewed route map matches this boundary.

A never-admitted key is permanently non-executable, not a financial operation or receipt. Actual-operation references require authoritative direct settlement proof. Repeated unused keys retain recorded ancestry; Revenue must atomically claim the immediate and every proven never-admitted ancestor target's successor slot for the same actual child, together with parent uniqueness and head CAS. Aliases cannot create another successor after abort. Original same-key replay precedes new admission checks. Rejections stay outside generations and cannot later become successful operations.

Held receipts and settlement evidence remain release-only, correctly bound to system:delivery and the exact old/new intent as appropriate. Completed financial release requires ledger_reversal_created:false and clear current assessment. Preserved receipts with later contradiction do not resolve the obligation. Soft holds remain local-only and cannot switch kinds or bypass binding races. Delivery enforces one UNIQUE(tenant, lesson) head/protection across both kinds, with immutable kind within a root; no parallel soft/held heads are allowed.

Pending closure continues to stop outreach and exclude reminders, automatic closure and paid handoff while blocking new booking/invoice admission. Lost completes only after every explicitly linked obligation has current clear cancellation evidence and a final Sales linkage/version check, with one stage-change event and audit. Unrelated purchases and ambiguous/shared ownership retain their existing protections. ADR-0049 arbitration and terminal handoff exclusion remain unchanged.

Independent validation and limits

Sales independently loaded the exact Revenue snapshot and corrected Delivery schema offline into AJV Draft2020 with strict:true, allErrors:true and format assertions. All 73 expected outcomes passed: 46 Revenue examples and 27 composed Delivery/Revenue response examples, with zero compile failures. Only declared x-* documentation annotations were registered; strict validation was not disabled. Exact results and reproducible script are Sales .cache/onboarding-closure/.tmp/adr0050-composed-consumer-review-results.json and adr0050-review-composed.cjs. The prior strict compilation failures are resolved for these pins. Earlier independent Revenue review also matched all 14 canonical fingerprint vectors.

The composed examples cover held completion, receipts, mappings and abort evidence for admitted and never-admitted alternatives; soft operation/abort/preview; repeated unused root and existing-parent chains; invalid release subject and missing no-ledger-reversal evidence. These are separate synthetic histories. Passing JSON Schema is not proof of authority, copied-ID equality, current eligibility, durable global uniqueness or concurrency. Original-version request/receipt compatibility and unknown reason handling must still be enforced by consumer semantics and runtime tests.

Retained implementation and release gates

Revenue's control-row/writer-epoch/transaction-entry/BEFORE STATEMENT guard proposal requires exact DDL and runtime role privilege verification, exhaustive writer coverage, pooled-transaction isolation, old-process and provider-work drain, and migration/restart/rollback proof. A transaction-local marker alone is not a security boundary. Incoming financial truth must still be recorded when new closure admission is disabled. Rollback cannot lower the epoch, erase keys or restore an incompatible writer.

All producer admission/recovery paths, v1/v1.1 races, permanent key reservations versus late admission, transitive successor claims and partial rollback, provider/payment/lock/completion/bind races, response loss and process-crash boundaries remain runtime acceptance gates. Deployed authorization and external provider evidence remain distinct from local schema proof. Final integration must retest ADR-0049 arbitration, Sales duplicate actions, durable journal recovery, ongoing pending exclusions and exactly one final Lost.

All named owner acknowledgments and exact contract/service-auth/ADR changes must publish atomically. Their design approval does not waive implementation or release evidence. No runtime code, provider, fixture, production setting or canonical coordination file was changed by this review. This scoped design approval does not complete the broader ADR-0048 implementation or release commitments.

Canonical publication references

• ADR-0050.
• Revenue re-evaluation contract and schema.
• Delivery re-evaluation contract and schema.
• Service authentication contract.
• Sales acknowledgment, Revenue acknowledgment, Delivery acknowledgment and Platform acknowledgment.

The ADR publication revision adds canonical references and conditional atomic acceptance wording to the reviewed draft; the hash above intentionally identifies the reviewed design artifact. Existing v1 sub-specifications remain unchanged. The publication pipeline must validate PRs without indexing unmerged sources into the live ledger. No branch push is permitted until that read-only validation behavior is enforced.