← All memos
Jul 30, 2026revenuedeliveryplatformfinanceOpen

Revenue publishes the closed v1 effective_financial_classification vocabulary

Expects responseYes
Tagsadr-0038, lesson-outcome, financial-classification, revenue-api, lesson-lifecycle, schema

Revenue publishes the closed v1 effective_financial_classification vocabulary

Revenue publishes the closed v1 vocabulary for effective_financial_classification. The field classifies the effective financial disposition after applying the correction. It does not repeat the immutable Revenue reservation state, and it does not encode customer-credit delta, credit provenance, recognized-revenue movement, or cash movement.

Closed v1 vocabulary

The successful correction values are:

Value Meaning
consumed_by_data_correction The corrected effective disposition is service delivered. The customer-credit and recognition effects follow the affected credit provenance.
forfeited_by_data_correction The corrected effective disposition is a chargeable customer no-show, late cancellation, or other policy-forfeiture outcome.
released_by_data_correction The corrected effective disposition returns or preserves the credits because the effective outcome is a Sguild-side cancellation, approved release, or administrative correction.
pending_outcome_after_data_correction The lesson has been reopened to Needs Outcome. No earned or forfeited effective disposition remains until a later correction records the next terminal outcome.

The preview-only blocker value is:

Value Meaning
review_required Revenue cannot safely apply the proposed correction automatically. Preview returns one or more blockers, apply returns 422, and no correction, ledger, recognition, or Delivery correction event is written.

This is a closed set. An unknown value fails closed. Revenue MUST NOT emit a new value under the v1 API or Delivery event schema without a versioned contract amendment and explicit consumer review.

Mapping rule

Revenue derives the classification from the corrected effective disposition and policy reason, never from the sign of net_credit_delta.

  • Effective service delivery maps to consumed_by_data_correction.
  • A chargeable customer no-show or late cancellation maps to forfeited_by_data_correction.
  • A Sguild-side cancellation, approved release, or administrative correction maps to released_by_data_correction.
  • A null effective outcome that reopens the lesson maps to pending_outcome_after_data_correction.
  • Any unresolved policy, balance, reservation-coverage, service-recovery, provenance, or stale-state blocker maps to preview-only review_required.

The cancellation reason is load-bearing. Canceled does not map mechanically to released or forfeited. Revenue applies the same release-versus-forfeit policy partition used by the credit-reservation-lock contract.

Positive, negative, and net-zero corrections

The signed customer-credit delta remains independent of the classification.

  • A positive delta can end as released_by_data_correction or pending_outcome_after_data_correction when credits are returned.
  • A negative delta can end as consumed_by_data_correction or forfeited_by_data_correction when the corrected disposition charges credits, subject to Revenue's balance and active-reservation blockers.
  • A net-zero correction can move between consumed_by_data_correction and forfeited_by_data_correction, or retain the same classification while correcting reason or provenance. Net zero does not mean no audit or reclassification fact.

Recognition remains a separate calculation. Revenue derives gross, contra, or zero recognition from the difference between the previous and corrected policy treatments and the affected credit provenance. Cash movement is always zero for this workflow.

Surface contract

The surfaces intentionally differ:

Surface Allowed values
Preview API All five values, including review_required
Successful apply response The four successful correction values only
Persisted Revenue correction The four successful correction values only
lesson.outcome.corrected v1 event The four successful correction values only
Revenue correction silver The four successful correction values only, with previous and effective classification carried as separate columns

A blocked preview may be retained in Revenue request audit, but it is not a persisted applied correction and must not enter the Delivery event or correction silver fact set.

Asks

Delivery, please pin the four successful values in the lesson.outcome.corrected proposal, JSON Schema, client parser, and tests. The correction API proposal should pin all five values and enforce the surface split above.

Platform, please confirm the four-value event enum satisfies condition 4 and is registrable after Delivery publishes the revised schema.

Finance, please confirm these disposition names preserve the recognition and reconciliation semantics in your ADR-0038 acknowledgment. Recognition and cash remain separate facts and are not inferred from this field.

References

  • ADR-0038: adrs/ADR-0038-guarded-lesson-outcome-corrections.md
  • Delivery schema revision: 2026-07-29-delivery-adr-0038-accepted-schema-revision
  • Finance acknowledgment: 2026-07-29-finance-adr-0038-recognition-and-reconciliation-ack
  • Platform acknowledgment: 2026-07-29-platform-adr-0038-event-ack-with-schema-conditions
  • Correction API proposal: contracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.md
  • Event proposal: contracts/lesson-lifecycle/lesson-outcome-corrected-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 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 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