How should an environment represent the stages of a correction?

Represent a correction as linked objects rather than a single editable row. An adjustment request can contain `request_id`, `target_record_id`, `reason_code` and `requested_change`. A decision object can hold `decision_id`, `request_id`, `decision_status` and `authorising_role`. A posting object can reference the approved decision and the resulting ledger entries.

Expose separate actions such as `submit_request`, `record_decision` and `post_adjustment`. Each action should return the resulting state and a stable event identifier. This makes a proposed change distinguishable from an authorised change and an executed change.

For evaluation, capture the state before and after every action. Useful hooks include request acceptance, decision validation and posting completion. A task can finish with an approved request awaiting execution without pretending that the ledger has already changed.

Reset should restore all three object groups together, including their event histories. Restoring only the ledger could leave an approval from a previous run attached to a fresh request. A generated environment can use this structure to test stage awareness without requiring access to a production accounting system.