# Risk Compliance Domain Boundary

## Purpose

Risk and compliance workflows for data protection incidents, DPIAs, compliance controls, audit measures, risk registers, and internal-control evidence.

## Owns

- risk registers
- compliance controls
- DPIA records
- data protection incident records
- audit measures
- internal-control evidence
- immutable normalized sanctions-list snapshots
- version-pinned screening runs and candidate explanations
- reviewer dispositions, exceptions, and screening freshness
- block, review, and degraded screening-gate decisions

## Does Not Own

- immutable audit log storage
- records retention engine
- inspection fieldwork

## Integration Candidates

- audit
- policy
- records
- inspections
- files
- tasks
- notifications
- connectors

## Sanctions Screening Contract

Connectors owns acquisition and raw source evidence. Risk Compliance imports an
exact connector snapshot, preserves its provenance, normalizes the list, and
owns every legal screening and review decision made from it.

The module provides the versioned
`risk_compliance.sanctions_screening` interface and
`riskCompliance.sanctionsScreeningProvider` capability. A consumer explicitly
submits:

- an immutable list snapshot
- an idempotency key
- the minimum subject data required for comparison
- matching limits and its `block`, `review`, or `degraded` failure policy

The response contains a stable `risk-screening:<run-id>` evidence reference and
a gate decision. Consumers can later check that evidence against a current
subject, an expected or latest source snapshot, and a current policy without
importing this module's internals.

Freshness reasons explicitly distinguish source replacement or age, subject
changes, matcher/normalization/policy changes, incomplete outcomes, and expired
or review-due dispositions. The reconciliation API lists the latest known
screening per subject that can already be proven stale. Subject changes remain
the consuming system's responsibility because Risk Compliance deliberately
stores immutable screening-time snapshots rather than owning each source
record.

Fuzzy candidates always require review. A confirmed match blocks; a set of
independently cleared false positives allows; source or execution uncertainty
uses the consuming module's configured failure policy.