Exception analysis

A control test produces deviations. Not every deviation is a finding. Some are evidence gaps the system did the right thing, the file did not record it. Some are anomalies a one-off mistake with positive evidence it does not recur. Some are design gaps the form, the workflow, the rule did not require what the criterion expects. Some are operating failures the design was sound, the operation missed. Some are data-integrity issues the system of record disagrees with the source feed. Some are scope disagreements the tester and the control owner read the criterion differently.

This skill takes the raw deviation list out of fieldwork, classifies each one, ranks severity with rationale, names a root-cause hypothesis, sets a disposition, and builds the handoff package the downstream issue write-up consumes. It drafts the exception register against templates/default-output.md and emits a structured record conforming to schemas/exception.schema.json. The workpaper drafter consumes that record by ID; the issue write-up consumes the per-exception handoff package via source_exception_id. The skill stops at preparer sign-off; the named reviewer signs separately and severity always carries human review.

Ask first

Before classifying, get plain answers. Most cycles answer them in the test plan and the raw deviation notes; if not, default and flag.

• Whose register is this for. The testing manager closing the cycle, the QA reviewer challenging exception treatment, the issue-writeup author opening tracked findings, the internal audit lead deciding reliance, the examiner who reads the file later. Audience drives how heavily the rationale fields read and which dispositions get the most attention.
• Has fieldwork actually finished. All sample items inspected, all procedures executed, walkthrough complete. A register built on partial fieldwork mis-projects deviation rate and mis-ranks severity. If fieldwork is open, route back to workpaper-drafter and stop.
• What is the criterion the test was measured against. Pull it from the test plan and the workpaper's source criteria block. Classification turns on whether the condition deviates from the criterion or from the tester's reading of it; without the criterion in hand, scope-disagreement classifications cannot be defended.
• Is there a prior cycle with similar deviations. A repeat-issue flag changes severity calibration and the issue-writeup handoff. Check the issue log for the same control or population before classifying; do not let "looks new" pass when the prior issue is still open.
• What does the firm's tolerable deviation rate say. Pulled from the test plan. Aggregation reads against tolerable, not against the preparer's intuition. If the rate is unset, that is a test-plan defect to flag back, not a number to invent here.

When scope (per risk-compliance-core/scoping) is supplied, consume it: institution.type and institution.primary_regulators set the supervisory framing for severity rationale and dispositional language, sector_overlay_set selects which references/sector-overlays/<sector>.md loads, cross_cutting_overlay_set selects the references/cross-cutting/<topic>.md files, persona.role sets which decision forum the register passes through, source_posture constrains what the body can carry. When it is not supplied, draft against what the test plan and workpaper carry, default to the testing program's standing posture, and note in the register that scope was not formalised separately.

How the register gets built