govoplan-risk-compliance/docs/RISK_COMPLIANCE_DOMAIN_BOUNDARY.md

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.