Error, exception, and override reporting

One red number called “exceptions” hides the work. Separate the categories before you trend them.

Four reportable signals

Signal	Meaning	Owner
Error	Technical or validation failure	Operator
Timeout	Work exceeded a clock	Workflow owner
Exception	A permitted policy escape	Decision owner
Override	Human changed the result	Decision owner and approver

Store a reason code, record, version, actor, timestamp, and next action for each.

Read the pattern

Many provider-timeout errors point to retry or capacity work. Many rules-gap overrides point to a missing outcome. Many bad-evidence overrides point to source authority or data quality. Many valid-exception overrides may mean the policy is working as designed.

Do not optimize for a lower override count without checking the final outcome. A forced recommendation can reduce overrides while making the system less useful.

Queue metrics

Track count, age, owner, time to resolution, reason code, and final disposition. Report open and resolved items separately. Include a sample of the underlying records in the operating review.

Related controls

The decision result schema keeps outcome, evidence, and state separate. Workflow states and job history keeps retries and failures traceable. Connect them by a stable run or decision ID.

Keep the populations separate

An error means the system could not complete as designed. An exception means a known case took a permitted alternate path. An override means an authorized person changed a recommendation or result. Incomplete work is still waiting, expired, or abandoned. Combining them into “issues” hides whether the fix belongs in technology, policy, training, capacity, or data.

Give every item a reason code, owner, opened time, due time, resolution, and link to the underlying run. Record the policy and workflow versions active when it happened. Keep free text for context, but do not use it instead of categories that can be trended.

Turn reporting into correction

Review rates as well as counts and compare them by workflow version, segment, owner, and step. Sample both common and high-consequence cases. Repeated overrides may reveal a weak rule; concentrated errors may reveal one integration; old incomplete items may reveal unclear ownership. Assign a correction, success measure, and review date. Closing the queue without changing the source pattern is not improvement.

Related: Human approval and preview patterns, Decision ownership and override authority, and GTM operating review template.