Skip to main content

ADR-0177: Navin Enterprise Compliance & Audit Agent, transverse core and banking pack on top of the Control Plane

  • Status: proposed on 2026-11-04, recommended options to be confirmed by the user (see "Points to be validated by the user")
  • Date: 2026-11-04
  • Scope: new project navin-enterprise-compliance/ (FastAPI backend, workers, Next.js 16 frontend, Navin integration), additive extensions of the Control Plane (services/control-plane, new compliance domain modelled on rag_agent), OpenFGA model (deploy/policies/openfga/model.fga, additive types), Enterprise portal (activation journey), Navin Manager service descriptor and agent template prepared but not published
  • Related documents: ADR-0101 (licence policy), ADR-0103 (vLLM and LiteLLM), ADR-0108 (Opik), ADR-0166 (ClamAV and YARA-X scanning), ADR-0171 (hardened installation), ADR-0173 (separation of the Manager and Enterprise), ADR-0174 (Mem0 and Cognee memory), ADR-0175 (Navin Enterprise RAG Agent, model of a product layer), audit navin-enterprise-compliance/docs/en/NAVIN_INTEGRATION_AUDIT.md, diagram docs/architecture/diagrams/compliance-audit-agent.html

Context​

Two master prompts describe one product: the Navin Enterprise Compliance & Audit Agent (transverse: banking, insurance, industry) and its specialisation Navin Enterprise Banking Internal Audit & Continuous Control Agent, which must reuse the generic model (frameworks, risks and controls, audits, evidence, findings, CAPA, workflow, reporting) and add the banking modules (audit universe, risk and control matrix, permanent control, continuous control monitoring, engagements and workpapers, sampling, banking connectors, audit committee reporting).

The audit of 2026-11-04 shows that:

  • the platform already provides identity, roles, hierarchy, OpenFGA and OPA, the agent runtime (runs, approvals, SSE), governed tools and MCP, the RAG (knowledge, V206 and V207), memory (ADR-0174), mandatory file scanning (file_security), object storage with object lock for the evidence purpose (storage, PURPOSE_NEEDS), Presidio, SPIFFE, Docling, chained audit, quotas and budgets, and a complete model of a product lifecycle (rag_agent, V208 and V209);
  • no transverse compliance core exists: no framework and obligation register, no business risk and control register, no management of audits, probative evidence, findings or CAPA, no PDF, DOCX or XLSX report engine, no GRC or banking connector;
  • the RAG Agent (ADR-0175) has solved the transverse problems of a product application on the Control Plane (Keycloak BFF, authorization, RLS, durable jobs, SSE, citations, lifecycle, branding, observability);
  • an untested embryo of a cancelled attempt contains deterministic engines (rules, sampling, severity, segregation of duties, state machines) and policies whose design is sound but whose schema is banking-only.

Decision​

1. Two planes, one governance​

WhoDoes what
Navin Managerinstalls and operates the product runtime (service navin-compliance-agent: API, workers, web), its dependencies, TLS, health, backups, updates and rollback
Control Planetenants, projects, roles, models, knowledge bases, memory, file scanning, storage and object lock, quotas, audit, policies, traces, instance lifecycle through the compliance domain
Product backendbusiness layer: frameworks, obligations, risks, controls, campaigns, tests, samples, evidence, findings, CAPA, reports, alerts, copilot; it calls the Control Plane only through the Python SDK enterprise_ai

The backend never calls Qdrant, Cognee, LiteLLM, Docling, ClamAV or YARA-X directly. It owns only its PostgreSQL schema and its Redis namespace.

2. A generic core and business packs, one code base​

  • Package navin_compliance: transverse core (frameworks, obligations, mapping, risks, controls, audits, tests, sampling, evidence, findings, CAPA, continuous monitoring, reports, copilot, workflows).
  • Package navin_compliance_banking: banking pack (audit universe, versioned risk and control matrix, first and second line permanent control, engagements and workpapers, read-only banking connectors, catalogue of configurable banking controls, KYC and suspicious activity report roles and policies, audit committee reporting). The insurance and industry packs follow the same contract.
  • A pack only adds libraries (frameworks, risks, controls, templates, checklists, classification rules, reports, indicators), additive migrations in an extension schema (compliance_banking) and policies; it never modifies the core. Packs are customisable without changing the code.
  • Delivery order: core first, banking pack next; the pack remains independently deployable by embedding the core.

3. Deterministic engines independent of the LLM​

  • Continuous control rules (kinds row_condition, field_equality, conflict_pairs, reconciliation, aging, limit_check, recency), evaluated on frozen snapshots with data contract, freshness and minimum population; an unavailable or stale source gives not_evaluated, never passed.
  • Reproducible sampling (order by SHA-256 of seed and key, no library random function), methods random, systematic, stratified, risk_based, exhaustive, judgmental; no statistical assurance claimed; only the exhaustive method may state that the whole population was tested.
  • Finding severity from the organisation's approved matrix (likelihood x impact, version and approver), otherwise not_rated; never from a model.
  • Declarative state machines: audit_plan, engagement, workpaper, finding, capa, report, evidence_request, rule_activation, framework_version, rcm_version; a state is never written directly, only through a declared transition with its roles, segregation-of-duties guards and justification.
  • The LLM proposes (drafts, root cause hypotheses, priorities, explanations); it never confirms the effectiveness of a control, never closes a CAPA, never signs a report and issues no regulatory conclusion.

4. Maker-checker and separation of functions​

  • Every sensitive action (approval of a plan, a workpaper, a finding, a report, closure of a CAPA, activation of a rule, publication of a framework version, export of evidence) requires distinct author and approver; guards not_author, not_reviewer, not_submitter and cooling-off period, named denials by OPA (self_approval_forbidden, human_decision_required, capa_not_verified, capa_owner_cannot_close, control_result_immutable, rule_not_active).
  • Permanent control (first and second line) and internal audit (third line) have distinct spaces, roles, workflows and rights: an auditor never modifies the initial result of a control, a controller never audits themself.
  • Agent runtime approvals (approvals) cover AI executions; business approvals live in the product schema; both are correlated in the audit by trace_id.

5. Evidence chain of custody​

  • Every uploaded evidence item goes through file_security (ClamAV, YARA-X, quarantine, fail-closed) then through the storage domain with the evidence purpose (SeaweedFS object lock in compliance mode, digest, integrity); extraction by Docling through the Control Plane; pseudonymisation by Presidio when the policy requires it.
  • Evidence is never modified: new version or separate annotation; integrity and access events journaled append-only; legal hold; export bundle with inventory and digests; no export of third-party data beyond rights.
  • Missing evidence gives incomplete or unverifiable, never a proven non-conformity.

6. Framework engine and applicability​

  • Versioned catalogue of frameworks, policies, procedures, requirements and obligations, with jurisdiction, sector, activity, entity, effective period and validation status; import of versions, comparison, impact analysis on controls, human review before publication.
  • Applicability is decided per jurisdiction and per entity by an authorised compliance function; no foreign regulation is loaded as mandatory by default; without validation: Applicability not verified.
  • No automatic regulatory declaration to a supervisor; no unlicensed private standard redistributed in full text.

7. Product data​

  • compliance schema in the catalogue PostgreSQL (dedicated database, least-privilege role), asynchronous SQLAlchemy 2, asyncpg and Alembic; the Control Plane keeps its V*.sql migrations.
  • Table families: instances and settings; frameworks, versions, obligations and links; auditable entities, processes, risks, assessments; controls, versions, owners, schedules, runs, exceptions; audit plans, engagements, programs, workpapers and reviews; sampling populations, plans and selections; evidence requests and items, versions, links, integrity and access events; findings, versions, management responses; CAPA actions, evidence and effectiveness tests; approval workflows and decisions; reports, versions and approvals; continuous monitoring rules, runs and alerts; sources and refreshes; conversations and execution references; audit references, retention and legal holds; jobs and outbox.
  • RLS on every tenant-scoped table, context set per transaction, append-only journals protected by trigger; durable jobs FOR UPDATE SKIP LOCKED; Redis only for ephemeral data.

8. Lifecycle through a compliance domain of the Control Plane​

  • New domain services/control-plane/src/eai/domains/compliance, adapted copy of rag_agent: instances, states draft, validating, provisioning, starting, ready, degraded, failed, stopping, stopped, updating, deleting, deleted, traced idempotent steps, branding (logo scanned by file_security), infrastructure delegation to the Manager through platform_manager, /v1/compliance router, additive migrations.
  • Each instance is a governed application and a registry agent; the activation journey lives in the Enterprise portal.
  • compliance resource added to the enterprise_ai SDK.

9. Frontend, streaming and observability​

  • Same choices as ADR-0175: Next.js 16, React 19, MUI, OIDC BFF with httpOnly cookie and no token in the browser, sanitised Markdown, French, English and Arabic i18n; SSE resumable with Last-Event-ID; one trace per request from the BFF to LiteLLM; AI spans to Opik after removal of personal data; Prometheus compliance_* metrics with documented definitions; a compliance rate is displayed only when population and formula are defined.
  • Grafana, Loki and Tempo (AGPL-3.0, ADR-0101) are replaced by Prometheus, Alertmanager, Alloy, OpenSearch and OpenSearch Dashboards, Jaeger and Opik.

10. Service template and publication​

navin-compliance-agent.yaml descriptor conforming to navin-manager/catalog/schema/service.schema.json and agent template conforming to navin-manager/agent-templates/schema.json, validated on a temporary copy; nothing is published into navin-manager/ before the user's explicit validation.

11. Truth of capabilities​

No function declared done without a real test; no capability, SLA or HA announced without measurement; limits written in navin-enterprise-compliance/docs/KNOWN_LIMITATIONS.md.

Rejected alternatives​

  • Taking the embryo as is: banking-only schema, no test, security rewritten instead of the tested RAG bricks.
  • Two separate products (transverse and banking): second audit engine, diverging workflows.
  • Compliance engine inside the Control Plane itself: the Control Plane remains a platform, the business stays in the product; only the instance lifecycle enters it.
  • Letting the LLM rate severity or conclude on effectiveness: refused.
  • Direct calls to LiteLLM, Qdrant or Cognee; tokens in the browser; Redis as a persistent queue; immediate publication in the catalogue.

Consequences​

  • The core serves three sectors; the banking pack is delivered first and validates the pack contract.
  • An additive compliance domain in the Control Plane and two migration tools in the repository (Alembic for compliance, V*.sql for the Control Plane).
  • RAG bricks copied, then extracted into a common package at the third application.
  • Dependency on the storage object lock: without a declared capability, the evidence purpose is refused.

Points to be validated by the user​

  1. Replacement of Grafana, Loki and Tempo (AGPL-3.0) by the allowed catalogue components.
  2. Names and identifiers: folder navin-enterprise-compliance, package navin_compliance, API prefix /api/v1/compliance, banking pack navin_compliance_banking, service navin-compliance-agent, Control Plane compliance domain.
  3. Embryo takeover: deterministic engines, state machines, OPA policies and OpenFGA roles kept as specifications and rewritten with tests; schema and security layer not kept.
  4. Order: transverse core first, banking pack next.
  5. Publication of the descriptor and template only after explicit validation.

Delivery plan​

Work packages tracked on the project board: audit and architecture; backend foundations and compliance domain; frameworks and obligations; risks and controls; audits and workpapers; evidence and sampling; findings and CAPA; continuous monitoring; reports; copilot and sub-agents; frontend; governance and observability; banking pack; Navin provisioning; validation.