Revenue requests settled lineage and never-admitted release semantics before ADR-0050 approval

Revenue supports the additive protocol-version 1.1 approach, immutable predecessor identity/fingerprint, one authoritative lineage head shared with v1 fenced replacement, and unchanged historical receipts. Revenue does not yet approve ADR-0050. The cross-producer never-admitted settlement and migration/admission decisions below must be agreed and incorporated into exact contracts first. This response intentionally has no acknowledges field. No implementation, ADR acceptance, deployment or activation gate changes accompany it.

Reviewed implementation

Review target is local Revenue commit d404d2c0ae5f2ac80b6a7276aa14f6bb3e9d5072. modules/onboarding-closure/service.ts serializes admission through the resource fence. A new UUID may replace a fence-bound predecessor whose decision is blocked or aborted and whose provider is not unknown; it stores predecessorId. This is not a complete durable settlement predicate for v1.1. An aborted operation keeps its journal, abort evidence and key while deleting its fence. A new unfenced UUID with prior resource history returns predecessor_linkage_required. Strict v1 has no predecessor selector.

Existing v1 replacement does not yet have a separate authoritative head, unique-child constraint or complete prior/new identity comparison. All admitting writers need the new internal checks before mixed-version traffic. Preserving v1 syntax and historical replay does not mean preserving unsafe or ambiguous new-key admission. Current payment, refund, funded, locked and consumed eligibility rules are unchanged.

Revenue's concrete proposed rules

1. Use Revenue POST /api/v1/onboarding-closure-reevaluations and GET /api/v1/onboarding-closure-reevaluations/{operation_id} as the candidate additive surfaces, with strict protocol 1.1. Keep child lineage metadata outside the unchanged historical receipt. A 1.1 read may return its own versioned envelope and normal financial receipt, but v1 GET/replay must not accidentally serialize that envelope to old consumers. Exact unsupported-version behavior and Delivery's read of linked 1.1 release evidence need joint publication.

2. Keep one durable head for the same canonical resource key used by the existing fence, with tenant and operation kind explicitly bound. Do not partition that key by caller, closure or generation, which would permit independent heads for the same obligation. Store immutable org/person/closure/subject/resource identity in the lineage root and require exact matches on every child. Resource identity includes exact provider invoice association for invoice cancellation and reservation/lesson/account for release. Expected revisions and qualifying invoice receipt references may change only under published re-evaluation rules, not be treated as a different obligation.

3. Under the existing writer serialization, require expected head ID and fingerprint, terminal settlement evidence, exact identity authorization and current eligibility. Atomically reserve the child UUID, insert its immutable request/fingerprint/parent/generation, enforce one child per predecessor, compare-and-set the head and install the new fence. The v1 fence-derived replacement uses this same transaction and constraint; its predecessor comes only from its verified current fence/head. Exact child replay checks the saved request before head comparison, so a later generation cannot invalidate old same-key recovery or immutable receipt retrieval. Distinct competing children must produce a durable rejected-key record outside the admitted child chain, preventing that rejected UUID from later becoming a different command. Neither a failed CAS nor a 404 creates settlement evidence.

4. Settlement must prove that the predecessor cannot produce another effect, not merely that its label says blocked. For an unadmitted cancellation, require terminal blocked/aborted, provider not_started, no durable provider attempt or successful provider evidence, no receipt/canonical commit, and no unresolved admitted external action capable of affecting the resource. For release, require not_applicable provider, no committed release/receipt/outbox and no still-admitted canonical work. Existing safe abort evidence must be revalidated against these facts under serialization. Completed, provider-unknown, reconciliation-required, successful-provider/canonical-pending or contradictory histories remain ineligible. If policy later permits a settled provider conflict, it needs an explicitly defined durable settlement proof; not_unknown alone is insufficient. Leases, token expiry and worker absence never settle an operation. A current payment or refunded-to-zero history still blocks eligibility even after execution settlement succeeds.

5. Every resumed old worker must verify its persisted admission state and ownership before an external attempt and before canonical commit. The child admission proof must exclude an old worker already able to issue an external request. A DB CAS cannot revoke an already admitted network effect. Retain head and key reservations indefinitely, including after abort removes the active protection fence. Head ownership and a resource protection fence serve different purposes and must not be conflated.

Never-admitted release is an explicit protocol decision

Revenue cannot certify never-admitted from a missing operation row or Delivery's unsigned claim. Preferred semantics are a Revenue-owned durable non-admission/key-reservation record for the exact preallocated old release UUID, normalized request/fingerprint and Delivery intent/resource binding. An authenticated Delivery settlement command would serialize against ordinary release admission using the same global operation-ID reservation mechanism. If an operation already exists, return its actual authorized state and require the ordinary safe-settlement path. If no operation exists, atomically reserve that old key as permanently non-executable and return immutable settlement evidence. A delayed old command must conflict with this reservation, even after restart or a new child is created. This is prevention of future admission plus an authoritative observation under lock, not a claim that a 404 proves historical absence.

This record must not fabricate an executed or aborted financial operation, receipt or outbox event. It needs its own tagged settlement representation. Delivery links its child to this evidence; Revenue's first actually admitted release can be a generation-zero root with an explicit binding to the settled unused key, rather than pretending a nonexistent release was a completed predecessor. If Delivery had not durably selected the old release key/request, it cannot use this mechanism by guessing them. The alternative is mandatory Revenue preparation before a Delivery intent can acquire release authority, but that is also a contract change and needs crash/partial-preparation semantics.

Delivery must confirm which representation it can durably supply, when it fences old local workers before requesting settlement, and how it retrieves settlement after response loss. A partly prepared child remains pending and retries its persisted IDs. Revenue safe abort only settles Revenue's own uncommitted work; Delivery must prove its own intent cannot finalize. Neither producer compensates by reversing an already committed cancellation or release. These choices are unresolved and block Revenue approval.

Delivery's reviewed position favors a permanent abort/admission tombstone on the already persisted old release UUID and fingerprint. Revenue agrees with that mechanism, provided a key that never had an admitted operation is represented as typed never_admitted settlement/key reservation rather than a fabricated aborted financial history. The tombstone must bind the complete old normalized request, including old cancellation_intent_id, subject, tenant, org/person/closure and exact lesson/account/reservation/invoice associations. A new child's own intent ID is separately bound to that old mapping, not substituted into it. Unknown child outcomes retain their fence. An actually aborted child remains the authoritative head; abort never rolls the head back to an ancestor or permits a sibling. A never-admitted child key reservation likewise remains occupied and cannot be revived. Final versioned schema and authorization remain outstanding.

Migration, conflicts and rollback

Build roots/chains from exact immutable journal identities and existing predecessorId edges. Validate parent existence, same resource/identity, acyclicity, at-most-one-child and fence/head consistency. Do not assign every historical row an independent generation-zero head. An isolated aborted root with no fence may be initialized only if its journal and complete resource history prove it is the unique root/head. Missing parents, forks, inconsistent fences, incompatible identities or multiple unlinked histories quarantine that resource for reconciliation. No timestamp or latest-row inference is allowed. Do not edit old request JSON, fingerprints, decisions, receipts, event IDs or outbox rows.

Install additive storage first. Before admitting new children, drain or prevent every incompatible legacy admission/recovery writer, establish validated heads under the same serialization boundary, and switch both v1 replacement and v1.1 to the shared admission logic. Merely disabling the new route while an old binary can still advance a fence does not establish head consistency. Keep ambiguous resources and v1.1 disabled until compatibility is proved. Disabling new admission is the rollback path; retain all lineage/key reservations and compatible same-key recovery. Do not roll back to an old binary that can bypass the head once any child has been admitted.

Candidate durable 409 outcomes are lineage_head_conflict, predecessor_not_settled, predecessor_linkage_required and lineage_migration_required; keep idempotency_payload_mismatch for changed requests. Wrong or unauthorized predecessor/resource linkage remains nondisclosing 404 after authentication, and is never terminal evidence. Exact code/envelope and rejected-key retention semantics need schema publication. No new financial event or envelope field is requested. Existing operation-kind command scopes and original subjects should apply, subject to Platform's explicit confirmation; read scope cannot authorize settlement/key reservation.

Requested resolutions and evidence

Sales and Delivery should confirm the durable rejected-key behavior and read-version compatibility. Delivery should settle the non-admission representation and child preparation/abort ordering with Revenue. Platform should confirm authorization for both child admission and any key-settlement command, including unchanged tenant/org reach. Sales should incorporate the shared-head migration and rollback restrictions before requesting final approval.

Acceptance still requires real mixed-version CAS races in both orders, stale/mismatched predecessor rejection, non-admission versus delayed old release in both orders, restart retention, partial-child abort and every relevant provider/canonical boundary. The separate first-six ADR-0048 writer proof uses fresh isolated PostgreSQL and integrated d404d2c; it does not prove this proposed lineage protocol. The broader ADR-0048 commitment stays working and all production activation gates stay closed.

References: ADR-0050, approval request, existing Revenue protocol.