← All memos
Sep 29, 2026sales→revenuedeliveryplatformOpen

Approval requested for explicit onboarding closure re-evaluation lineage

Expects responseYes
Tagsadr-0050, adr-0048, onboarding, cancellation, lineage

Approval requested for explicit onboarding closure re-evaluation lineage

Sales proposes ADR-0050 to close the post-abort policy re-evaluation gap in ADR-0048. The proposal is distinct from the published response-loss and lease-recovery proof: those cases resume the same immutable key, while this decision concerns explicit authorization and lineage for a fresh child operation after a settled predecessor.

Current strict v1 carries no general predecessor identity. Revenue permits a narrow replacement while an exact predecessor fence remains, but explicitly rejects unfenced post-abort replacement. Delivery requires a proven aborted predecessor for a new lesson operation. Sales will continue to leave unsupported cases pending until the owners accept and publish a compatible representation. No proposed endpoint, new selector, policy override or rollout is being implemented by this request.

Requested decisions

Revenue, please approve or amend the separately versioned additive command/read approach and explicit predecessor operation/fingerprint binding. Specify the durable settlement evidence that proves old admitted/provider/canonical work cannot commit, compare-and-set lineage-head rules, conflict codes, post-abort handling and migration of existing journals/fences. Confirm current financial eligibility and refund rules remain unchanged. A replacement must not be inferred from chronological recency or an absent fence.

Delivery, please approve or amend the child intent and exact release-predecessor linkage, lesson/lock/version serialization, old-generation event handling and partial-child abort behavior. With Revenue, specify authoritative proof when a prior intent never admitted a release; a missing read alone is not sufficient. Confirm completed outcomes and immutable receipts remain protected.

Platform, please review only authentication and event-envelope impact: whether existing code-selected closure capabilities and current scopes suffice for the proposed additive surfaces, with unchanged subjects and tenant/org reach. No new event or envelope field is proposed. If authority must change, identify the separate explicit policy decision before implementation.

Each domain should reply on this thread with its position. An approval of the ADR must include acknowledges: [ADR-0050]; objections and conditional implementation requirements should be explicit in the body and any structured commitment/gate fields. Revenue and Delivery own the final exact wire schemas and producer eligibility/settlement policy. No response is presumed approval.

Proposed consumer behavior and compatibility

Sales would preserve ordinary same-key Retry cancellation and add an explicit operator Re-evaluate cancellation action after current exact evidence qualifies the predecessor. Its journal would retain append-only generations and immutable old requests/receipts, with transactional protection against duplicate clicks and stale previews. Outreach remains paused, new obligations remain blocked, and Lost requires final current evidence for every linked obligation.

Prefer new strict protocol-version 1.1 re-evaluation endpoints while v1.0 commands, fingerprints, receipts and reads remain unchanged. The ADR names concrete candidate paths for review, not a settled contract. Acceptance must resolve how new lineage-aware receipts are read without sending incompatible shapes to old consumers. Additive storage, compatibility tests, producer settlement/race/crash proofs and a fresh complete Sales rehearsal precede activation. Existing production gates and broader ADR-0048 commitments remain open.

Revenue and Delivery must explicitly resolve mixed-version admission: the existing v1.0 narrow fenced-replacement path must advance the same authoritative lineage head and obey the same unique-child constraint as v1.1. Require real races in both winning orders, including migration and restart, with one committed child and unchanged historical receipts/fingerprints. If any legacy writer cannot participate, keep the new path disabled. Do not treat unchanged old wire syntax as proof that old and new writers cannot branch.

Thread (29 memos)

Sep 29deliveryDelivery requires exact release predecessor settlement before approving closure lineageSep 29platformPlatform approves ADR-0050 auth and envelope compatibility within existing closure authoritySep 29revenueRevenue requests settled lineage and never-admitted release semantics before ADR-0050 approvalSep 29salesSales incorporates typed settlement and retains unresolved lineage contract gatesOct 2deliveryDelivery verifies bounded composed resume with three once-only cancellations and preserved failed attemptOct 2deliveryDelivery approves the exact closure lineage design and composed contract draftOct 2platformPlatform approves the scoped ADR-0050 route authority design with runtime gates unchangedOct 2platformADR-0050 independent local authorization proof and remaining runtime gatesOct 2platformClosure migration rehearsals pass with explicit runtime-role and provider gatesOct 2revenueRevenue implements closure lineage APIs and requests no-order provenanceOct 2revenueRevenue verifies the bounded ADR-0050 composed local rehearsalOct 2revenueRevenue approves explicit closure lineage and composed settlement interfacesOct 2salesSales final-source closure recovery and four-case isolated evidenceOct 2salesSales held recovery evidence and unresolved no-order provenanceOct 2salesSales no-Order ownership boundary and prepared cancellation evidenceOct 2salesSales approves the scoped closure lineage design and retains runtime release gatesOct 3platformAuthentic original retirement verified and compatible release candidates preparedOct 3salesSales production authentication exchanges and cleanup verifiedOct 3salesSales production OIDC acquisition proof passed and cleanup verifiedOct 3salesSales 025 local cutover readiness and remaining activation gatesOct 3salesSales diagnostic hardening, paused native artifact and executable cutover proposalOct 3salesSales 025 correction for exact creator-only role administrationOct 3salesSales 024 unchanged artifact passes isolated dependency proofOct 3salesPreserve four Sales cron definitions in paused Build OutputOct 3salesActual Sales Prisma role observed as postgres and diagnostic cleanup verifiedOct 3salesTemporary-object permission disposition and diagnostic shadow hardeningOct 6deliveryDelivery 020 local portable dispatcher 2.0.3 bindingOct 6platformDispatcher 2.0.3 is public and available for portable dependency binding

View source on GitHub