compliance-testing

Designs the sample for a control test before fieldwork starts. Defines the testable population, picks a sampling method (statistical or judgmental), sizes the sample, sets a tolerable deviation rate, names the selection technique, and documents the rationale a reviewer can defend in front of an examiner. Output is a sampling memo that drops into the test plan or workpaper as a referenceable artifact. Best for: - A second-line testing pod or internal-audit team is scoping a control test and needs a defensible sample method, size, and rationale before pulling evidence. - A reviewer is challenging a first-line control owner's self-attested testing because the sampling rationale is missing or thin and the sample needs to be redesigned. - A walkthrough has confirmed control design and the next step is sizing operating-effectiveness testing across a defined population. - A prior-cycle workpaper failed QA on sample-design grounds and the redraft starts at the sampling memo. Not the right tool when: - The control or obligation has not been mapped yet. Run `risk-compliance-core/skills/control-matrix` and come back with a control ID. - The full test plan has not been scoped. Run `test-plan-builder`; this skill produces the sampling section that test-plan-builder consumes by reference. - The evidence ask itself is the work. Run `evidence-request-builder`; sampling sets which items the request targets, but the request artifact is separate. - Exceptions have already been identified and need classification. Run `exception-analysis`. - The completed workpaper is being written. Run `workpaper-drafter`; this skill stops at the sample drawn.

Drafts the provided-by-client (PBC) evidence request list for a single control test cycle: one numbered row per ask, each carrying the control objective tested, criterion source, artifact requested, format, system of record, owner role, due date, population reference, reliance classification, and status. Produced before fieldwork begins; tracked through fieldwork; closed when every row resolves to received-or-not-applicable. The deliverable is an Excel workbook rendered via the `xlsx` skill in `document-skills`. Downstream, the workpaper consumes the request_id per evidence row and the closure binder consumes the closed list as the index of what was produced. Best for: - A compliance-testing or internal-audit pod has a signed test plan and is preparing the evidence ask before fieldwork begins. - A second-line reviewer is preparing for an upcoming examination and needs to pre-anticipate the regulator's evidence asks against current control coverage. - A QA reviewer is building a re-perform request list to redo a workpaper because the original evidence trail was thin. Not the right tool when: - The test scope and procedures have not been written. Use `test-plan-builder` first; this skill consumes the test plan's procedures and criteria. - The sample has not been designed. Use `control-sampling` first where the requests need a sample-ID set; small inline samples can be drafted alongside the request list, large samples sit in a sampling memo this skill references. - Evidence is in hand and the work is documenting test results. Use `workpaper-drafter`. - The work is QAing a completed workpaper for evidence sufficiency. Use `qa-workpaper`. - The work is assembling the evidence index after fieldwork closes. Use `evidence-binder` in `risk-compliance-core` — that skill indexes what was produced; this skill asks for what is needed. The two are different artifacts at different lifecycle points.

Classifies the deviations a control test surfaced into design gaps, operating-effectiveness failures, evidence gaps, scope disagreements, data-integrity issues, and anomalies; ranks severity with rationale; names a root-cause hypothesis; sets disposition (elevate to issue, close at exception, re-test, expand sample); and builds the handoff package downstream issue write-up consumes. Output is an exception register that pairs with the testing workpaper and ladders confirmed exceptions into the issue lifecycle. Best for: - A compliance-testing or internal-audit reviewer has finished sample testing and is sitting on a list of deviations that need to be classified before they become findings. - A QA reviewer is challenging a workpaper's exception treatment because the line between evidence gap and control failure was blurred. - A repeat-issue review needs to confirm whether deviations across testing cycles are the same root cause or coincidental. - A second-line lead is preparing a handoff to issue write-up and wants the criterion, condition, cause, effect, and recommendation seed populated before the writer opens the issue artifact. Not the right tool when: - The test has not been run yet. Pre-fieldwork scoping is `test-plan-builder`; sample design is `control-sampling`; evidence asks are `evidence-request-builder`. - The exception has already been classified and the work is drafting the issue. Use `risk-compliance-core/skills/issue-writeup`; this skill produces the input that issue-writeup consumes via `source_exception_id`. - The work is drafting the workpaper end to end. Use `workpaper-drafter`; that skill consumes the exception register this skill produces via `exception_register_id`. - The work is QA on a completed workpaper. That is `qa-workpaper`.

Reviews a completed control-test workpaper for QA along named dimensions: scope alignment to the test plan, source-criteria sufficiency, evidence reliability, procedure execution rigor, exception classification, conclusion support, severity calibration, reviewer separation, and remediation handoff. Output is a QA review pack — Excel workbook with QA markup tabs over the workpaper plus a Word QA memo summary — that lists deficiencies by severity, a decision (accept, return for rework, conditional accept), and required rework before workpaper closure. Best for: - A second-line QA function or independent reviewer is performing the standard QA pass over a completed workpaper before issue closure or examiner sharing. - An internal-audit director is rolling up workpaper-quality metrics across a testing cycle and needs structured QA notes per workpaper. - A targeted Federal Reserve, OCC, FDIC, CFPB, NYDFS, or state DOI exam is imminent and the team is doing a self-QA sweep on the workpaper population the examiner will likely sample. - A workpaper failed prior QA, was reworked, and needs a post-rework re-QA before closure. Not the right tool when: - The workpaper has not been drafted. Use `workpaper-drafter`. - The test plan itself is being reviewed (design-stage review of `test-plan-builder` output, not QA of a completed workpaper). - Exceptions identified during QA need their own classification. Use `exception-analysis` for the QA-identified deviations from the methodology, not for the original control deviations the workpaper already classified. - The work is drafting an issue from a confirmed finding. Use `risk-compliance-core/skills/issue-writeup`; this skill's deficiency findings on the workpaper are not the same as control issues on the entity.

Drafts the pre-fieldwork test plan for a single control test cycle: scope, control objective, named source criteria, period, population, sampling reference, walkthrough plan, design-effectiveness procedures, operating-effectiveness procedures, evidence-request reference, pass and fail criteria, limitations, downstream consumers, and reviewer sign-off block. Output is the planning artifact that gets reviewer sign-off before evidence pulls and fieldwork begin; it is the contract the workpaper is written against. Best for: - A compliance-testing or internal-audit team is scoping an annual test plan or a one-off targeted review and needs the pre-fieldwork planning workpaper before evidence pulls and fieldwork. - A second-line reviewer is responding to a regulatory-change-management trigger (a new rule, an updated examiner priority, a new exam letter) by standing up a fresh test against an updated control set. - An audit lead is rebuilding a test program after a prior issue, restating control objectives and procedures from first principles before the next cycle starts. Not the right tool when: - The control inventory and risk-to-control mapping has not been done. Run the control-matrix work in `risk-compliance-core` first; the test plan consumes a control ID, it does not invent one. - Sample design is the only thing needed. Use `control-sampling` standalone; the test plan references the sampling memo by ID. - The evidence ask is the only thing needed. Use `evidence-request-builder` standalone; the test plan references the evidence request list by ID. - Fieldwork is in flight or complete. Use `workpaper-drafter` for during and post-fieldwork documentation. Use `qa-workpaper` for review of the completed workpaper. Boundary: this skill is pre-fieldwork; `workpaper-drafter` is during and post; `qa-workpaper` is review of completed work. The three are sequential, not redundant.