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
• reusable assurance relationships from obligation through governed object, risk, control, evidence, finding, corrective measure, and effectiveness review

Does Not Own

• immutable audit log storage
• records retention engine
• inspection fieldwork
• domain-object lifecycle and corrective execution owned by the affected module
• policy rule evaluation or immutable audit-log storage

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.

Horizontal Assurance Graph

Sanctions screening is the first complete assurance vertical, not the whole module model. Risk Compliance persists the reusable graph:

Obligation -> governed object -> risk -> control -> evidence -> finding -> measure -> effectiveness review

Every node and relationship has a stable tenant-local identity, immutable revision history, effective and recorded time, owner and optional scope, provenance, legal/policy/evidence references, and optimistic-concurrency guards. Corrections create a new revision; the historical assertion is not rewritten or deleted. Governed-object nodes retain only an opaque reference to the object owned by another module.

The tenant API exposes bounded current-object listing, revision histories, aggregate counts, and graph traversal. Traversal is intentionally limited to eight relationships and 500 returned objects. Search indexes only current revisions, rechecks tenant access at result time, and omits confidential descriptions. Aggregate responses contain counts, never labels or opaque references.

Completed sanctions screenings automatically project obligation, party, exposure risk, version-pinned control, immutable evidence, and finding nodes. This projection is idempotent and includes unsuccessful or stale screening outcomes so operational uncertainty remains visible. The non-sanctions test fixture proves the entire chain through corrective measure and effectiveness review without coupling the graph to sanctions data.

Policy may advise or block based on assurance state; Audit records events; Files/Records retain referenced evidence; Tasks/Workflow may coordinate review and correction. Risk Compliance owns risk, control, finding, and effectiveness semantics, but the affected domain module remains authoritative for its object and corrective execution.

Access, recovery, and retirement

Read, write, and administration use the Risk Compliance workspace scopes and are always tenant-bound. Generated sanctions evidence additionally keeps the sanctions permissions on its source workflow. Database backup and restore is the recovery mechanism for the immutable graph; migration verification covers both graph tables. Module retirement is destructive and therefore requires a database snapshot before graph, source, screening, and review evidence is removed.