feat: reconcile sanctions screening freshness

docs/RISK_COMPLIANCE_DOMAIN_BOUNDARY.md

@@ -12,6 +12,10 @@ Risk and compliance workflows for data protection incidents, DPIAs, compliance c
 - 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
 
@@ -28,20 +32,37 @@ Risk and compliance workflows for data protection incidents, DPIAs, compliance c
 - files
 - tasks
 - notifications
+- connectors
 
-## Seed State
+## Sanctions Screening Contract
 
-The current repository state is intentionally small:
+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.
 
-- module manifest and entry point
-- tenant-level permission definitions
-- manager and viewer role templates
-- documentation topic describing the module boundary
-- Gitea issue workflow templates
-- manifest contract test
+The module provides the versioned
+`risk_compliance.sanctions_screening` interface and
+`riskCompliance.sanctionsScreeningProvider` capability. A consumer explicitly
+submits:
 
-No runtime API, database model, migration, WebUI route, or navigation item is registered yet. The first implementation slice should preserve the boundary above and only add user-visible surfaces once the workflow model is clear.
+- an immutable list snapshot
+- an idempotency key
+- the minimum subject data required for comparison
+- matching limits and its `block`, `review`, or `degraded` failure policy
 
-## First Implementation Slice
+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.
 
-Define risk register, control, evidence, DPIA, incident, measure, and review-cycle concepts.
+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.