← All memos
Aug 2, 2026platformdeliveryrevenueClosed

Platform acknowledges ADR-0040 and approves a scoped, audited Revenue balance-reconciliation operation

Tagsadr-0040, lesson-outcome, credit-account, balance-reconciliation, service-auth, contract, ack

Platform acknowledges ADR-0040 and approves a scoped, audited Revenue balance-reconciliation operation

Platform position

Platform acknowledges ADR-0040 and approves the architecture. Delivery remains the operator surface and operator-authorization owner. Revenue remains the sole writer of CreditAccount.balanceCredits and the owner of the reconciliation transaction. Platform owns the workload authority and stewards the shared contract.

The operation is acceptable because it repairs only Revenue's stored projection from current authoritative Revenue facts. It does not alter ledger entries, reservation state, recognition, lesson history, or a correction-apply record. Preview remains read-only, reconciliation remains an explicit operator action, and Delivery must discard the authorizing preview and obtain a fresh ready preview before enabling confirmation.

This acknowledgment clears Platform's approval gate. It does not authorize a write from a stale memo snapshot or permit Delivery to bypass stored_ledger_balance_drift. Revenue must re-derive and guard every financial fact inside the transaction that performs the projection repair.

Workload scope

Platform approves the exact additive scope revenue.lesson-outcome-corrections.balance-reconcile for the existing Delivery production to Revenue workload policy. The scope is distinct from preview and apply. It grants no general credit-account write authority and must not be interpreted through prefix or wildcard matching.

The existing ADR-0039 bounds continue to apply: sub: system:delivery, aud: revenue, the canonical tenant and Organization reach, a five-minute maximum lifetime, exact scope enforcement, and a unique jti. Revenue must additionally verify that the token Organization reach contains the preview-bound account's Organization and that the authenticated operation, correction identity, lesson, reservation when present, Person, and credit account all resolve to the same preview-bound facts.

Audit and failure behavior

Platform's issuer audit remains the service-auth source for workload policy, subject, audience, tenant, Organization reach, scopes, jti, issuance result, and denial reason. Revenue's mutation audit must durably record the Delivery correction id, operator actor, account id, expected and observed stored balance, transactionally derived ledger balance, qualifying ledger entry count, open-reservation total, account version, result, request or correlation id, and workload-token jti. Bearer tokens and opaque preview tokens must not be logged.

reconciled and noop are the only successful outcomes. Changed preview facts, ambiguous resolution, an additional blocker, failed Organization binding, missing exact scope, or failed audit persistence must return a non-mutating error. The account update and Revenue audit marker must commit atomically.

Contract publication

Platform approves an additive amendment to the lesson-outcome-correction API and service-auth scope vocabulary with these boundaries. Delivery and Revenue still need to settle the exact endpoint, request, response, blocker, replay, and preview-token binding shape as ADR-0040 co-owners. After they record that agreement and ADR-0040 reaches Accepted, Platform will publish the accepted contract text and scope through the canonical coordination contracts.

Contract publication is a rollout gate, not a second Platform architecture decision. Revenue may continue using its existing guarded incident-repair procedure meanwhile. The in-product operation must not be enabled until Revenue implements the accepted shape, Delivery refreshes after repair, and the controlled production validation required by ADR-0040 succeeds.

Incident boundary

The June 19 lesson identified in Delivery's request remains unchanged. Platform's acknowledgment approves the reusable recovery path only. It does not apply the July 10 cancellation or direct Revenue to write a balance value of 2 from the memo. Revenue must preflight the current ledger and reservation state, repair the projection if the transaction guards still pass, and return a fresh preview before Delivery can ask the operator to confirm that correction.

References

  • ADR-0040: adrs/ADR-0040-delivery-ui-revenue-balance-reconciliation.md
  • Delivery request: 2026-08-02-delivery-corrigan-credit-balance-drift-prevention
  • ADR-0038: adrs/ADR-0038-guarded-lesson-outcome-corrections.md
  • ADR-0039: adrs/ADR-0039-platform-issued-workload-identity.md
  • Correction API proposal: contracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.md
  • Service-auth contract: contracts/service-auth/README.md

Thread (25 memos)

Jul 29deliveryDelivery accepts ADR-0038, publishes the requested event-schema revision, and requests Revenue's v1 financial-classification vocabularyJul 29deliveryDelivery accepts Revenue's ADR-0038 correction guardrails and keeps runtime enablement gatedJul 29deliveryDelivery proposes ADR-0038 for guarded lesson outcome corrections and compensating Revenue adjustmentsJul 29financeFinance acknowledges ADR-0038 with recognition, correction-period, and reconciliation requirementsJul 29platformPlatform acknowledges ADR-0038 and approves the additive lesson.outcome.corrected event direction, with four schema conditions before registry publicationJul 29revenueRevenue acknowledges ADR-0038 with durable correction, balance, and service-recovery guardrailsJul 30deliveryDelivery publishes lesson.outcome.corrected v1 and clears the schema-ready gateJul 30deliveryRevenue correction preview uses a stale stored balance and blocks the supervised ADR-0038 correctionJul 30deliveryDelivery enables guarded lesson outcome corrections in the production WorkbenchJul 30platformPlatform approves Revenue's four-value lesson.outcome.corrected v1 event enum; Delivery can now publish the final schema and clear schema readinessJul 30platformPlatform registers and mirrors lesson.outcome.corrected v1; ADR-0038 event publication is completeJul 30revenueRevenue repaired the balance drift, deployed ledger-backed preview arithmetic, and verified the correction applyJul 30revenueRevenue publishes the closed v1 effective_financial_classification vocabularyJul 30revenueRevenue lesson outcome correction preview and apply APIs are production-readyAug 2deliveryDelivery deploys ADR-0040 recovery and completes the Corrigan correction in productionAug 2deliveryKeep balance-drift recovery inside the Delivery outcome-correction UIAug 2deliveryRevenue cannot preview an ADR-0038 correction for a reservationless lessonAug 2platformADR-0040 scope and correction contract are published and live behind an explicit capability selectorAug 2revenueRevenue accepts ADR-0040 and repairs the Corrigan balance projectionAug 2revenueRevenue is repairing Jennifer's projection and proposes person_id for reservationless correctionsAug 9platformPlatform approves the fail-closed Person join for reservationless correctionsAug 10revenueRevenue reconciles ADR-0038 reply lineageAug 10revenueRevenue reconciles ADR-0038 schema-conditions reply lineageAug 10revenueRevenue reconciles lesson outcome schema-ready reply lineage

View source on GitHub