FEAT-OBL-003: Satisfy Obligation

Reference Number	Version	Effective Date	Supersedes	Authority Level
FEAT-OBL-003	1.2	2026-10-10	1.1	Normative

---

I. Purpose

This FEAT records lawful satisfaction of an assessed obligation.

The satisfaction may occur through:

• payment, with a Ledger transaction reference; or
• rent waiver, with no Ledger movement.

This FEAT does not create the liability. It closes or partially closes an existing liability through canonical obligation history.

---

II. Authority

Obligations owns:

• assessment_events obligation event rows for PAYMENT and WAIVED
• satisfaction legality
• rent waiver legality

Ledger owns:

• monetary movement truth for PAYMENT

Class Configuration owns:

• source terms that make the satisfaction lawful

---

III. Required Context

Required canonical context:

• class_id
• seat_id
• assessment_id
• correlation_id
• method = PAYMENT or WAIVED
• actor_seat_id
• idempotency_key

For PAYMENT, the caller SHALL also provide the lawful ledger_transaction_id.

Optional context:

• notes — free-text metadata to persist on the resulting event row (see DOM-OBL-001 §VII.1 notes column contract). NULL and empty string are equivalent. Not used by any legality check; informational only.

---

IV. Orchestration Logic

1. Verification

1. Verify the assessment exists.
2. Verify the supplied correlation_id matches the assessment lineage.
3. Verify the requested satisfaction method is lawful for the assessment type.
4. For PAYMENT, verify the Ledger transaction is lawful and belongs to the same class/seat boundary.
5. For WAIVED, verify the assessment is rent and the caller has waiver authority.

1.a Shared Payment Funding

For a payment amount lawfully selected by Obligations, the originating FEAT composes the Ledger domain commands incorporated by FEAT-LED-000 §VIII/XI.5 and FEAT-LED-001. It resolves Identity seats and typed Class banking directives, acquires the canonical seat → class serialization before monetary reads, and resolves principal plus any full-shortfall protection legs through the Ledger resolution path. Enabled protection uses savings only if it covers the entire checking shortfall; otherwise savings is untouched. A payment that checking, together with any full-shortfall protection transfer, cannot cover is refused before posting (DOM-OBL-001 3.3 §II.C; SPEC-ECON-003 §4.5.1.1, owner ruling 2026-10-07): the obligation stays owed, accumulates with later assessments, and nothing posts. Insufficient savings alone does not by itself deny a payment — checking plus savings, under the protection rule above, is the full affordability test. Own-account transfers retain their separate sufficient-funds rule.

Obligations still owns the payable slice, partial-payment permission, waiver legality, satisfaction lineage and any separately authorized fee applicability. The shared funding rule creates no waiver, new liability, deferred deduction or additional fee. A lawful payment references its actual principal Ledger effect; protection transfer legs are not satisfaction. Coverage/entitlement consequences remain with their owning domain. Replay returns the original accepted satisfaction/effect identity before repricing or further debit.

2. Mutation

1. Create the immutable obligation event row with event_type = PAYMENT or event_type = WAIVED.
2. For PAYMENT, reference the Ledger transaction.
3. For WAIVED, record no Ledger movement.

3. Derived state

The FEAT SHALL NOT persist:

• paid/unpaid
• satisfied/outstanding
• past due
• remaining amount

Those states are projections over immutable assessment and satisfaction history.

4. Coordinated rent-linked entitlement effect

After the obligation satisfaction mutation is lawfully established, the coordinating FEAT MAY evaluate a configured rent-linked Store benefit. This is not part of the monetary satisfaction event and MUST use the lawful Store grant surface rather than the Store purchase path.

The coordinated grant MUST:

• use acquisition_type = GRANT;
• preserve the satisfaction correlation lineage;
• evaluate the product’s source-independent holding limit;
• obtain rent-cycle timing from the Obligations temporal authority; and
• remain idempotent under replay of the same obligation action.

The following checks MUST NOT be reused for the rent-linked grant:

• direct-purchase permission;
• purchase limit;
• overdue direct-purchase policy; or
• purchase funding and price resolution.

If the holding limit prevents the grant, the FEAT MUST preserve the lawful obligation outcome and record the grant result as a separate coordinated outcome. It MUST NOT manufacture a purchase, reverse the satisfaction, or create a Store entitlement exceeding the holding limit.

---

V. Invariants

1. An assessment MAY have multiple PAYMENT events.
2. WAIVED is rent-only.
3. WAIVED SHALL NOT create a Ledger transaction.
4. Satisfaction events MUST be immutable.
5. Monetary correction after settlement belongs to Ledger, not to obligation history.

---

VI. Dependencies

• docs/DOMAIN/DOM-OBL-001_OBLIGATIONS_DOMAIN.md
• docs/FEATURE-EXECUTION/FEAT-LED-001_POST_LEDGER_TRANSACTION.md

VII. Change Notes

1.1 (2026-10-03) explicitly incorporates the universal charge-funding rule and typed FEAT orchestration. Supersedes code-only checking affordability rejection for an otherwise authorized payment; partial-payment, waiver, coverage and fee authority remain unchanged.