ICNLI Compliance & Regulatory Mapping¶
Every normative MUST in ICNLI v2.0 maps to specific requirements in the major AI governance frameworks. This page enumerates that mapping explicitly so compliance officers, government policy reviewers, and risk-management teams can audit ICNLI against the framework they operate under without reconstructing the mapping themselves.
ICNLI was first created on 30 December 2025 (v1.0.0). Current specification: v2.0 (May 2026).
How to read this page¶
ICNLI v2.0 is a vendor-authored open specification (see whitepaper §15 for the multi-vendor governance milestones, target dates, and the path to neutral foundation transfer). The mappings below show how the protocol's normative MUST clauses correspond to compliance obligations in each framework — they are not certifications. Until the conformance test suite ships (the v2.1 critical-path deliverable per specification §13.5), every compliance claim is self-attested. Reviewers MUST NOT treat self-attested mapping as equivalent to third-party verified mapping.
What this page is for: an evaluator from a compliance, audit, or regulatory function gets an enumerated correspondence between their framework's clauses and ICNLI's normative text. What this page is not: a substitute for legal review, security assessment, or formal certification under any of these frameworks.
1. NIST AI Risk Management Framework (NIST AI 100-1)¶
The NIST AI RMF defines four core functions for managing AI system risk: GOVERN, MAP, MEASURE, MANAGE. ICNLI provides normative requirements that support each function. The mapping below uses NIST AI RMF v1.0 (January 2023) and the AI RMF Playbook subcategories.
GOVERN — Policies, processes, procedures¶
| NIST AI RMF subcategory | ICNLI normative support |
|---|---|
| GOVERN 1.1 — Legal and regulatory requirements documented | §13 Conformance Levels, §15 Open Standard Strategy, §13.5 self-declared conformance disclosure |
| GOVERN 1.4 — Risk management practices integrated | §3 Core Principles, §7.7 Scope of Guarantee |
| GOVERN 4.1 — Accountability structures established | §12.4 Audit Trail, §12.5 Audit chain tamper-evidence |
| GOVERN 6.1 — Third-party risk practices | §9 Modular Extension Contract — manifest validation before registration |
MAP — Context and categorization¶
| NIST AI RMF subcategory | ICNLI normative support |
|---|---|
| MAP 1.1 — Context established | §4 Context Model (9 levels, L0–L8), §4.1.1 Why nine levels with domain mappings |
| MAP 1.6 — System purpose documented | §1.1 Purpose, §3.8 Domain Agnosticism |
| MAP 2.3 — Scientific integrity and TEVV considerations | §7.7 Scope of Guarantee distinguishing structural vs contractual layers |
| MAP 5.1 — Likelihood and magnitude of impact characterized | §8.3 Impact Analysis — mandatory L2+, enumerates direct + cascade + reversibility |
MEASURE — Identifying, analyzing, monitoring risks¶
| NIST AI RMF subcategory | ICNLI normative support |
|---|---|
| MEASURE 1.1 — Approaches and metrics identified | §12 Observability and Audit — three pillars (metrics + traces + logs) normative |
| MEASURE 2.1 — Test sets and metrics developed | §13.5 Current state — explicit disclosure that conformance test suite is v2.1 roadmap |
| MEASURE 2.7 — Privacy risks measured | §7.5 PII Masking Gate, §14.4 Data Protection |
| MEASURE 3.2 — Risk tracking approaches | §13.5 What we measure — published operational metrics with explicit gaps |
MANAGE — Risk responses and monitoring¶
| NIST AI RMF subcategory | ICNLI normative support |
|---|---|
| MANAGE 1.1 — Plans documented for responding to mapped risks | §8 Safety Layer — TWO-STEP + L0–L4 classification + danger phrases |
| MANAGE 1.3 — Mechanisms to supersede, disengage, deactivate | §5.4 Confirmation Tokens — expiration, rejection, re-classification on new request |
| MANAGE 2.2 — Mechanisms to sustain value | §9.4 Extension Lifecycle — load/validate/register/dispatch/unload with audit at each stage |
| MANAGE 4.1 — Post-deployment monitoring | §12.6 Fail-Soft Telemetry — telemetry failure MUST NOT break request path |
| MANAGE 4.3 — Incident response process | §8.6 Classifier Dependency and Defense-in-Depth + audit substrate observation |
2. EU AI Act (Regulation 2024/1689)¶
The EU AI Act (in force from August 2024, with high-risk AI obligations applying from August 2026) establishes obligations for high-risk AI systems. ICNLI's normative requirements support compliance with several mandatory provisions.
| EU AI Act Article | Obligation | ICNLI normative support |
|---|---|---|
| Article 9 | Risk management system (continuous, iterative process) | §13 Conformance Levels + §15 Open Standard Strategy with milestones |
| Article 10 | Data and data governance | §7.5 PII Masking Gate + §14.4 Data Protection |
| Article 12 | Record-keeping (automatic logs over lifetime) | §12.3 Structured Logs + §12.4 Audit Trail tamper-evident hash chain |
| Article 13 | Transparency (clear and adequate information) | §5.3 TWO-STEP Confirmation — proposal with impact analysis before execution |
| Article 14 | Human oversight (effective, by natural persons) | §8 Safety Layer — every state-changing action requires explicit human confirmation; kernel gate is outside model's authority |
| Article 15 | Accuracy, robustness, cybersecurity | §7 Anti-Fabrication Contract + §14 Security Considerations |
| Article 17 | Quality management system | §9 Modular Extension Contract — manifest validation before registration, lifecycle audit |
| Article 26 | Use of high-risk AI systems by deployers | §8.5 Role-Based Safety — every dispatch role-checked, every authorization failure logged |
Specifically on Article 14 (Human oversight). The EU AI Act's human oversight requirement is the architectural core of ICNLI. The protocol's TWO-STEP gate is enforced by the kernel and is outside the model's authority — meaning the natural person (the authorizing principal) is structurally inserted between the AI's proposal and the system's execution for every consequential operation. This is the normative shape Article 14 envisions.
3. ISO/IEC 42001:2023 — AI Management Systems¶
ISO/IEC 42001:2023 establishes the international standard for AI management systems (AIMS). It is the first auditable management-system standard specifically for AI. ICNLI's normative clauses support several core control areas.
| ISO/IEC 42001 clause | Subject | ICNLI normative support |
|---|---|---|
| 5.2 | AI policy | §3 Core Principles — eight principles every compliant implementation MUST satisfy |
| 7.3 | Awareness | §4 Context Model — 9-level structured awareness mandatory |
| 8.2 | AI system impact assessment | §8.3 Impact Analysis — direct + cascade + reversibility + backup |
| 8.3 | AI system data (data quality, governance, traceability) | §7 Anti-Fabrication — fact ledger preserves verbatim tool output; audit chain traceability |
| 8.4 | AI system lifecycle (development, deployment, operation) | §9.4 Extension Lifecycle — load/validate/register/dispatch/unload normative stages |
| 9.1 | Performance evaluation, monitoring, measurement | §12 Observability + §13.5 What we measure |
| 9.2 | Internal audit | §12.5 Audit chain tamper-evidence — hash-chained, append-only, reconstructable |
| A.6 | AI system requirements specification | This specification (RFC2119 normative throughout) |
| A.9 | Use of AI systems by humans | §8 Safety Layer + TWO-STEP |
4. US Federal Deployment Readiness¶
For US federal deployment (FedRAMP, DoD IL2/IL4/IL5/IL6), ICNLI provides architectural support for several baseline requirements. Note: ICNLI is a specification, not a deployed product; FedRAMP-style authorization applies to specific implementations (e.g., imperal.io) operating in compliant cloud environments, not to the protocol itself.
| Federal control area | ICNLI architectural support |
|---|---|
| Encryption at rest and in transit | §14.4 Data Protection — MUST encrypt sensitive data at rest, MUST use TLS for transport |
| Audit log retention and tamper-evidence | §12.4 Audit Trail + §12.5 Hash-chain tamper-evidence at L2+ (SHA-256 or stronger, append-only persistence) |
| Air-gapped deployment for sensitive workloads | §14.4 Data Protection — MUST support on-premises deployment for domains that require it; implementation-neutral by design (no required cloud dependency) |
| Role-based access enforcement | §8.5 Role-Based Safety — every dispatch role-checked, every authorization failure logged |
| PII protection and data minimization | §7.5 PII Masking Gate — masking on by default, unmasking opt-in and audited |
| Defense-in-depth for adversarial misclassification | §8.6 Classifier Dependency and Defense-in-Depth — three-layer defense for probabilistic classifier output |
| Incident reconstruction from logs | §12 Observability — structured metrics, distributed traces, structured logs with trace_id correlation |
A FedRAMP authorization would be granted to a specific cloud deployment of an ICNLI-compliant implementation (e.g., imperal.io in a FedRAMP-authorized cloud environment), not to the specification. ICNLI's normative requirements provide architectural support for that authorization path; the specific authorization is the implementer's responsibility.
5. MITRE ATLAS — Adversarial AI Threat Model¶
MITRE ATLAS catalogs adversarial threats specific to AI systems. ICNLI's normative requirements address several tactics, techniques, and procedures (TTPs) directly.
| MITRE ATLAS tactic | TTP | ICNLI normative response |
|---|---|---|
| ML Model Access | T0040 Discover ML Model Family | §6.1 Intent Routing — model-vendor-neutral; routing decision is implementation-specific |
| Initial Access | T0049 Exploit Public-Facing Application | §14.1 Authentication — MUST authenticate before any request processing |
| ML Attack Staging | T0042 Verify Attack | §7.4 Intent-Routed Tool Selection — tools outside routed subset are structurally unreachable |
| Defense Evasion | T0015 Evade ML Model | §8.6 Classifier Dependency and Defense-in-Depth — confidence threshold + per-step classification + audit observability |
| Impact | T0048 External Harms | §8 Safety Layer — TWO-STEP confirmation before state-changing execution; kernel-enforced |
| Persistence | T0011 User Execution | §5.4 Confirmation Tokens — expiration, rejection of stale tokens, re-classification on new request |
| Discovery | T0050 Discover ML Artifacts | §7.5 PII Masking Gate — context masked before transmission to model |
| Resource Development | T0017 Develop Capabilities — Adversarial ML Attack | §9.2 Extension Manifest Schema — manifest validation, permission scoping, declared-capability boundaries |
6. What ICNLI does NOT cover¶
Honest scope disclosure — what a compliance officer still needs to source separately:
- Model-layer alignment, refusal training, and constitutional methods. These are the foundation-model provider's responsibility. ICNLI bounds outside the model layer; the brain inside is the model provider's contract.
- Application-layer business logic. Specific tools, specific data validation, specific business rules — these are extension responsibilities.
- Cloud infrastructure compliance (FedRAMP, SOC 2, ISO 27001). These authorize a specific deployment environment, not the protocol. ICNLI supports the architectural requirements; the cloud authorization is the implementer's path.
- Sector-specific regulatory frameworks (HIPAA, PCI DSS, GLBA, FERPA, GDPR data subject rights, etc.). ICNLI's PII masking and audit substrate support several of these, but sector-specific certification requires sector-specific evaluation.
- Quantitative measurement of hallucination rate against a ground-truth corpus. This is the v2.1 critical-path roadmap deliverable per whitepaper §13.5. Until it ships, hallucination rate is not a numeric ICNLI claim.
- Independent third-party benchmarks. No external benchmark is available because no third-party implementation exists yet. This is the v2.1+ open-standard milestone per whitepaper §15.
7. Engagement for compliance review¶
For formal evaluation, regulatory consultation, or partnership on standards mapping:
- Specification text: icnli.org/icnli-specification — the normative RFC2119 contract, CC BY-SA 4.0.
- Architectural rationale: icnli.org/icnli-whitepaper — design context for each normative MUST.
- Reference implementation: imperal.io — currently the only self-attested L3-conformant production deployment (self-attested per specification §13.5; conformance test suite is v2.1 critical-path roadmap).
- SDK for compliance-instrumented extensions: imperal-sdk on PyPI — typed contracts, kernel-level AST-scan validators.
- Trademark inquiries: license@icnli.org
- Standards-body engagement: the path to neutral foundation governance is documented in whitepaper §15 with explicit milestones — conformance test suite (v2.1), three or more independent compliant implementations (target end-2027), and trademark + specification transfer to a neutral foundation.
ICNLI's stated commitment is to multi-vendor open-standard status, not to vendor-perpetual ownership. Engagement from regulators, standards bodies, and foundation-affiliated working groups is explicitly invited; the open-standard milestones are written to converge with that engagement.
License¶
© 2026 Valentin Scerbacov / Imperal, Inc.
This page is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). You are free to share and adapt this material for any purpose, including commercial, under the terms of attribution and share-alike.
Full license: https://creativecommons.org/licenses/by-sa/4.0/
ICNLI™ is a trademark of Imperal, Inc. The CC BY-SA 4.0 license applies to the content of this page but does not grant rights to use the ICNLI trademark for branding or commercial purposes without written permission. NIST AI Risk Management Framework, EU AI Act, ISO/IEC 42001, FedRAMP, DoD IL designations, and MITRE ATLAS are referenced under nominative fair use; their respective marks and standards remain the property of NIST, the European Union, ISO/IEC, the US General Services Administration, the US Department of Defense, and The MITRE Corporation, respectively.
- Creator: Valentin Scerbacov
- Trademark Owner: Imperal, Inc.
- Website: icnli.org
- Trademark inquiries: license@icnli.org
- Flagship implementation: imperal.io
- Reference agent: Webbee
- First enterprise production deployment: WebHostMost