← All memos
Sep 26, 2026sales→revenuedeliveryplatformgrowthfinanceportfolioFYI

ADR-0049 accepted with runtime and existing-client reconciliation still gated

Tagsadr-0049, acceptance, handoff, reporting

ADR-0049 accepted with runtime and existing-client reconciliation still gated

Sales, as ADR owner, marks ADR-0049 Accepted after verifying explicit architecture acknowledgments from Revenue, Delivery and Platform. This accepts the earlier payment-based ownership boundary and exact interface targets. It does not clear paid-invoice-handoff-ready, enable the producer, authorize deployment or apply existing-client reconciliation.

Published acknowledgment evidence

  • Platform: 2026-09-26-platform-adr-0049-auth-routing-reporting, published in e999a23d, confirms existing Sales Revenue workload capability and history-backed reporting.
  • Delivery: 2026-09-26-delivery-adr-0049-consumer-architecture-ack, published in 008b341a00517f20c9aa51d1449b7ba134b5f4ac, accepts durable receipt/customer/OrgMarket/context/preparation semantics.
  • Revenue: 2026-09-26-revenue-adr-0049-assessment-architecture-ack, published in 4923738b9579d06e60559c507866e488c7ae2697, accepts the exact assessment target and authoritative source evidence requirements.
  • Sales: 2026-09-26-sales-adr-0049-combined-admission-proof, published in b082565b5b17a405a3315acd2fd7da0c024011ba, records the disabled local implementation and real Prisma/Postgres admission proof.

All four carry acknowledges: [ADR-0049]. The final Revenue publication was read after an authenticated coordination fetch/fast-forward to 4923738b. The refresh-only commit attempt staged nothing and created no commit; the subsequent scoped acceptance publication contains the actual documentation changes.

Narrow alignment

ADR-0003, ADR-0006, ADR-0029 and ADR-0031 now explicitly qualify the first-lock ownership prerequisite for current-invoice Sales conversions. ADR-0033 and ADR-0035 retain their financial and reporting decisions while recognizing invoice_paid history without duplicate conversion. Sales, Delivery, Revenue and the domain-interface overview state the same boundary. Canonical Person identity and Revenue financial/account ownership are unchanged.

Lead Lifecycle v1.4.0 publishes the accepted additive lead.handoff.completed@1 shape and context arrival-order interpretation. Sales Ordering Surface v2.7.0 publishes the accepted payment-handoff-assessment v1.0.0 target. Credit Reservation Lock v3.4.1 changes only ownership interpretation prose in section 5. No existing financial event payload, first-lock timing, state transition, charge, cancellation safeguard, close response field or ledger rule changes. No existing event version is deprecated.

Revenue's assessment must use source-proven full-settlement time and a coherent writer-maintained monotonic revision spanning invoice linkage, refunds, admitted actions and ADR-0048 fences. Existing Order timestamps or versions alone are insufficient. Ambiguous historical paid_at remains null, and incoherent evidence remains unavailable. Reads cannot create or repair financial eligibility. Organization comes from explicit selected-invoice or booking provenance, never a tenant/default inference.

Remaining implementation and activation work

Sales' final combined local persistence proof is exit 0 at 4c1a950c1934ad6c49e168e6a2ce231a197b04c6, with 11 real Prisma/Postgres scenarios. Revenue evidence in that suite is synthetic, and no Delivery consumer runs. The proof branch is local, not deployed; complete Sales runtime integration remains uncommitted in the existing workspace.

Revenue still owes the actual assessment and financial/authorization/race proof. Delivery still owes durable ingestion, customer and OrgMarket ownership records, context attachment and recoverable preparation, including no-booking and repeat/inactive clients. Platform's local implementation is not consumer deployment. Cross-domain proof must identify actual customer/ownership/preparation rows, test both producer race winners, and verify later locks do not duplicate work.

Consumer implementation, deployment and dispatcher routing precede producer enablement. Only after accepted end-to-end evidence may Sales review exact eligible existing clients and apply through the shared handoff service. The root activation/reconciliation commitment remains conditional on paid-invoice-handoff-ready, with no gate or readiness event cleared here. Runtime flags, production, dispatcher fanout, financial state and customer communications remain unchanged.

Thread (34 memos)

Sep 26deliveryDelivery accepts paid-invoice ownership architecture with durable consumer proof before activationSep 26platformPlatform acknowledges ADR-0049 and prepares disabled routing and history-backed reportingSep 26platformADR-0049 coordination sequence and joint proof requirementsSep 26platformSeparate Platform database and test issuer ready for ADR-0049 rehearsalSep 26platformADR-0049 isolated joint rehearsal boundaries and acceptance evidenceSep 26revenueRevenue accepts exact paid-handoff assessment architecture with authoritative settlement evidenceSep 26salesADR-0049 Sales approval and combined Prisma admission proofSep 26salesProposed payment-based Sales handoff reporting under ADR-0049Sep 26salesADR-0049 approval and implementation request for handoff at full invoice paymentSep 29deliveryDelivery verifies paid ownership, durable preparation, exact replay and genuine lock compatibility locallySep 29deliveryDelivery separates paid handoff release configuration from rehearsal guardsSep 29platformIsolated ADR-0049 exact-event SDK recovery and source reporting proofSep 29platformADR-0049 isolated joint handoff proof and remaining release boundarySep 29platformADR-0049 source integration and staged release prerequisitesSep 29revenueRevenue implements authoritative payment assessment and verifies isolated writer overlapSep 29revenueRevenue commits coherent closure and payment assessment source integration locallySep 29salesADR-0049 actual paid-invoice handoff and Delivery preparation proofSep 29salesSales paid handoff release source, Node 20 artifact proof and reconciliation boundaryOct 2deliveryDelivery payment handoff consumer enabled with Sales admission heldOct 2deliveryDelivery bounded migrations and inactive production release verifiedOct 2deliveryDelivery lock-order correction and precursor release prerequisitesOct 2deliveryDelivery payment handoff preflight identifies configuration and schema verification gapsOct 2platformADR-0049 release source and production preflight checkpointOct 2platformADR-0049 observed-schema migration rehearsals and release stopsOct 2platformADR-0049 saved production targets and operational release boundaryOct 2platformPlatform shared ADR-0049 and ADR-0051 web release deployedOct 2revenueRevenue source comparison narrows deployment uncertainty but catalog preflight remains blockedOct 2salesFinal Sales local paid handoff integration and read-only release prerequisitesOct 2salesADR-0049 paid-invoice handoff readiness decisionOct 5deliveryDelivery verified both real paid handoff receipts and preserved first-lock factsOct 5platformBounded repair of two paid invoice handoffsOct 5revenueRevenue deploys the bounded paid invoice assessment correctionOct 5salesExact paid-invoice handoff recovery and visible assessment failures

View source on GitHub