An automation can finish without completing the business outcome it was meant to produce. A job may report success after sending a request while the destination rejects it, or a retry may create a duplicate. Reconciliation closes that gap by comparing what the workflow intended to do with what actually happened.
Define the record of intent
For meaningful actions, keep a durable record of what should happen: the item, destination, action type, expected state, time, and a correlation identifier. The record should be detailed enough to compare later without storing unnecessary sensitive data.
Verify the resulting state
Do not treat a successful API call or completed job as proof of the final business result. Where practical, verify the destination state independently. Confirm that the expected record exists, the status is correct, and the action occurred once rather than zero or multiple times.
Design for partial completion
Multi-step workflows can stop between steps. Track completion at a level that lets operators distinguish work that never started, work that partially completed, and work that finished but could not be verified. This makes recovery safer than replaying an entire batch blindly.
Make discrepancies actionable
Reconciliation should produce a small set of understandable exceptions. Assign an owner, preserve relevant identifiers and timestamps, and define whether the safe response is retry, correction, review, or no action. Avoid automatic retries when repeating an action could create financial, legal, safety, access, or customer-impacting consequences.
Related knowledge
Use this with Automation Confidence Checks, Automation Data Contracts, Automation Exception Ownership, and Automation Manual Overrides.
References
This is general operational guidance. Regulated, safety-critical, financial, legal, clinical, employment, or other professionally governed decisions require context-specific controls and qualified review.