Finance withholds ADR-0056 release acceptance pending paid-credit forfeiture recognition

Finance classifies the missing CREDIT_FORFEIT recognition path as an implementation gap under accepted policy, not a new policy or cross-domain design decision. Credit Reservation Lock section 9.7 already assigns Revenue recognition of forfeited credits under policy. Finance ADR 003 already requires sold-credit forfeiture recognition and suppresses recognition for service-recovery and other non-cash-backed credits. No Finance code, mart schema, contract version, or new ADR is required to resolve this gap.

Revenue's isolated proof for Delivery candidate 6d109b490a3d02aa97c08102121b3ef0f5cb9bc4 preserved the correct six-credit ledger footprint, but produced zero recognition and zero attribution rows. The actual recognizer rejected the CREDIT_FORFEIT source with Entry Type must be "Lesson Debit", and the reconciliation sweep selects only LESSON_DEBIT. That charge path is not financially acceptable yet. The separate do_not_charge path correctly produced a customer_requested_exception release with no recognition or attribution.

Required funded-source attribution

Revenue must recognize only the sold, cash-backed portion of the exact forfeited quantity. The recognition must:

• use the CREDIT_FORFEIT ledger entry as the immutable recognition source, preserving its lesson and credit-reservation links;
• attribute each recognized slice through the originating PURCHASE_CREDIT entry and Order Item, using the same source-backed amount controls and Order Item caps that govern paid-credit consumption;
• derive cents from the original Order Item consideration and retained per-credit value snapshot, including the existing closing-slice residual rule, without exceeding the original consideration;
• apply Revenue's authoritative credit-class ordering for mixed balances, with no recognition row, gross-up, or contra row for any service_recovery or other non-cash-backed slice; and
• fail closed with an explicit reconciliation exception when sold-credit provenance or amount basis is missing or contradictory. It must not synthesize a source, relabel the forfeiture as LESSON_DEBIT, or silently recognize an estimated amount.

Recognition timing

Recognition belongs to the forfeiture disposition. recognized_at and the reporting period must derive from the authoritative CREDIT_FORFEIT.occurred_at, aligned with the terminal forfeited_at, not from lesson completion, the Delivery decision journal, the later recognition job, or a reconciliation rerun. A retry or backfill may create the row later, but must retain the original forfeiture period and source identity.

Acceptance criteria

Finance will accept this recognition slice only when source-pinned isolated evidence demonstrates all of the following:

1. A six-credit sold-credit late-cancel creates one CREDIT_FORFEIT source and exactly one non-contra recognition effect, with attribution slices tied to the originating PURCHASE_CREDIT and Order Item.
2. Attributed sold-credit quantity equals the recognizable forfeited sold-credit quantity, and recognized cents equal the source-backed Order Item allocation at zero-cent variance. Recognition plus prior recognition and refunds never exceeds the original Order Item consideration.
3. A mixed sold and service-recovery fixture attributes the full forfeited quantity by credit class, recognizes only the sold slice, posts nothing for the service-recovery slice, and remains reconstructible from silver facts.
4. A customer_requested_exception release creates no forfeiture recognition or attribution and leaves returned paid credits deferred for a later authoritative disposition.
5. Same-source retry and reconciliation sweep are idempotent. They create no second recognition or attribution effect, and a sweep can recover a missing recognition without changing the original recognition period.
6. Missing, duplicate, over-allocated, or contradictory provenance fails closed as a visible exception. No historical ledger, release, token, recognition, or attribution fact is rewritten.
7. Finance-mart recognized_revenue ties through source_credit_ledger_entry_id to the exact CREDIT_FORFEIT, and the recognition, attribution, credit-ledger, and unearned-credit-liability views reconcile at zero cents.

The isolated proof also reports duplicate terminal effects under concurrent Revenue handlers. Revenue owns that separate settlement blocker. Passing the recognition criteria does not clear concurrency, composed timeout and recovery, exact deployment, migration, historical inventory, or activation gates.

Finance records no new implementation commitment. Revenue owns the recognition and reconciliation implementation, and Finance remains the silver-data reporting consumer. This disposition authorizes no production SQL, DDL, financial repair, historical repricing, deployment, or activation.

Evidence reviewed

• Revenue proof source head fecab1cc63c5ef46aad551b3bb4a438ff3606a21
• Revenue proof manifest SHA-256 52b91920dc6bd67b52860ed8ccaedb7f94cdf406dd96936d4bbcd6c97df03e24
• Revenue proof results SHA-256 e55e35ee774a1c892a0707fb99160a9f312c72ffce1d56bcf8b1f9f1dbfb37b9
• Delivery candidate 6d109b490a3d02aa97c08102121b3ef0f5cb9bc4
• contracts/credit-reservation-lock/README.md, section 9.7
• adrs/finance/003-non-cash-backed-credit-recognition-policy.md
• contracts/finance-mart/revenue-recognition-rollup.md
• contracts/finance-mart/reconciliation.md