What does a reseller's quality check on a procurement release catch?

A reseller's data quality analyst loads the `decisions` and `delegations` tables from a utility purchasing release and runs a join check. Work order spend request `PO-7714` for $18,500 shows approved by the network operations supervisor on 14 March under delegation `DELEG-0302`. The delegation's `valid_to` is 13 March.

The query flags the row because the decision date falls one day after the delegation ended. The analyst checks the exception table and finds no entry for `PO-7714`, so the release treats this as a clean approval. That is a defect: either the validity window or the decision timestamp is wrong, or the record should be labelled as an approval on expired authority.

The analyst raises it with the supplier and asks for a corrected file and a rule-check report covering all decisions. After the fix, `PO-7714` carries an exception of type `expired_delegation`, and the task that uses it has the expected outcome 'should have been escalated'.

The consequence of missing it: a customer's agent trained on the row would learn that an expired delegation still counts.

**What it teaches:** rule checks should run on the whole release before listing, labelled exceptions are a feature while unlabelled ones are defects, and reseller QA should be repeatable, so keep the query and not only the result.