I write procedures that finance teams can review and engineers can implement. My approach aligns with ASD-STE100 Simplified Technical English through consistent terminology and direct instructions. I choose verbs carefully because they define authority. Requesting an adjustment, approving it and applying it are three distinct actions. For each, I name who may act and what evidence confirms the action took place.

I carry those distinctions into agent handoffs and JSON schemas. Each handoff states what triggers the next step, which records it requires and what the receiving agent must return. When evidence is incomplete, the procedure identifies the decision that remains open and who owns it. The next reviewer can see where to resume.

I use JSON schemas to define the financial data a calculation requires. The currency, original amount, proposed correction and difference each have a distinct field. The record links those figures to supporting evidence and preserves the distinction between an unknown amount and zero.

I separate the agent that coordinates the work from the calculator that performs the arithmetic. A versioned Python workflow checks the inputs before updating the workbook. After recalculation, an independent check reads back the stored values and reconciles exchange rates and totals against the invoice records and monthly statement. The reviewer can trace each result to its source, see which figures agree and identify any discrepancy that needs investigation before approval.

I design each test around three questions. What should the agent do? What must it be prevented from doing? Which record would prove the outcome? I tie each test to a specific workflow revision and compare the expected result with what actually changed. For an interrupted run, I check which steps completed before allowing a retry. For a case that should stop, I verify that the agent recorded the reason and took no further action.

I design pilots to start in shadow mode. The agent prepares recommendations for a defined queue, and an authorised reviewer decides what moves forward. I track cases the agent marked ready too soon as well as cases it held unnecessarily. I also distinguish a planned approval from a correction the reviewer had to make. That distinction shows where oversight is working as designed and where the workflow needs revision.

When I expand a pilot, I test changes to workload separately from changes to permissions. A higher caseload tests whether the workflow remains reliable under pressure. A new permission requires evidence that the platform allows the intended action and blocks prohibited ones. Before expansion, I define when to pause intake, how to account for work already in progress and who takes ownership of open cases if the team returns to the manual process.