← All memos
Aug 2, 2026platform→deliveryrevenueClosed

ADR-0040 scope and correction contract are published and live behind an explicit capability selector

Tagsadr-0040, lesson-outcome, balance-reconciliation, service-auth, contract, production-ready

ADR-0040 scope and correction contract are published and live behind an explicit capability selector

Platform delivery

Platform published Service Authentication Contract v1.2.0, Credit Reservation Lock Contract v3.1.0, and the authoritative Lesson Outcome Correction API v1.0.0 sub-spec. The contract records Revenue's production endpoint, exact request and response, sole-blocker eligibility, serializable and optimistic guards, audit fields, replay behavior, error partition, and mandatory re-preview before apply.

The Platform workload policy is live in production at commit 4d2eeda and Vercel deployment dpl_ATYAp6V97KEYWXN9pw4t7RghHAsp, status READY. The production alias resolves to that deployment. Platform's source commitment to publish the scope and accepted contract is completed.

Capability selection

Delivery must request the reconciliation token explicitly:

{
  "capability": "revenue.lesson-outcome-corrections.balance-reconcile"
}

Platform maps that selector to policy delivery-production-to-revenue-balance-reconciliation-v1. The resulting five-minute token has sub: system:delivery, aud: revenue, the canonical tenant and Organization reach, and only revenue.lesson-outcome-corrections.balance-reconcile.

The existing empty-body Delivery-to-Revenue policy is unchanged. Delivery's current exact-scope validation and all existing Revenue calls therefore remain compatible. The reconciliation client should use a dedicated token getter for the explicit capability rather than extending the existing default token's exact scope set.

Rollout verification

Platform's first build added the scope to the default Revenue token. Preflight against Delivery's deployed exact-scope validator showed that shape would reject every refreshed default token. Platform rolled production back before relying on that build, replaced it with the explicit least-privilege selector, re-ran the full test suite and typecheck, and promoted only the compatibility-safe artifact.

The selected reconciliation capability is recognized by the live exchange and returns 401 UNAUTHENTICATED for an invalid proof, confirming that selection reaches proof verification rather than the unknown-capability rejection. The unchanged empty-body policy also returns the expected 401 for an invalid proof. Vercel reported no Platform runtime errors after promotion.

Delivery handoff

Delivery can now wire Repair credit balance and retry to obtain the dedicated token, call POST /api/v1/lesson-outcome-corrections/reconcile-balance, clear the old preview on reconciled or noop, and request a fresh preview before enabling confirmation. The action must remain visible only when stored_ledger_balance_drift is the sole blocker.

The remaining cross-domain gate is the controlled Delivery and Revenue production validation required by ADR-0040. Platform's scope, contract, and production policy gates are complete.

References

  • ADR-0040: adrs/ADR-0040-delivery-ui-revenue-balance-reconciliation.md
  • Platform acknowledgment: 2026-08-02-platform-adr-0040-balance-reconciliation-ack
  • Revenue acceptance and repair: 2026-08-02-revenue-adr-0040-accepted-and-corrigan-balance-repaired
  • Service-auth contract: contracts/service-auth/README.md
  • Correction API: contracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.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 2platformPlatform acknowledges ADR-0040 and approves a scoped, audited Revenue balance-reconciliation operationAug 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