Every configuration change to the screening model, read from the append-only audit log. This is the change-control evidence an examiner reviews (docs/model-governance.md).

Active entries on allowlist-action lists. An allowlist suppresses false positives, so each entry carries an expiry date, a review-by date, and a justification. Entries past their review date (or expired, or missing a justification) need action in Internal Lists — request a modify or removal there. An allowlist never suppresses a true SDN match.

Wolfsberg §3.1: every exclusion, suppression list and threshold decision carries a documented rationale and a risk acceptance. One list across allowlist entries (by id — names and justification text stay in Internal Lists), disabled list × record-type cells, deactivated rule overrides, raised per-list floors and a raised tenant threshold, each with who set it, who approved it and whether four-eyes backs it (docs/model-governance.md §5).

Phase 2 of the L1 program (docs/model-governance.md §11): an LLM adjudicates held reviews in the background (shadow → propose → delegated, four-eyes-controlled per tenant). This panel is the promotion evidence — weekly agreement between the LLM verdict and the eventual human disposition, split by the in-band class the deterministic tier cannot discriminate, plus the FP-verdict precision that gates any move to delegated. Counts only; per-review verdicts live on the payment record (propose stage and above).

Independent testing on a schedule (docs/independent-testing.md): seeded list entries are perturbed through the ladder rules, screened through the real path in test mode (excluded from every MI aggregate; no alert rows by default) under a screening-rate budget, and scored the way the match benchmark scores — an ATL pass alerts on the seed entry itself, a BTL pass clears. The cadence flag and the per-rule miss rate are the examiner's two questions.

One artifact for the second line, the auditor, the Part 504 certifying officer or the examiner (docs/model-governance.md §13): model inventory, design & intent, configuration in force, change control, data quality, list management, independent testing, ongoing monitoring, exceptions, AI components, the limitations statement, the framework control map, and an attestation carrying a configuration hash and a pack hash. Assembled from the database by code — nothing is written by a language model; sections that cannot be produced are shown as gaps, never omitted; no party names and no adjudicator reasoning ever enter it. Open the HTML and print it to PDF; the JSON is the machine-readable bundle; Verify recomputes the hash from the stored body.

The control response to a discovered defect or a new designation (Wolfsberg §7; Part 504 §504.3(d); docs/model-governance.md §14). Two honest lanes: alerted payments re-screened with their full party inputs, and cleared decisions re-screened by the recorded party names. Every payment that now qualifies is a finding classified by the entry's publish and removal dates — designated after the payment, a configuration or list-scope defect (the entry existed at screen time), or an additional entry on an already-alerted payment. Findings carry the payment reference, the entry, the score and the dates — never a name. Runs on the referential queue lane; one in flight per tenant.

Model-risk change control (docs/model-governance.md): one approver proposes a settings change, a different admin approves before it takes effect. The database refuses self-approval. One pending proposal per area at a time (per rule / per policy cell for those scopes). Rule-activation and OFAC-off proposals are raised from the Rules and Screening Policy screens and land here for approval.