How should an agent interface represent the stages of a correction?

A correction interface can represent business progress explicitly through states such as `draft`, `submitted`, `approved`, `posted` and `rejected`. The supplied transition rules determine which actions are valid and which roles may perform them. Approval should not be represented as equivalent to posting.

A generated record could contain `adjustment_id`, `source_entry_id`, `status`, `requested_by_role`, `approved_by_role` and `posting_reference`. Tools such as `create_adjustment`, `submit_adjustment`, `approve_adjustment` and `post_adjustment` can return both the resulting state and the actions currently permitted.

This structure matters because natural language often compresses several stages into phrases such as “fix the charge”. An agent must translate that request into the stages it can complete, then accurately report where the work stopped. A valid draft is progress, but it does not change the ledger.

MirrorFirm could supply a simulated interface with transition guards and generated records for training. Evaluation hooks can capture attempted transitions, rejected actions and final state. Developers can inspect whether the agent respects the process even when a tool makes an invalid transition technically callable, and whether its completion message matches the actual business state.