Architecture
Three-layer separation.
CCAI is organized into three architectural layers. Each has distinct responsibilities, separate data stores, and enforced boundaries.
CCAI Execution Layer
Data Plane
Processes entity data through the resolution waterfall. Handles ingestion, schema detection, entity type classification, normalization, L0–L4 layer execution, lineage tracking, and DecisionEventPackage assembly.
The data plane handles all entity-level computation. It reads configuration from the control plane but never modifies it.
Control Plane
Manages operational configuration and governance: tenancy, rule packs, auth, quotas, observability, incident control, config snapshots, and audit exports. The control plane constrains the data plane's behavior but does not execute screening logic.
Intelligent Analyst Verification Layer
The truth and attestation system. Architecturally separate from CCAI. Receives DecisionEventPackages, records decisions in an append-only truth ledger, binds VeracityReceipts with cryptographic hashes, and enables independent replay and verification.
IA does not influence screening decisions. CCAI does not modify IA records. The boundary is enforced at the system level, not by convention.
Modular Control Plane
The control plane is composed of independent modules, each with a single responsibility. Modules communicate through an internal event bus. No module directly imports another module's internals. Isolation is enforced by automated boundary checks in CI.
| Module | Responsibility |
|---|---|
| Tenancy | Tenant provisioning, suspension, deletion, isolation enforcement |
| Governance | Rule packs, threshold policies, model policies, approval chains |
| Auth | Users, service accounts, roles, permissions, ABAC scoping |
| Quota | Rate limits, batch limits, L3 budget enforcement |
| Observability | Metrics, traces, alerts, operational dashboards |
| Incident Control | Circuit breakers, kill switches, incident response |
| Config Snapshots | Immutable configuration versioning for reproducibility |
| Audit Exports | Regulatory report formatting, evidence bundle packaging |
| Metering | Usage event collection and billing signal generation |
| Monitoring | Re-screening orchestration and delta alert generation |
Developer and API Consumption
CCAI is consumed as infrastructure. REST API for single-entity resolution, batch submission, audit retrieval, and health monitoring. Web dashboard for operators managing screening workflows, case triage, and evidence export. Webhooks for event notifications.
The API is the primary integration surface. The dashboard is the operational interface. Both consume the same underlying engine.
Infrastructure Properties
| Property | Implementation |
|---|---|
| Multi-tenant isolation | Project-level, VPC-level, and row-level tenant separation |
| Regional data residency | EU and US deployments with enforced data locality |
| Encryption | Customer-managed encryption keys (CMEK) at rest, TLS in transit |
| Deployment | Container-based deployment on GCP Cloud Run |
| Observability | Structured logging, distributed tracing, metric collection |
| Incident response | Circuit breakers, kill switches, automated escalation |