Delivery requires exact release predecessor settlement before approving closure lineage
Delivery supports the proposed separate strict v1.1 surfaces, explicit predecessor identity and fingerprint, and one authoritative lineage head shared with every eligible v1 replacement writer. Delivery does not yet approve ADR-0050. Exact Revenue settlement evidence, never-admitted key reservation and partial-child abort semantics below must be agreed before acknowledgment or contract publication. This response contains no implementation or activation approval.
The source reviewed is ADR-0048 Delivery 24119b54f1cda747c7b420ce7894dd735f2a8884. The distinct ADR-0049 payment-handoff candidate is 5624d7b66574de346bf2b37cf31be85ff62a89ae; it is not the runtime for the ADR-0048 recovery or writer proofs. Paid ownership and preserved first-lock history from ADR-0049 do not establish cancellation eligibility or predecessor settlement.
Accepted design direction and current boundary
Keep ordinary recovery on the original immutable key. A new child must be an explicit decision against the exact current producer head, with the same authenticated subject, tenant, organization, person, closure and obligation identity. Actor/reason may describe the new decision but do not change authorization. A terminal cancellation receipt or completed lesson can never become an eligible predecessor merely because current policy changed.
The proposed additive Delivery command and read resource, /api/v1/delivery/v1/onboarding-closure-reevaluations and its operation-specific GET, are an acceptable naming direction. They remain unavailable proposed interfaces until exact schemas and Platform scope treatment are agreed. Existing v1 request fingerprints, receipts and strict response shapes must remain unchanged. New lineage metadata belongs to the versioned child representation, not retroactive edits to historical receipts.
Current Delivery preparation serializes on the schema advisory boundary, revalidates lesson and lock ownership and versions, and rejects any non-aborted operation already fencing the lesson. Its v1 wire has no explicit predecessor or authoritative lineage-head comparison. Existing abort history must not be advertised as mixed-version child admission proof. Both v1 admission and v1.1 child admission must join the same head and unique-child constraints before mixed-version traffic is permitted.
Exact Revenue release predecessor
For a held lesson, derive the predecessor release solely from the immutable request stored with the exact predecessor Delivery operation. Bind its Revenue operation ID and Revenue-normalized request fingerprint to the original Delivery operation ID used as cancellation_intent_id, organization, person, closure, lesson, reservation, account, expected predecessor reservation revision, actor/reason and invoice-operation associations. Validate those bindings against Revenue's authoritative operation record. Do not infer them from the latest reservation journal, an event arrival, an absent fence, or Sales' relayed receipt.
The child stores its own new Delivery operation ID and new Revenue release operation ID before external work. Its Revenue predecessor must be the exact settled release operation above. The new cancellation_intent_id is the child Delivery ID; changing that field does not erase the explicit old mapping. Retain valid completed invoice cancellation IDs and receipts, rather than creating invoice children to match the lesson generation. Revenue must independently assess the complete associated invoice history.
Never-admitted release and partial preparation
Delivery agrees with Revenue's separate typed never_admitted / key_reserved settlement evidence for an old Delivery intent whose release was never admitted. Revenue permanently reserves the already allocated release key and exact normalized request fingerprint, including the old cancellation_intent_id and all predecessor bindings above. The authenticated mutation serializes with actual admission and global operation-key reservation. Same-key replay returns immutable settlement evidence, changed payload rejects, and a delayed release cannot execute. This is not a fabricated aborted financial operation, receipt or outbox event. If an actual operation exists, use its authorized journal state and real safe-abort predicate. A local unsent flag, 404, expired lease, expired token or absent transport log cannot substitute for this producer guarantee.
The Delivery child explicitly references this settlement evidence. When there was no actual old Revenue release, the first admitted Revenue release may be a generation-zero root with an explicit binding to the unused-key settlement, rather than a fictitious predecessor. The permanent unused-key reservation sits outside the admitted Revenue chain. An actually admitted and then aborted Delivery or Revenue child remains its producer's head. If the old key and request were not durably selected, neither producer may guess them.
This requires Revenue to define the exact command and evidence representation. An equivalent authoritative never-admitted proof is acceptable only if it reserves the exact key permanently and is atomic with every admission path. Until that representation exists, preserve Closure pending and the local fence. Do not claim the existing v1 unknown-operation abort already supplies this capability.
For partial child preparation:
- Persist the child request, immutable predecessor mapping and protective local fence before sending its release work. A retry resumes this same child.
- Unknown or contradictory Revenue admission, release or abort outcomes retain the child's fence. A failed request is not proof that Revenue did no work.
- Abort requires an authoritative, exact, durable Revenue child-abort decision that prevents later commit, followed by a direct read. Re-lock and compare the local child/head and versions before recording local abort.
- A committed Revenue release cannot be compensated by reopening its reservation. Complete the local cancellation if still valid, otherwise retain reconciliation-required evidence and the protective fence.
- An aborted child remains durable history and the lineage head. A later re-evaluation names that child; it cannot create a sibling from an ancestor or rewind the head. A crash during local cleanup resumes the same abort and preserves all records.
Soft holds require only local settlement because the resource must be proven lockless and financially unlinked. Their abort and successor admission still serialize with binding, expiry, completion and recovery. Do not use soft-hold semantics to bypass an uncertain held-lesson release.
Migration, old events and rollback
Reconstruct roots and chains from authoritative historical operations and explicit existing predecessor edges, validating identity, acyclicity, unique children and agreement with the resource fence. Do not turn every historical row into an independent generation-zero head or elect a head by time or UUID ordering. Multiple ambiguous aborted histories, conflicting active fences or missing cross-producer links remain blocked until evidence establishes their relationship.
Delivery agrees that the resource head must use the producer's existing canonical fencing identity, including tenant and operation kind, without partitioning competing writers by caller, closure or generation. Same-key historical replay compares the stored immutable request before current-head admission checks. A competing rejected child key needs durable rejection evidence outside the admitted chain so it cannot later be reused with another payload. Its exact versioned read and error representation still needs joint publication.
All v1 and v1.1 writers must enforce a single resource head and at-most-one-child admission in the same transaction. A legacy fenced replacement may derive its predecessor only from the exact authoritative fence that it validates and advances atomically. If an old worker cannot participate, v1.1 stays disabled; an incompatible binary is not a safe rollback target after lineage admission starts.
Delayed events and recovery must resolve the exact historical operation they reference, re-read current producer evidence, and respect the current head. They may retain historical evidence or record a contradiction, but cannot advance a different generation, replace a receipt or reopen a canceled lesson. Preserve current assessment timestamps separately from immutable receipts.
A safe rollback disables new child admission while retaining all heads, children, tombstones, receipts and fences and supporting same-key recovery with a compatible binary. No down migration should drop lineage history or restore a pre-lineage replacement writer while children exist.
Decisions still needed
- Revenue: exact release predecessor fingerprint and settlement fields, permanently reserved never-admitted key representation, and terminal abort guarantees against all admitted/provider/canonical writers.
- Revenue and Delivery: exact partial-child abort/read envelopes, conflict codes and cross-producer crash recovery ordering. Local abort cannot precede authoritative release settlement.
- Both producers: deterministic migration reconciliation and mixed-version head/CAS enforcement, including behavior for ambiguous historical chains and incompatible workers.
- Platform: publish the exact route/scope mapping. Settlement and abort require the original mutation authority; read authority must never permit key reservation or another mutation. Tenant, organization and subject reach must remain unchanged.
The published invoice-response-loss and Sales lease-recovery cases are same-key evidence. The separate six-case Delivery writer tranche exercises existing ADR-0048 ordering, with mocked Revenue/Coaching evidence explicitly labeled. Neither is ADR-0050 child-lineage acceptance evidence. No additional commitment or production gate is created or completed by this review.