Approval discipline is the single most-undervalued operator skill in a deployed operations layer. The system can be built correctly and still produce bad outcomes if the operator's approval habits are loose. Five rules and four warning signs.
The five rules
Rule 1: every approval carries a reason
The reason can be terse ("routine," "within band," "vendor preferred") or specific ("V-218 already on this lot, consolidating for inspection efficiency"). The point is not the length. The point is that the approval is a recorded judgment, not a button press. The audit log is materially better when every row carries a reason. The operator's own future self thanks them in three months.
Rule 2: bulk approve only when the bulk is structurally similar
Bulk approve is fine when you are approving twenty rows that all share the same parent attribute (same vendor, same item family, same time window) and the system is reporting all twenty as within tolerance. Bulk approve is not fine when you are approving twenty mixed rows because you are running out of time before a meeting. The structural similarity is what makes the approval defensible.
Rule 3: read the system's confidence score before approving
The confidence score is the system telling you what it knows about how sure it is. A confidence score of 0.95 means the system extracted the data cleanly and you can verify in two seconds. A confidence score of 0.65 means there is something the system is uncertain about and you should spend ten seconds with it before approving. Treating both rows the same is leaving signal on the table.
Rule 4: override with a reason, never with silence
When you override the system, leave the reason. "V-218 has been late three times this quarter on the 1.5mm gauge specifically." The override reason is the signal that feeds back into the system's scoring. Without the reason, the override looks like noise. With the reason, six months of overrides become a queryable corpus that improves the next vendor evaluation.
Rule 5: end your shift with a clean queue or a noted hand-off
The operations layer is real-time. A queue you leave full at the end of your shift is a queue someone else inherits without context. Either work the queue to zero or leave a short note on the items you escalated, deferred, or are watching. The note is two sentences. The hand-off is clean. The next operator does not have to reconstruct your decisions.
The four warning signs
A proposal that triggers any one of the following four patterns is masking something the system should have caught earlier. The right move is to flag it for review, not to approve it.
Sign 1: the proposal sits at the maximum tolerance band
A price band of +/- 5% and a proposal that lands at +4.8% is a proposal that is mathematically inside the band and operationally hugging the edge. Either the band is too loose or the proposal is being squeezed by something the band does not capture. Flag it.
Sign 2: the proposal cites a source artifact that you do not recognise
The provenance click-through opens a PDF from a vendor you do not work with regularly, or an email from a domain you do not recognise. The system extracted data from somewhere and presented it as if it were routine. Flag it before approving.
Sign 3: the proposal contradicts the last similar proposal
The system proposed $52.93 yesterday for the same SKU from the same vendor and is proposing $54.40 today. Both are inside the tolerance band. The discrepancy might be real (vendor price moved) or it might be a parser glitch (different column read). The two-second check is to open both source PDFs and verify. The flag is appropriate if you cannot reconcile them.
Sign 4: the proposal needs an explanation you cannot find
You read the proposal, click through to the source, and you still cannot tell why the system proposed what it did. The reasoning chain is opaque. This is the failure mode the provenance surface was meant to prevent. When it happens, do not approve. The system has produced an output you cannot defend, and approving it makes you the defender.
When the rules are wrong
The five rules above are defaults. They are wrong sometimes and you should know when. The bulk-approve rule is wrong when the bulk is large enough that even structurally similar items deserve individual eyes (a hundred-row batch is too large regardless of similarity). The confidence-score rule is wrong when the system's confidence is wildly miscalibrated and you have learned that 0.85 on this workflow actually means 0.65. The override-with-reason rule is wrong when the reason is so obvious to anyone reading the record that writing it down is friction without information. Use judgment on when to relax the defaults. Document the relaxation in the operator handbook so the next operator knows the local convention.