DataFab Graph Operations

Version: 4.3 Last Updated: May 2026

Component Overview

The Graph Operations module provides comprehensive capabilities for entity analysis, pattern detection, and operational decision-making. It leverages the Knowledge Fabric’s graph-based entity resolution and the Studio’s workflow capabilities to deliver an integrated operational intelligence solution.

Core Capabilities:

Capability	Description	Security Relevance
Knowledge Graph Integration	Entity resolution and relationship mapping	Data integrity, access control
Rule Engine	Pattern scoring and operational decision rules	Rule versioning, audit trail
Graph Workflows	Multi-step operational process orchestration	Process authorization, escalation
External Enrichment	Data enrichment and third-party integration	Source validation, provenance
Graph Screening	Entity screening against external sources	Match verification, false positive handling
Case Management	Operational case tracking and documentation	Evidence chain, retention

Architecture Overview

┌─────────────────────────────────────────────────────────────────────────┐
│                    GRAPH OPERATIONS ARCHITECTURE                        │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  ┌────────────────────────────────────────────────────────────────────┐ │
│  │                    OPERATIONS INTERFACE                            │ │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐  │ │
│  │  │  Case Queue  │  │  Dashboards  │  │  Reporting & Analytics   │  │ │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘  │ │
│  └────────────────────────────────────────────────────────────────────┘ │
│                              │                                          │
│  ┌────────────────────────────────────────────────────────────────────┐ │
│  │                    OPERATIONS ENGINE                               │ │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌───────────┐  │ │
│  │  │  Rule       │  │  Graph      │  │  Screening  │  │   Case    │  │ │
│  │  │  Engine     │  │  Workflows  │  │  Service    │  │  Manager  │  │ │
│  │  └─────────────┘  └─────────────┘  └─────────────┘  └───────────┘  │ │
│  └────────────────────────────────────────────────────────────────────┘ │
│                              │                                          │
│  ┌────────────────────────────────────────────────────────────────────┐ │
│  │                    KNOWLEDGE FABRIC INTEGRATION                    │ │
│  │  ┌─────────────────┐  ┌─────────────────┐  ┌────────────────────┐  │ │
│  │  │ Knowledge Graph │  │ Entity          │  │ External Source    │  │ │
│  │  │ (Entities &     │  │ Resolution      │  │ Integration        │  │ │
│  │  │  Relationships) │  │                 │  │                    │  │ │
│  │  └─────────────────┘  └─────────────────┘  └────────────────────┘  │ │
│  └────────────────────────────────────────────────────────────────────┘ │
│                              │                                          │
│  ┌────────────────────────────────────────────────────────────────────┐ │
│  │                    CUSTOMER SYSTEM CONNECTIONS                     │ │
│  │  Business Systems │ CRM │ Analytics │ Data Management              │ │
│  └────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘

Knowledge Graph for Operations

The Knowledge Fabric’s graph database provides the foundation for operational intelligence, enabling entity resolution, relationship mapping, and pattern analysis across connected data sources.

Operational Entity Model

Entity Type	Description	Operational Relevance
Entity	Core business entities (persons, organizations)	Analysis subject, pattern detection
Relationship	Connections between entities	Network analysis, anomaly detection
Case	Investigation or analysis record	Case management, audit trail
Assessment	Calculated analytical profile	Pattern scoring, decision support
Detection	Pattern or anomaly detection result	Alert management
Document	Evidence and supporting materials	Documentation, compliance

Operational Relationship Types

Relationship	Description	Operations Use
OWNS	Ownership or control stake	Structure analysis
CONTROLS	Administrative control	Authority mapping
RELATED_TO	Personal/business relationship	Network analysis
HAS_CASE	Entity linked to operational case	Case tracking
HAS_DETECTION	Entity linked to detection result	Alert management
HAS_ASSESSMENT	Entity linked to analytical profile	Risk monitoring

Entity Resolution for Operations

The Entity Resolution Engine identifies duplicate and related records across customer systems to build a unified view of each entity.

Resolution Security Controls:

Control	Implementation
Match Decision Audit	All match decisions logged with reasoning
Human Review Queue	Uncertain matches routed for manual review
Source Attribution	Every attribute linked to source system
Confidence Scoring	Match confidence visible for review
Merge History	Complete history of entity merges preserved

Graph Queries for Operations

Query Type	Purpose	Security Control
Relationship Traversal	Identify connected entities through relationship chains	Traversal depth limits
Network Analysis	Map entity relationships and patterns	Result filtering by permission
Pattern Matching	Detect suspicious or significant relationship patterns	Query audit logging
Assessment Aggregation	Calculate network-level analysis scores	Authorized users only

Rule Engine

The Rule Engine enables administrators to define, version, and execute business rules for pattern detection, operational scoring, and decision workflows.

Rule Engine Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                    RULE ENGINE ARCHITECTURE                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌──────────────────────────────────────────────────────────--──┐   │
│  │                    RULE DEFINITION LAYER                     │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐           │   │
│  │  │  Rule       │  │  Condition  │  │  Action     │           │   │
│  │  │  Builder    │  │  Editor     │  │  Designer   │           │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘           │   │
│  └───────────────────────────────────────────────────────────-──┘   │
│                              │                                      │
│  ┌────────────────────────────────────────────────────────────-─┐   │
│  │                    RULE EXECUTION ENGINE                     │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐           │   │
│  │  │  Evaluation │  │  Scoring    │  │  Action     │           │   │
│  │  │  Engine     │  │  Engine     │  │  Executor   │           │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘           │   │
│  └────────────────────────────────────────────────────────────-─┘   │
│                              │                                      │
│  ┌─────────────────────────────────────────────────────────────-┐   │
│  │                    GOVERNANCE LAYER                          │   │
│  │  • Version Control   • Approval Workflow   • Audit Trail     │   │
│  └────────────────────────────────────────────────────────────-─┘   │
└─────────────────────────────────────────────────────────────────────┘

Rule Types

Rule Type	Purpose	Example Use Case
Pattern Scoring	Calculate numeric pattern scores	Entity assessment
Anomaly Detection	Classify deviations from expected patterns	Unusual activity detection
Classification	Assign categories based on conditions	Entity categorization
Threshold	Trigger actions when values exceed limits	Alert generation
Routing	Direct workflow based on conditions	Escalation to analysts
Validation	Verify data meets requirements	Input data validation

Rule Definition Security

Control	Implementation
Role-Based Editing	Only authorized roles can create/modify rules
Version Control	All rule changes versioned with full history
Approval Workflow	Rule changes require approval before activation
Testing Required	Rules must pass the test suite before deployment
Rollback Support	Previous versions can be restored instantly

Pattern Scoring Rules

Pattern scoring rules calculate numeric scores based on configurable factors and weights.

Scoring Components:

Component	Description	Security Control
Factor Definition	Pattern factors with categories and weights	Admin-only modification
Score Calculation	Weighted aggregation of factors	Audit trail on calculations
Threshold Mapping	Score ranges mapped to analysis levels	Configurable per policy
Override Handling	Manual score adjustments	Requires justification, logged

Pattern Factor Categories:

Category	Examples	Typical Weight Range
Entity Type	Organization type, sector	0-30 points
Geography	Country, jurisdiction	0-25 points
Relationship	Connection depth, multiplicity	0-20 points
Activity	Transaction patterns, velocity	0-20 points
History	Past alerts, issues	0-15 points
Behavioral	Deviation from baseline	0-20 points

Assessment Level Mapping:

Assessment Level	Score Range	Review Frequency	Expected Actions
Low	0-25	36 months	Routine monitoring
Medium	26-50	24 months	Standard review
High	51-75	12 months	Enhanced analysis
Critical	76-100	6 months	Immediate review

Rule Versioning

Control	Description
Immutable Versions	Published versions cannot be modified
Version History	Complete history of all changes preserved
Change Attribution	Every change linked to user and timestamp
Comparison View	Side-by-side comparison of versions
Audit Export	Version history exportable for compliance

Rule Execution Security

Control	Implementation
Execution Isolation	Rules execute in a sandboxed environment
Input Validation	All inputs validated against schema
Output Verification	Results validated before action execution
Timeout Enforcement	Maximum execution time enforced
Resource Limits	Memory and CPU limits on rule execution

Rule Audit Trail

Event	Logged Data	Retention
Rule Created	Rule definition, creator, timestamp	2 years
Rule Modified	Changes, modifier, justification	2 years
Rule Activated	Version, approver, effective date	2 years
Rule Executed	Input hash, score, actions triggered	1 year
Rule Overridden	Override value, justification, approver	2 years

DAG Rules (Self-Organising Rule Graph)

DAG Rules extend the Rule Engine with a self-organising directed acyclic graph (DAG) of rule nodes. Each rule node declares its inputs, outputs, and dependencies; the platform infers the execution order, parallelism opportunities, and isolation boundaries from the node definitions themselves. There is no hand-written workflow or pipeline file — the rule graph organises itself from the registry.

DAG Rules are the foundation for utility-grade rule chains (Transaction Monitoring, Compliance, Car Finance) where a single decision must aggregate evidence from many independent rules with shared upstream context.

DAG Rule Concepts

Concept	Description
Rule Node	A single rule evaluator with a stable key, declared inputs, and a typed output
Rule Block	A set of rule nodes that share a tier and may execute in parallel
Tier	A monotonically increasing integer ordering blocks; tiers express coarse data-flow phases
Execution Context	A typed, in-memory bag of shared state propagated through the DAG (entities, baselines, tags, focus sets, alert info, external services)
Rule Output	The structured result of a rule (matched, severity, band, data, reason codes)
Self-Organisation	Tiers + declared dependencies fully determine execution order, parallelism, and skip conditions — no manual orchestration
Chain Trace	A persisted JSON DAG of every node, edge, parameter, timing, and outcome for the run

DAG Architecture

┌──────────────────────────────────────────────────────────────────────┐
│                    DAG RULE ENGINE ARCHITECTURE                      │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌──────────────────────────────────────────────────────────────┐    │
│  │                  RULE REGISTRY                               │    │
│  │  Stable key → Async evaluator + Metadata + Dependencies      │    │
│  └──────────────────────────────────────────────────────────────┘    │
│                              │                                       │
│  ┌──────────────────────────────────────────────────────────────┐    │
│  │                  RULE CHAIN DEFINITION                       │    │
│  │  Ordered Blocks (by tier) │ Parallel Flag │ Scoring Config   │    │
│  │  Decision Config │ Domain Weights │ Hard Overrides           │    │
│  └──────────────────────────────────────────────────────────────┘    │
│                              │                                       │
│  ┌──────────────────────────────────────────────────────────────┐    │
│  │                  CHAIN EXECUTOR                              │    │
│  │  ┌────────────┐  ┌─────────────┐  ┌──────────────────┐       │    │
│  │  │  Topology  │  │  Parallel/  │  │  Per-Rule Error  │       │    │
│  │  │  Resolver  │  │  Sequential │  │  Isolation       │       │    │
│  │  └────────────┘  └─────────────┘  └──────────────────┘       │    │
│  │  ┌────────────┐  ┌─────────────┐  ┌──────────────────┐       │    │
│  │  │ Dependency │  │  Disabled-  │  │  Timing &        │       │    │
│  │  │ Guard      │  │  Rule Guard │  │  Resource Gate   │       │    │
│  │  └────────────┘  └─────────────┘  └──────────────────┘       │    │
│  └──────────────────────────────────────────────────────────────┘    │
│                              │                                       │
│  ┌──────────────────────────────────────────────────────────────┐    │
│  │                  EXECUTION CONTEXT                           │    │
│  │  Entities │ Subject Profile │ Baseline │ Tags │ Focus Set    │    │
│  │  Rule Outputs │ External Services (Text-to-Cypher, OSINT)    │    │
│  └──────────────────────────────────────────────────────────────┘    │
│                              │                                       │
│  ┌──────────────────────────────────────────────────────────────┐    │
│  │                  CHAIN TRACE (JSONB)                         │    │
│  │  Nodes │ Edges │ Parameters │ Scoring │ Decision │ Timing    │    │
│  └──────────────────────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────────────────────┘

Rule Node Definition

A rule node is a registry entry — not a free-form function. The registry binds a stable key to an async evaluator and declares its surface area.

Field	Description
`key`	Stable rule identifier (e.g., `TM_TRX_006`); referenced from chains, configuration, and audit
`evaluate`	Async callable accepting `ExecutionContext` and returning a `RuleOutput`
`inputs`	Named context fields the rule reads (e.g., `transactions`, `baseline`, `tags`)
`outputs`	Named context fields the rule writes (e.g., `tags`, `focus_set`, `rule_outputs[key]`)
`depends_on`	Other rule keys whose outputs must exist before this rule may execute
`tier`	Tier number determining the block this rule joins (assigned at chain-build time)
`parallel_safe`	Boolean — declares whether the rule may run alongside other rules in the same tier
`external_services`	Optional declared dependencies on external services (Text-to-Cypher, OSINT, screening)
`metadata`	Display name, description, scoring weight, severity rule, audit retention

Self-Organisation

The DAG self-organises from the rule node declarations:

Mechanism	Behavior
Tier Sorting	Blocks are sorted by tier ascending; each tier completes before the next begins
Intra-Tier Parallelism	Within a tier, rules with `parallel_safe=True` and no unresolved cross-rule dependencies execute concurrently
Dependency Resolution	Rules whose `depends_on` outputs are not present in `ExecutionContext.rule_outputs` are skipped with reason code `DEPENDENCY_NOT_MET`
Disabled Rule Guard	Rules listed in `ExecutionContext.disabled_rules` are skipped with reason code `RULE_DISABLED` and never invoked
Conditional Execution	Rules may declare a precondition predicate over the context (e.g., “skip if focus set empty”); failure produces `PRECONDITION_NOT_MET`
Cross-Block Convergence	Outputs from one tier feed downstream tiers via the shared context, not via explicit wiring

Execution Context

The Execution Context is the typed shared state propagated through the DAG.

Field	Description
`entities`	The entities under analysis (transactions, applications, claims — utility-specific)
`subject_profile`	KYC / customer / applicant attributes that ground the analysis
`baseline`	Historical statistics computed by foundation rules (averages, percentiles, deltas)
`tags`	Index map: tag-name → set of entity indices currently bearing that tag
`focus_set`	Set of entity indices that downstream rules must restrict attention to
`rule_outputs`	Map of rule_key → `RuleOutput`; populated as rules complete
`alert_info`	The triggering alert / case / application metadata
`disabled_rules`	Set of rule keys excluded from this run (per-tenant configuration or runtime override)
`external_services`	Bound references to Text-to-Cypher, OSINT, screening services
`scoring`	Working scoring state (suspicion inputs, materiality inputs)
`decisioning`	Decision artifacts (final score, hard-override flags, RFI/SAR pack inputs)

Rule Output

Field	Description
`matched`	Boolean — did this rule fire for the entity / case
`severity`	Float in [0.0, 1.0] used by scoring rules
`band`	Optional categorical band (`Low` / `Medium` / `High` / `Critical`)
`data`	Rule-specific structured output (counts, ratios, top-K lists, evidence pointers)
`reason_codes`	List of stable codes explaining the result (e.g., `UNREGULATED_COUNTERPARTIES`, `EVAL_ERROR:TIMEOUT`, `DEPENDENCY_NOT_MET`)

Block Execution Strategy

Strategy	Behavior	Typical Use
Sequential Block	Rules in the block execute one at a time in registry order	Foundation rules where each writes to context state consumed by the next
Parallel Block	Rules in the block execute concurrently via async fan-out	Independent pattern detectors that share inputs but produce isolated outputs
Mixed Block	Sequential prelude rule (e.g., precedence resolution) followed by a parallel fan-out	Tagging tier where precedence must be set before independent taggers run
Convergence Block	Single rule that aggregates outputs from many upstream rules	Composite scoring, materiality, decision routing

Error Isolation

Failure	Behavior
Rule Exception	Caught at the executor level; produces `RuleOutput(matched=False, reason_codes=["EVAL_ERROR:<type>"])`; chain continues
External Service Failure	Caught and translated to a reason code; rule’s deterministic fallback is invoked if declared
Timeout	Rule abandoned at deadline; reason code `EVAL_ERROR:TIMEOUT`; chain continues
Validation Failure	Output rejected if it fails its declared shape; reason code `EVAL_ERROR:OUTPUT_SHAPE`
Whole-Block Failure	Block-level guard catches catastrophic failures; downstream blocks see missing outputs and skip via `DEPENDENCY_NOT_MET`

A failure in one rule never cascades into the chain; this is fundamental to the audit posture of utility-grade rule chains.

Scoring and Decisioning

DAG chains include built-in scoring and decision blocks. The chain definition carries a ScoringConfig and a DecisionConfig.

Scoring Config:

Field	Description
`suspicion_weight`	Weight applied to aggregated rule severities
`materiality_weight`	Weight applied to financial / impact band
`rule_weights`	Per-rule weight in the suspicion aggregate
`domains`	Domain groupings (e.g., A–E) with caps and convergence bonuses
`confidence_max_reduction`	Maximum reduction applied when knowledge gaps are present
`benign_max_reduction`	Maximum reduction applied when benign mitigants are confirmed

Decision Config:

Field	Description
`escalation_threshold`	Final score above which the chain escalates (utility-specific outcome, e.g., SAR / decline / refer)
`review_threshold`	Final score above which the chain requests further information (e.g., RFI / additional KYC)
`confidence_threshold`	Minimum confidence required for review-band decisions
`hard_overrides`	Reason codes that force escalation regardless of score (e.g., sanctions hit, fraud confirmed)

Chain Trace

Every chain run produces a structured trace stored in JSONB on the consuming utility’s analysis record. The trace captures the full DAG, not just the final result.

Field	Description
`chain_id`	Stable identifier for the chain definition and version
`typology` / `domain`	Human-readable label of what the chain assessed
`started_at` / `completed_at`	ISO timestamps
`total_duration_ms`	End-to-end duration
`nodes`	Per-rule node entries: id, tier, key, status, duration_ms, output summary, reason codes
`edges`	Data-flow edges between rules (source → consumer) inferred from declared inputs/outputs
`parameters`	Effective parameter values used (after configuration overrides)
`scoring`	Inputs and intermediate values for the score: suspicion_inputs, materiality_inputs, confidence_factor, mitigant_factor, final_risk_score
`decision`	Final decision label and the rule that produced it
`hard_override_triggered`	Reason code, if any, that forced escalation

DAG Rule Security Controls

Control	Implementation
Registry-Only Loading	Rules must be registered to be invoked; ad-hoc evaluators are rejected by the executor
Per-Rule Authorization	Disabling, parameterising, or overriding a rule requires the same role as Rule Engine modification
Isolated Execution	Each rule runs in the executor’s async sandbox; resource and timeout limits apply per rule
Read-Only Context Discipline	Rules may only write to fields they declared as outputs; violations are rejected at runtime
External Service Whitelisting	Rules may only call services declared in `external_services` and bound by the executor
Tenant Scoping	The chain run is bound to a tenant; all context state is scoped accordingly
Hard-Override Authorization	Decision config and hard-override reason codes are change-controlled like rule definitions
Trace Integrity	Chain traces are append-only on the analysis record; modification is not permitted post-run

DAG Audit Trail

Event	Logged Data	Retention
Chain Defined	Chain ID, version, blocks, scoring/decision config, author	2 years
Chain Executed	chain_id, tenant, alert/case ID, total_duration_ms, decision	1 year
Rule Skipped	Rule key, reason code (`DEPENDENCY_NOT_MET`, `RULE_DISABLED`, `PRECONDITION_NOT_MET`)	1 year
Rule Errored	Rule key, error type, attempt count	1 year
Hard Override Triggered	Reason code, rule key, decision change	2 years
Rule Disabled	Rule key, tenant, justification, approver	2 years

Relationship to Pattern Scoring Rules

The classical Pattern Scoring Rules described above remain the model for individual rule definitions. DAG Rules build on top: a chain is an ordered set of pattern-scoring rules plus aggregation, scoring, and decision rules, all expressed through the same registry. A standalone Pattern Scoring Rule can be promoted into a DAG chain by declaring its tier, dependencies, and parallel-safety flag.

Integration Points

04-Studio (DDAs, Chain of Agents) — DDAs may consume DAG rule outputs as evidence; Chain of Agents may treat a DAG chain run as a single agent step with HUMAN_IN_THE_LOOP gating.
13-Graph-RAG (Text-to-Cypher Rules) — DAG rule nodes consume Text-to-Cypher through declared external services; results are evidence-packed into rule outputs.
05-AI-LLM — Any rule that uses LLM-backed reasoning (e.g., narrative generation, evidence summarisation) routes through the LightLLM Gateway with provenance.
DataFab Utilities — Transaction Monitoring, Car Finance, and Compliance utilities each ship a DAG chain definition; see the Utilities section.

Graph Workflows

The Graph Workflow system orchestrates multi-step operational processes with human tasks, automated actions, and control mechanisms.

Graph Workflow Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                    GRAPH WORKFLOW ARCHITECTURE                      │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌────────────────────────────────────────────────────────-─────┐   │
│  │                    PROCESS DEFINITION                        │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐           │   │
│  │  │  Process    │  │  Task       │  │  Gateway    │           │   │
│  │  │  Designer   │  │  Library    │  │  Config     │           │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘           │   │
│  └────────────────────────────────────────────────────────────-─┘   │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────-──┐   │
│  │                    EXECUTION ENGINE                          │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐           │   │
│  │  │  Process    │  │  Task       │  │  Event      │           │   │
│  │  │  Runtime    │  │  Manager    │  │  Handler    │           │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘           │   │
│  └──────────────────────────────────────────────────────────-───┘   │
│                              │                                      │
│  ┌───────────────────────────────────────────────────────────-──┐   │
│  │                    INTEGRATION LAYER                         │   │
│  │  • Knowledge Graph   • Rule Engine   • Notification Service  │   │
│  └────────────────────────────────────────────────────────────-─┘   │
└─────────────────────────────────────────────────────────────────────┘

Operational Process Types

Process Type	Purpose	Trigger
Entity Onboarding	Initial entity analysis workflow	Entity creation
Periodic Assessment	Scheduled re-analysis	Timer, score change
Alert Investigation	Event-driven analysis	Detection, manual referral
Pattern Analysis	Deep pattern investigation	High-risk detection
Escalation	Management review process	Risk threshold, policy

Pattern-Based Workflow Triggering

The Rule Engine integrates with Graph Workflows to automatically trigger appropriate workflows based on pattern detection.

Workflow Trigger Flow:

┌─────────────────────────────────────────────────────────────────────┐
│                    PATTERN-BASED WORKFLOW TRIGGERING                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  Entity Event ──▶ [Pattern Detection] ──▶ [Rule Evaluation]         │
│       │                  │                      │                   │
│       ▼                  ▼                      ▼                   │
│  (New entity,        (Score calculated)     (Rules matched)         │
│   data change,                                  │                   │
│   alert)                                        ▼                   │
│                                     [Workflow Selection]            │
│                                           │                         │
│              ┌────────────────────────────┼────────────────┐        │
│              ▼                            ▼                ▼        │
│         [Low Risk]                  [Medium Risk]    [High Risk]    │
│              │                            │                │        │
│              ▼                            ▼                ▼        │
│       Standard Review                Extended Review   Critical     │
│        Workflow                       Workflow          Review      │
│              │                            │            Workflow     │
│              └────────────────────────────┼────────────────┘        │
│                                           ▼                         │
│                                    [Task Assignment]                │
│                                           │                         │
│                                           ▼                         │
│                                    [Process Execution]              │
│                                           │                         │
│                                           ▼                         │
│                                     [Audit Trail]                   │
└─────────────────────────────────────────────────────────────────────┘

Workflow Task Types

Task Type	Description	Security Control
User Task	Human action required	Role-based assignment
Service Task	Automated system action	Permission validation
Script Task	Custom logic execution	Sandboxed execution
Send Task	External communication	Message logging
Receive Task	Wait for external event	Event validation

Workflow Security Controls

Control	Implementation
Process Authorization	Only authorized users can start processes
Task Assignment	Tasks assigned based on role and workload
Escalation Rules	Automatic escalation on SLA breach
Delegation Controls	Delegation requires approval, logged
Completion Verification	Task completion validated before proceeding

Workflow Definition Security

Control	Description
Version Control	Process definitions versioned
Change Approval	Process changes require multi-party approval
Testing Required	Processes must pass simulation before deployment
Rollback Support	Previous versions can be restored
Access Restrictions	Process definition access role-based

Task Assignment Security

Control	Implementation
Role-Based Assignment	Tasks assigned to roles, not individuals
Workload Balancing	Even distribution across team members
Conflict Avoidance	Prevent assignment to conflicted parties
Audit Trail	All assignments and reassignments logged
SLA Monitoring	Task completion tracked against SLA

Escalation Controls

Trigger	Action	Security Control
SLA Breach	Escalate to supervisor	Automatic, logged
Risk Threshold	Escalate to management	Rule-based, audited
Manual Request	Escalate per request	Requires justification
Timeout	Reassign or escalate	Configurable per task

Process Instance Security

Control	Description
Instance Isolation	Each process instance isolated
Data Encryption	Process data encrypted at rest
Access Control	Instance access based on role and assignment
State Protection	State transitions validated and logged
Cancellation Control	Cancellation requires authorization

External Source Integration

The Graph Operations module integrates with external data sources for entity verification and enrichment.

External Source Categories

Category	Examples	Data Types
Corporate Registries	Corporate filings, registration records	Incorporation, officers, filings
Relationship Data	Business databases, industry databases	Connections, associations
Public Records	News, legal records	Public information, history
Regulatory Data	Regulatory databases	Compliance records
Industry Data	Industry-specific data	Sector information

Source Integration Security

Control	Implementation
Source Validation	Only approved sources in registry
Credential Isolation	Per-source credential management
Rate Limiting	Respect source API limits
Data Minimization	Retrieve only required fields
Caching Policy	Time-limited caching per source
Provenance Tracking	Full lineage from source to graph

Enrichment Workflow

Stage	Description	Security Control
Request	Entity submitted for enrichment	Authorization check
Matching	Entity matched against external source	Matching rules applied
Retrieval	Data fetched from external source	Encrypted transport
Fusion	External data merged with existing	Conflict resolution rules
Validation	Enriched data validated	Schema validation
Storage	Enriched entity persisted	Access control inherited
Audit	Enrichment event logged	Full audit trail

Graph Screening Service

The Graph Screening Service performs entity screening against external sources.

Screening Types

Screening Type	Sources	Frequency
Database Screening	Business databases, registries	Real-time, periodic batch
Regulatory Screening	Regulatory databases	On-demand, periodic
Public Records Screening	News and public records	Continuous monitoring

Screening Security Controls

Control	Implementation
Match Verification	Potential matches require human review
False Positive Management	Documented false positive decisions
Alert Escalation	True matches escalated per policy
Screening Audit	All screening activity logged
Source Update Tracking	Source list versions tracked

Case Management

Operational cases track analyses, investigations, and decision records.

Case Types

Case Type	Purpose	Lifecycle
Initial Analysis	Entity onboarding analysis	Open → Review → Concluded
Deep Investigation	Detailed pattern investigation	Triggered → Analyze → Escalate/Close
Pattern Review	Systematic pattern assessment	Open → Review → Documented
Management Review	Senior review and approval	Prepared → Review → Approved/Rejected

Case Security Controls

Control	Implementation
Access Control	Case access based on role and assignment
Evidence Chain	All documents and notes timestamped
Decision Audit	All decisions logged with justification
Retention Policy	Cases retained per operational requirement
Export Controls	Case export requires authorization

User Roles and Permissions

Operations-Specific Roles

Role	Description	Permissions
Analyst	Day-to-day operational analysis work	Case work, screening review, standard analysis
Senior Analyst	Senior operations staff	Case approval, pattern override, team management
Operations Manager	Operations leadership	Escalation approval, full case access
Data Coordinator	Intake and coordination	Create cases, basic screening, escalate
Auditor	Internal/external auditor	View all cases, run reports, no edit

Permission Matrix

Action	Analyst	Senior	Manager	Coordinator	Auditor
Create Case	✓	✓	✓	✓	✗
Review Case	✓	✓	✓	✗	✓
Approve Case	✗	✓	✓	✗	✗
Override Assessment	✗	✓	✓	✗	✗
Escalate Case	✗	✓	✓	✗	✗
Modify Rules	✗	✓	✓	✗	✗
View Reports	✓	✓	✓	✗	✓

Audit Logging

Operations-Specific Events

Event Category	Logged Data	Retention
Case Created	Case ID, entity, creator, type	3 years
Case Decision	Case ID, decision, approver, justification	3 years
Pattern Detection	Entity, score, factors, detector	3 years
Screening Performed	Entity, sources, matches, reviewer	3 years
Rule Executed	Rule ID, inputs, score, actions	1 year
Process Executed	Process ID, tasks, outcomes	1 year
Escalation	Case ID, escalation reason, recipient	3 years

Operational Retention

Category	Retention Period	Data Types
Active Case Data	Duration + 1 year	Analysis records, decisions
Closed Cases	3 years minimum	Complete case files
Audit Records	3 years	All system activity
Rule Changes	Indefinite	Rule versions and history

Reporting and Analytics

Operations Dashboards

Dashboard	Purpose	Access
Case Queue	Active cases and assignments	All operations roles
Pattern Overview	Entity pattern distribution	Manager
SLA Monitoring	Task completion against targets	Manager
Screening Alerts	Pending screening matches	Analyst, Manager
Operations Dashboard	Management information metrics	Manager

Report Security

Control	Implementation
Role-Based Access	Reports filtered by user permissions
Data Aggregation	Individual data protected in summaries
Export Logging	All report exports logged
Scheduled Reports	Automated reports require authorization