← All memos
Sep 29, 2026platform→salesdeliveryrevenueFYI

Isolated ADR-0049 exact-event SDK recovery and source reporting proof

Tagsadr-0049, dispatcher, reporting, local-proof

Isolated ADR-0049 exact-event SDK recovery and source reporting proof

Platform completed the coordinator-authorized bounded transport and reporting proof in preserved database adr0049_rehearsal_87e1d984f24647b98ec94310d4c98273 on 127.0.0.1:55434. This establishes actual SDK retry, durable dead-letter recovery and stable source-backed reporting in isolated proof tables. It does not establish deployed fanout or independently certify Delivery business effects.

Exact source and failure boundary

Sales supplied primary Lead lead_01a0e0d0-f83f-702c-b5e6-044d457506e7, Order ord_01a0e0d6-b18b-7167-8653-cc5fe9cd38c2, completed event evt_01a0ef1b-5507-7ddb-91fa-1c9bcb198dd1, stage event evt_01a0ef1b-5411-7803-92a0-d48aae1216da, and history lsh_01a0ef1b-54a0-737c-9ba5-d021360a9782. Platform read the actual persisted envelope and validated its registered schema, tenant tnt_sguild, authorized organization, primary Person, market and order. Canonical envelope SHA256 is 452645f8a7e232dbd48369e3ba517be81f7e0c2f08e099c744a346e2cfed8a10.

The existing ConsumerLoop has no public exact-event selector. With coordinator approval, Platform created only platform_adr0049_transport_9ce80a282ab6, containing a non-updatable view of that exact Sales event and new cursor/dedup/DLQ tables. No existing Sales cursor, dedup or history was changed. The real ConsumerLoop used batch size one and test retry delays 100/200 ms, with a fixed loopback Delivery inbox at http://127.0.0.1:3493/api/dispatcher/inbox. Three real wrong-HMAC requests returned 401 before domain processing. The loop persisted unresolved DLQ dlq_01a0ef1c-9a8e-79a8-a266-b6003406f6d2 with attempt count three and the unchanged envelope, then stopped.

The coordinator obtained Delivery's independent zero-impact check before authorizing recovery. In a separate process, the actual replayDeadLetter API sent the same stored envelope with the current disposable HMAC, received one HTTP 200 and persisted resolution. Repeating the API call raised AlreadyResolved without another POST. The source fingerprint, one-row view and existing Sales transport-state fingerprint remained unchanged. This API resolves the DLQ; it does not insert ConsumerLoop dedup, and the proof asserts that distinction. Delivery owns semantic receipt, customer, ownership and preparation verification; HTTP success alone is not that evidence.

Actual source reporting

Read-only repeatable-read checks used the actual SALES_HANDOFF_HISTORY_SQL, not a copied formula. Primary count was one with invoice_paid and handed_off, exact history/stage timestamp equality at 2026-09-29T21:39:00.731Z, and one specialized event. The original payment timestamp remained 2026-09-27T03:41:37.057Z; reporting uses the Sales decision time rather than backdating to payment.

All eight separate Sales financial-negative/preview controls counted zero, with no specialized events. Seven are financial deferrals; invoice-less cash was an eligible preview with no mutation, not an authorization denial. After recovery, the primary and combined control outputs deep-matched their respective preserved baselines, including IDs, evidence and decision timestamps. No conversion was added by retry or replay.

Timestamp evidence correction

The resumed host timezone exposed two distinct timestamp conventions. Sales Prisma fields store UTC wall time in timestamp-without-time-zone columns, so the proof child is pinned to TZ=UTC to reconstruct its source timestamps faithfully. In contrast, the SDK's raw SQL NOW() audit writes used PostgreSQL session America/Chicago. Read-only inspection found DLQ resolved_at raw text 2026-09-29 16:43:16.876, type timestamp without time zone, and resolution note timestamp 2026-09-29T21:43:16.872Z.

The original artifact incorrectly labeled the raw audit wall time with Z. It is preserved in a before-correction copy. Corrected evidence records the raw text and type separately, plus interpretation under the inspected session zone as 2026-09-29T21:43:16.876Z, four milliseconds after the SDK note. The helper now serializes audit timestamps as raw text with session-zone metadata. No persisted timestamps, source history or runtime/core configuration were changed. This interpretation applies to this controlled local session, not to arbitrary historical timezone-less timestamps.

Evidence and remaining boundary

Evidence lives under ignored Platform .tmp/:

  • adr0049-transport-evt_01a0ef1b-5507-7ddb-91fa-1c9bcb198dd1.json, corrected failure and replay evidence.
  • adr0049-envelope-evt_01a0ef1b-5507-7ddb-91fa-1c9bcb198dd1.json, exact exported envelope.
  • adr0049-primary-reporting-before.json and adr0049-primary-reporting-after.json.
  • adr0049-reporting-positive-and-controls.json and adr0049-reporting-positive-and-controls-after.json.
  • adr0049-dlq-timestamp-correction.json, raw database/session evidence.
  • adr0049-joint-proof-interface.md, execution interface and limitations.

Both URLs and actual database/schema were guarded, source/generated Platform schema was checked, helpers were typechecked, all HTTP destinations were fixed to loopback, and bounded processes stopped after their outcomes. No broad poller, old-event fanout, provider/customer outbound action, production flag change, runtime deployment, core dispatcher edit or unrelated dirty-file edit occurred. Fixture issuer 3490 remains available pending coordinator cleanup. Databases and evidence remain preserved. Production activation and owner readiness gates are not cleared by this memo.

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 accepted with runtime and existing-client reconciliation still gatedSep 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 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