Evidence request builder

A PBC list is the evidence ask the testing pod fields before fieldwork begins. Each row names what is being asked for, of whom, by when, against which criterion, in what format, from which system, and at what reliance class. The named reviewer signs the list before it is fielded; the firm fields the list; rows resolve to received, received-partial, re-asked, closed, not-applicable, or deferred; and the closed list flows into the workpaper as the bridge from procedure to evidence inspected, and into the closure binder as the index of what was produced.

The deliverable is typically an Excel workbook rendered via the xlsx skill in document-skills because PBC lists live in spreadsheets through fieldwork (statuses updated as rows resolve, pivots run for routing and cadence management). The markdown in templates/default-output.md carries the named sections, fields, and the request-row contract; render to xlsx where the firm's workflow consumes a workbook, render to Word or Markdown where the deliverable is a discrete document (a regulator-bound pre-exam letter; a closure-pack appendix; a firm-internal memo where the spreadsheet is overkill). The format choice follows the workflow; the row-level contract is the same either way.

This skill produces that list. It does not run the test, draw the sample, draft the workpaper, classify exceptions, or assemble the closure binder. It produces the request list per templates/default-output.md shape, conforms to schemas/evidence-request.schema.json, and stops at preparer sign-off. The named reviewer signs separately, before fielding.

Ask first

Before drafting, get plain answers. Most cycles answer them from the signed test plan plus the sampling memo; if not, default and flag.

• Whose list is this for fielding to. First-line control owners typically; in some firms a second-line operations team fields requests on behalf of the control owners. The owner-role column drives routing and the escalation path drives unresponsive-owner handling.
• Has the test plan been signed off. A request list before pre-fieldwork sign-off on the test plan is fielding evidence against an unsigned scope, which is a methodology weakness on both artifacts. Stop and route to test-plan-builder if not. Where the cycle cannot wait (regulator request with a clock; examiner-prep deadline; in-flight enforcement response), draft a pro-forma PBC list that names the unsigned scope explicitly in the cover and limitations sections, marks every row's criterion_source with [scope unsigned — verify on test-plan sign-off], and routes the unsigned-scope risk to the named reviewer for explicit acknowledgement. The artifact is still useful (the firm can pre-stage evidence the eventual scope will likely need); the methodology weakness is on the face, not buried.
• Has the sample been designed. Where the requests need sample IDs, the sampling memo is the source. For small inline samples, the test plan's inline_sample_design is the source. Without a sample, the request list cannot reference the population at the row level for sample-driven procedures.
• What does the firm already know about the evidence in this control area. Prior cycle's request list, prior cycle's exceptions on evidence sufficiency, repeat-issue areas, system-of-record changes since last cycle. The previous list is the strongest input; the current list is largely a revision.
• Has anything material changed since the last cycle. System migrations, new vendor relationships, policy updates that changed where evidence sits, regulator letters that shifted what evidence the firm should be able to produce. Reusing a prior list without re-reading the system-of-record landscape is the most common drafting failure.

When scope is supplied, consume it: institution.type and institution.primary_regulators set the citation focus and tone, sector_overlay_set selects which references/sector-overlays/<sector>.md loads, cross_cutting_overlay_set selects the references/cross-cutting/<topic>.md files. Privacy overlay loads whenever the request list will pull artifacts containing NPI, PHI, PCI, or other regulated personal data, regardless of how the scope reads. When scope is not supplied, draft against what is on file (the test plan usually carries enough), default to the testing program's standing posture, and note in the request list that scope was not formalised separately.