A machine-readable control, evidence and architecture ontology for regulated AI, data and software systems. The navigation layer between regulation, controls, software architecture and audit evidence.
Apache-2.0 · Citation: ReguNav Compliance-to-Architecture Framework™ v0.1 (2026)
Most companies have legal teams reading regulations, compliance teams building spreadsheets, engineers building systems without knowing control intent, auditors asking for evidence, vendors producing random documents, and AI teams deploying models with weak governance.
These groups speak different vocabularies. The Compliance-to-Architecture Framework is the shared graph that lets each group ask the question they care about and get an answer the others can verify. The product would not just say "ISO maps to GDPR" — it would define the canonical control IDs, obligation IDs, evidence objects, policy-as-code controls, architecture requirements, audit-trail requirements, AI-governance requirements, and the cross-framework mappings that bind them.
Eight typed layers that combine into a single executable graph.
Each regulation, standard or contract that obligates someone is registered as an Authority with a precise version. PCI DSS v4.0.1 ≠ v3.2.1; EU AI Act applicable date ≠ in-force date. Versioning is mandatory.
eu-ai-act@2024-1689 · iso-42001@2023 · pci-dss@4.0.1Authority clauses are decomposed into canonical, framework-neutral Obligations. The same obligation can originate in multiple authorities — "periodic privileged access review" = ISO 27001 A.5.18 + SOC 2 CC6.3 + PCI DSS Req. 7.2.
OBL-PRIV-ACCESS-001 · OBL-AI-FRIA-001 · OBL-INC-72H-001Reusable Controls map to obligations and carry an explicit crosswalk array — the framework references they cover. Implement one control, see exactly which audit clauses are done.
CTRL-IAM-ACCESS-REVIEW-001 satisfies OBL-IAM-ACCESS-REVIEW-001 · crosswalk: ISO 27001 A.5.18, SOC 2 CC6.3, PCI DSS Req. 7.2, NIST CSF PR.AA-05Each control's runtime proof is an EvidenceObject with type, owner, source systems, frequency, retention and an optional JSON Schema for the artefact body.
EV-IAM-001 · type: access-review · owner: Security Admin · frequency: quarterly · retention: 6 yearsThe strongest differentiator. Each control declares concrete capabilities the system must have (RBAC/ABAC engine, immutable audit log, tenant-aware identity, approval workflow, evidence-export endpoint, drift detector). Ships with reference patterns per cloud.
ARCH-IAM-001 → capability: rbac-abac-policy-engine · pattern: Cerbos PEP at every API gatewayEach control points at one or more PolicyAsCode bundles — Cerbos, OPA, Cedar, Casbin policies enforcing the control at runtime. Bundles declare decision type and whether passing decisions emit evidence.
POL-IAM-PRIV-001 · engine: cerbos · decisionType: abac · evidenceRequired: trueEach control has a runtime AuditTrailLink: control owner, evidence owner, system owner, test frequency, last result, linked risks, linked policies, linked assets, linked vendors, linked AI systems.
controlId · owner · evidenceOwner · linkedAiSystemIds[]On top of layers 1-7, AI systems carry intended purpose, risk classification, ISO 42001 actor role, data lineage, bias-test results, oversight model, model monitoring, post-market monitoring cadence, model change log.
AiSystemGovernance · riskClassification: high-risk · roles: [provider, deployer]The framework is the trust asset. The engine that runs on it is the commercial product.
The framework follows SemVer. v0.1 ships an end-to-end seed across nine authorities; we'll publish v0.2 expanding authority by authority. PRs welcome at packages/ontology/src/seed.ts.