Prepare the change. Check it. Approve it. Then verify what actually changed. Here is a payroll example with a clear approval boundary. It is illustrative design guidance, not a ready-to-run payroll integration.
Preview the change. Don’t write first.
In one practitioner discussion, someone wanted to update benefit deductions, and a reply suggested preparing a preview of the changes for payroll to approve. That was a proposal, not a verified result, but it draws the right line. Extracting proposed changes and applying them are separate steps with different controls.
Make the proposal inspectable.
Every value below is fictional, and no calculation or entitlement is implied. It is not a payroll instruction.
- Change request
- DEMO-007
- Employee ID
- DEMO-014
- Current deduction
- CA$40.00 per pay period
- Proposed deduction
- CA$45.00 per pay period
- Effective
- Beginning February 1, 2027
- Supporting source
- Fictional approved schedule
- Status
- Awaiting authorized review
1. Use explicit rules. Don’t guess the gaps.
Match the record using the authorized employee identifier. Don’t resolve duplicate names by guessing.
Check the basis. Payroll verifies the source, amount, pay period and effective date against approved rules.
Stop on uncertainty. Flag missing dates, conflicting instructions or a rate that can’t be verified.
Practical check: Use validated calculation rules, not generated arithmetic.
2. Approve this change, not unlimited access.
Review the exact batch. Show every proposed change, and its source, to the authorized payroll approver.
Recheck before writing. If a record or a proposal changed after approval, stop and get the new review it needs.
Enforce the boundary. Apply only the approved changes, through the authorized connection to the system.
Practical check: An instruction to “ask first” is not an enforced permission.
3. Use dummy records. Try the awkward cases.
- Same name
- Two records with different employee IDs.
- Missing date
- No effective date supplied.
- Period change
- A change falls within a pay period.
- Repeated request
- The same instruction arrives twice.
Practical check: Payroll defines the expected outcome for each test.
4. Approved is not the same as applied.
Confirm the result. Compare the actual record in the system with the approved change.
Record each outcome. Track approvals, completed writes, failures and items still waiting for attention.
Handle partial failure. Don’t blindly retry the whole batch. Use the agreed retry and correction process.
Practical check: Keep a traceable request ID, and prevent duplicate writes.
Prepare and validate. Approve, apply, verify.
Start in a test environment. Involve payroll and the system owner, and keep real records out until the design is approved. This is a pattern to review with your team, not a compliance checklist or a payroll rule.
Read more: How to Scope a First AI Agent