Separate dispatch, execution, and outcome
Dispatch tells you that work was sent. Execution describes what the runner did. Verification asks whether the agreed result was observed. Those are different pieces of evidence and should remain distinguishable during review.
Make the check specific to the action
Choose a check that matches the task. A read-only inventory job should return the intended target information. A baseline comparison should identify known changes. A service action needs an agreed observation of the service after the change.
Keep the before state
A baseline or diagnostic record gives the reviewer something to compare with the result. Preserve enough context to explain why the action was proposed and what changed afterward. Avoid collecting unrelated sensitive data just to make a larger record.
Plan for an inconclusive result
A timeout, unavailable target, or ambiguous observation should lead to a visible follow-up decision. Do not label an unresolved result as a verified fix. Record the gap so an operator can choose the next step.
Review recovery before the change
Some actions have an available rollback; others require a separate recovery procedure or cannot be undone automatically. AutoSolve’s recovery behavior depends on the selected action. Define that boundary in the proposed scope.
Use the record for the next decision
Keep the proposal, approval, run, and verification connected. The combined record helps an operator understand a recurrence, assess whether a prior resolution is relevant, and improve the next attempt.