Practical workflow notes

The exception belongs in the workflow

A normal example shows how a task is intended to work. The exception shows where someone must make a decision.

Suppose two exports disagree about the amount for one record. Choosing the newest file may look reasonable, but that rule could be wrong if the later export is incomplete. Preserve both sources and identify who can resolve the conflict. The output should explain that a value is unresolved rather than replace it with a plausible guess.

Missing and duplicate records need their own treatment. A missing input might stop the whole task, allow a partial report with a clear limitation, or wait for a reviewer. A duplicate might be an accidental repeat or a legitimate separate event. Agree on the evidence needed to distinguish them before a tool takes action.

Describe the human decision in operational terms. Who reviews the exception? What information do they see? Which actions are allowed before approval? What happens if the reviewer is unavailable? A label that says “human in the loop” does not answer those questions.

Keep retries visible too. If an action may already have succeeded, check its result before repeating it. This matters whenever a workflow could send a message, create a record or submit something externally. An assessment should document that boundary; it does not authorize the action.

Use the exception examples as acceptance cases for any later pilot. The goal is an expected response that can be checked, including a deliberate stop when evidence is insufficient.

Tempero examines these boundaries as part of a focused workflow assessment. A clearer process or an existing tool may be sufficient. Practical intelligence for smarter work.