feat: implement assurance graph and screening evidence
This commit is contained in:
@@ -16,12 +16,17 @@ Risk and compliance workflows for data protection incidents, DPIAs, compliance c
|
||||
- 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
|
||||
|
||||
@@ -66,3 +71,49 @@ 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:
|
||||
|
||||
```text
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user