Spaces:
Runtime error
Runtime error
ARF Comprehensive Regulatory Alignment & Compliance Handbook
NIST AI RMF 1.0, EU AI Act, ISO/IEC 42001, SOC 2, GDPR, and More
Document Version: 2.0
ARF Version: v4.3.2
Date: July 8, 2026
Classification: Proprietary – Access‑Controlled
1. Introduction
The Agentic Reliability Framework (ARF) is a governance control plane for AI‑driven infrastructure operations. This document provides an exhaustive, auditable mapping between ARF's capabilities and the requirements of global regulatory frameworks applicable to high‑risk AI systems in critical infrastructure.
It is intended for:
- Design partners evaluating ARF for regulated deployments.
- Compliance officers preparing for certification audits.
- Independent auditors verifying the platform's claims.
- Regulators assessing the adequacy of ARF’s governance controls.
Every mapping includes a code reference, audit evidence location, and verification procedure so that claims can be tested without relying on vendor assertions.
2. Framework Overview
ARF addresses the following frameworks:
| Framework | Jurisdiction | Status | ARF Alignment |
|---|---|---|---|
| NIST AI RMF 1.0 | United States | Active (revision underway) | Full – Govern, Map, Measure, Manage |
| EU AI Act | European Union | In force | Full – Articles 9–16, Annex IV |
| ISO/IEC 42001:2023 | International | Published | Full – AI management system |
| SOC 2 (Trust Services Criteria) | International (AICPA) | Widely adopted | Security, Availability, Confidentiality |
| GDPR | European Union | In force | Data protection by design, right to explanation |
| NIST SP 800‑53 | United States | Active | Security and privacy controls |
| OWASP Top 10 for LLM Applications | International | Best practice | Prompt injection, supply chain |
3. Detailed Framework Mappings
3.1 NIST AI RMF 1.0
The NIST AI RMF is organized into four core functions: Govern, Map, Measure, and Manage. ARF addresses each function with specific technical controls.
3.1.1 Govern
| NIST Subcategory | ARF Capability | Code Reference | Audit Evidence | Verification Procedure |
|---|---|---|---|---|
| GOV‑1: Policies, processes, and procedures | Policy algebra (TLA⁺ verified); criticality parameter; pre‑built policy packs | policies.py (PolicyAlgebra), gates.rs (dynamic thresholds), policy_engine.py (healing policies), policy_packs/ |
Policy tree definitions stored in ConfigMap; every decision logs which policies were checked. | 1. Export the active policy tree from the ConfigMap. 2. Run TLC on PolicyAlgebra.tla to verify algebraic laws. 3. Verify that 100% of decisions in the audit log include policy violation lists. |
| GOV‑2: Roles, responsibilities, and delegated authority | Gateway RBAC via API key tiers; internal API key protects governance endpoints; human‑override fields in HealingIntent. |
auth/apikey.go (gateway), deps.py (verify_internal_key), healing_intent.py (human_overrides, approvals) |
Gateway access logs show per‑key requests; audit log entries record approver identity for overridden decisions. | 1. Attempt to call the API directly without X‑Internal‑Key; confirm 401. 2. Call the API with a read‑only tier key; confirm that outcome recording fails. 3. Inspect the audit log for any decision with status=approved_with_overrides and verify the approved_by field is populated. |
| GOV‑4: AI risk management integration with organizational risk | Bayesian risk scores feed into CVaR loss minimization; stability and drift flags provide continuous risk signals. | risk_engine.py, governance_loop.py (CVaR, stability, drift) |
Every HealingIntent carries a risk score, epistemic breakdown, and stability/drift metadata. |
1. Query the audit log for any decision where risk_score > 0.8 and verify that the action was DENY or ESCALATE. 2. Verify that lyapunov_stable and temporal_drift_detected are present in every HealingIntent.metadata. |
| GOV‑5: Continuous improvement | Conjugate Beta updates, online recalibration, memory‑weight optimization, and causal effect re‑estimation after every outcome. | risk_engine.py (update_outcome, _maybe_recalibrate), memory_weight_optimizer.py, causal_effect_estimator.py |
Outcome log shows feedback loop; recalibration events are logged. | 1. Record a sequence of outcomes; verify that the conjugate α and β values change as expected. 2. Verify that after 100 outcomes, the risk_engine recalibrates if ECE exceeds 0.1. |
3.1.2 Map
| NIST Subcategory | ARF Capability | Code Reference | Audit Evidence | Verification Procedure |
|---|---|---|---|---|
| MAP‑1: Context and intended use | InfrastructureIntent carries provenance, environment, requester identity; context_hash cryptographically binds all inputs. |
intents.py (InfrastructureIntent), healing_intent.py (context_hash), governance_loop.py (context extraction) |
HealingIntent.context_hash is a SHA‑256 of the canonical context; auditor can recompute and verify. |
1. For any decision in the audit log, retrieve the stored context and recompute SHA‑256(canonical_json(context)). 2. Assert equality with the stored context_hash. |
| MAP‑2: AI system categorization | RiskEngine categorizes every intent into action categories (database, network, compute, security) with category‑specific priors. |
risk_engine.py (categorize_intent, PRIORS) |
The risk_score explanation string includes the category; audit log records the category. |
1. Submit intents of each type (ProvisionResource, GrantAccess, DeployConfiguration). 2. Verify that the risk explanation string contains the correct category. |
| MAP‑3: AI capabilities, limitations, and appropriate use | Skill registry tracks per‑skill reliability; skill gate blocks unreliable skills; counterfactual explanations describe limitations. | skill_registry.py, gates.rs (SkillGate), causal_effect_estimator.py (generate_counterfactual) |
Skill alpha/beta values are logged; counterfactual text is included in every HealingIntent. |
1. Register a new skill with no history. 2. Submit an intent with that skill; verify that the SkillGate blocks it (P(θ>0.5) < 0.95). 3. Submit an intent with a well‑established skill (α=20, β=3); verify that the SkillGate passes. |
| MAP‑4: Risk mapping to AI system lifecycle | Time‑decayed risk and temporal drift detection monitor risk evolution over time. | governance_loop.py (time‑decayed risk, temporal drift), temporal_reliability.py |
HealingIntent.metadata.decayed_risk, .temporal_drift_detected |
1. Run 100 decisions with a fixed risk score; verify that decayed_risk converges to the input risk. 2. Inject a sudden risk spike; verify that temporal_drift_detected becomes True within the CUSUM threshold. |
3.1.3 Measure
| NIST Subcategory | ARF Capability | Code Reference | Audit Evidence | Verification Procedure |
|---|---|---|---|---|
| MEASURE‑1: Risk measurement methodologies | Bayesian risk fusion (conjugate + hyperprior + HMC), CVaR, epistemic uncertainty decomposition (CUDL Shapley values). | risk_engine.py (calculate_risk), governance_loop.py (CVaR, epistemic), research/cudl/ |
HealingIntent contains risk score, epistemic breakdown, and Shapley attribution. |
1. Submit an intent with known risk factors; verify that risk_factors sum to the risk_score. 2. Enable epistemic probing; verify that epistemic_breakdown contains hallucination, forecast, and sparsity components. |
| MEASURE‑2: Evaluation of trustworthiness characteristics | Lyapunov stability monitoring, CUSUM drift detection, Expected Calibration Error (ECE) recalibration, E‑value sensitivity analysis. | stability_controller.py, temporal_reliability.py, risk_engine.py (ECE), causal_effect_estimator.py (E‑value) |
HealingIntent.metadata.lyapunov_stable, .temporal_drift_detected; E‑values reported with ATE estimates. |
1. Run two consecutive decisions with increasing risk; verify that lyapunov_stable becomes False. 2. Compute the E‑value for a known ATE; verify that it matches the formula RR + sqrt(RR(RR‑1)). |
| MEASURE‑3: Mechanisms for tracking and responding to emergent risks | Passive Lyapunov check triggers active stability override; CUSUM drift triggers recalibration; skill gate blocks unproven skills. | governance_loop.py (active stability response), gates.rs (StabilityGate, SkillGate) |
Gate failure reasons are logged; stability override events are recorded. | 1. Artificially destabilize the Lyapunov monitor by alternating risk/psi; verify that the active stability response overrides the decision to ESCALATE. 2. Inject a skill with α=3, β=3; verify that the SkillGate fails with a message containing "Bayesian confidence low". |
3.1.4 Manage
| NIST Subcategory | ARF Capability | Code Reference | Audit Evidence | Verification Procedure |
|---|---|---|---|---|
| MANAGE‑1: Risk treatment strategies | Three‑action decision (approve, deny, escalate) based on posterior expected loss minimization; human‑in‑the‑loop overrides. | governance_loop.py (decision rule), healing_intent.py (human_overrides) |
HealingIntent.action and .status fields; audit log records the final decision and any overrides. |
1. Submit an intent with policy violations; verify action is DENY. 2. Submit an intent with high epistemic uncertainty; verify action is ESCALATE. 3. Submit an intent with low risk and no violations; verify action is APPROVE. |
| MANAGE‑2: Documentation and reporting | Immutable, hash‑chained audit log; every decision carries full trace (risk score, justification, counterfactual, metadata). | routes_governance.py (write_audit_log), models_intents.py (DecisionAuditLogDB) |
The decision_audit_log table is queryable by tenant and timestamp; hashes are cryptographically verifiable. |
1. Query the audit log for a specific tenant and date range; verify that all decisions are present and ordered. 2. Select two consecutive entries; verify that the hash chain is intact. |
| MANAGE‑3: Stakeholder communication | Plain‑language justification; counterfactual explanation; advisory‑only status for OSS edition. | healing_intent.py (justification, metadata.counterfactual) |
Every decision response includes a human‑readable explanation. | 1. Call the /intents/evaluate endpoint; verify that the response includes a justification field with a plain‑language explanation. 2. Verify that when a causal model is available, the response includes a counterfactual field. |
| MANAGE‑4: Post‑deployment monitoring | Outcome feedback loop updates conjugate posteriors, memory weights, and causal estimates; usage tracker provides quota visibility. | outcome_service.py, risk_engine.py (update_outcome), usage_tracker.py |
Outcome log shows feedback events; usage tracker shows remaining quota. | 1. Record an outcome via the /intents/outcome endpoint; verify that the risk engine's conjugate parameters have changed. 2. Call the /auth/info endpoint via the gateway; verify that remaining decreases after each evaluation. |
3.2 EU AI Act
ARF is designed to govern AI‑driven infrastructure actions, which may be classified as high‑risk under the EU AI Act when they affect critical infrastructure.
| Article | Requirement | ARF Capability | Code Reference | Audit Evidence | Verification Procedure |
|---|---|---|---|---|---|
| Art. 9 | Risk management system | CVaR expected loss minimization; StabilityGate blocks when platform is unstable; temporal drift triggers recalibration. | governance_loop.py (CVaR, stability), gates.rs (StabilityGate), risk_engine.py (recalibration) |
Every HealingIntent contains risk score, CVaR usage flag, stability sample, and drift metadata. |
Same as NIST Measure‑1/Measure‑3. |
| Art. 10 | Data governance and data quality | context_hash cryptographically binds decisions to input data; provenance field in intent tracks data origin. |
healing_intent.py (context_hash), intents.py (provenance) |
Auditor can recompute context_hash from stored context; provenance chain is logged. |
Same as NIST Map‑1. |
| Art. 11 | Technical documentation | Immutable audit log; HealingIntent carries full decision trace including pre‑/post‑memory risk, epistemic breakdown, counterfactual. |
models_intents.py (DecisionAuditLogDB), healing_intent.py (to_enterprise_request) |
Audit log table is queryable; each entry contains the complete decision payload. | Same as NIST Manage‑2. |
| Art. 12 | Record‑keeping | Every decision logged with timestamp, tenant, risk score, action, justification; logs are hash‑chained and Ed25519‑signed. | routes_governance.py (write_audit_log), crypto.py (Ed25519 signing) |
Hash chain integrity can be verified without trusting the runtime; signatures are base64‑encoded Ed25519. | 1. Export the audit log. 2. For each entry, verify the Ed25519 signature using the stored public key. 3. Verify that `SHA‑256(entry_n |
| Art. 13 | Transparency and provision of information | Plain‑language justification; counterfactual explanation; memory‑based evidence summary. | healing_intent.py (justification, metadata.counterfactual) |
Every API response includes justification and counterfactual fields. |
Same as NIST Manage‑3. |
| Art. 14 | Human oversight | Escalate action; human override fields; approval tracking; gateway RBAC for human reviewers. | governance_loop.py (decision rule), healing_intent.py (with_human_approval), auth/apikey.go |
HealingIntent.approvals records reviewer identity and timestamp; gateway enforces role‑based access. |
Same as NIST Govern‑2. |
| Art. 15 | Accuracy, robustness, and cybersecurity | Deterministic RNG (SHA‑256 seeded), cryptographic signatures, constant‑time API key comparison, internal API key protection. | governance_loop.py (deterministic RNG), crypto.py (signatures), deps.py (constant‑time compare) |
All probabilistic operations are reproducible; tampering with signed intents is detected. | 1. Run the governance loop twice with the same input; verify identical output. 2. Modify one field of a signed HealingIntent; verify that verify() returns False. |
| Art. 16 | Reporting obligations | Usage tracker and audit log provide quota consumption and decision history; Wilson monitor tracks Rust enforcer agreement. | usage_tracker.py, models_intents.py, wilson_monitor.py |
Usage and audit logs are queryable; Wilson confidence interval is updated every 5 minutes. | 1. Query the usage log for a given API key; verify that monthly counts match the quota. 2. Verify that the Wilson monitor emits a Prometheus metric with the current confidence interval. |
3.3 ISO/IEC 42001:2023 – AI Management System
ISO/IEC 42001 provides a certifiable framework for an AI management system. ARF can serve as the technical enforcement layer for the controls required by this standard.
| Clause | Requirement | ARF Capability | Code Reference |
|---|---|---|---|
| 4.1 | Understanding the organization and its context | InfrastructureIntent captures operational context; context_hash binds it to decisions. |
intents.py, healing_intent.py |
| 5.1 | Leadership and commitment | Criticality parameter allows leadership to set risk appetite. | infrastructure_intents.py (criticality) |
| 6.1 | Actions to address risks and opportunities | Full Bayesian risk pipeline, CVaR, stability monitoring. | risk_engine.py, governance_loop.py |
| 7.5 | Documented information | Immutable, hash‑chained audit log. | models_intents.py, routes_governance.py |
| 8.1 | Operational planning and control | Policy engine enforces rules; gates block unsafe actions. | policies.py, gates.rs |
| 9.1 | Monitoring, measurement, analysis, and evaluation | Epistemic uncertainty, Shapley decomposition, ECE recalibration, Lyapunov stability, CUSUM drift. | governance_loop.py, stability_controller.py, temporal_reliability.py |
| 10.1 | Continual improvement | Conjugate updates, memory weight optimization, causal re‑estimation. | risk_engine.py, memory_weight_optimizer.py, causal_effect_estimator.py |
3.4 SOC 2 (Trust Services Criteria)
SOC 2 evaluates the security, availability, processing integrity, confidentiality, and privacy of a system.
| Trust Service Criterion | ARF Capability | Code Reference |
|---|---|---|
| Security (CC6.1, CC6.6) | Internal API key authentication, constant‑time comparison, gateway salted SHA‑256 hashing, RBAC. | deps.py (verify_internal_key), auth/apikey.go |
| Availability (A1.1, A1.2) | Kubernetes HPA (3–10 replicas), liveness/readiness probes, rolling updates. | deploy/kubernetes/arf‑api/hpa.yaml, deployment.yaml |
| Confidentiality (C1.1) | NetworkPolicy restricts API to gateway only; CORS restricted to specific origin. | networkpolicy.yaml, main.py (CORS) |
| Processing Integrity (PI1.2, PI1.3) | Deterministic policy evaluation, TLA⁺ verified algebra, property‑based testing. | PolicyAlgebra.tla, test_policy_properties.py, proptest_policy.rs |
| Privacy (P1.1, P4.1) | Tenant isolation in risk engine; API keys scoped to tenants; usage data retained per retention policy. | risk_engine.py (tenant isolation), usage_tracker.py (retention) |
3.5 GDPR (General Data Protection Regulation)
For deployments processing personal data, ARF provides the following controls:
| GDPR Article | Requirement | ARF Capability |
|---|---|---|
| Art. 5(1)(f) | Integrity and confidentiality | Cryptographic signatures, hash‑chained audit log, constant‑time API key verification. |
| Art. 25 | Data protection by design | context_hash minimizes the need to store raw personal data; only hashes are retained. |
| Art. 30 | Records of processing activities | Audit log provides a complete record of all decisions, including requester identity and justification. |
| Art. 35 | Data protection impact assessment | Risk scores, epistemic uncertainty, and counterfactuals provide evidence for DPIAs. |
| Art. 22 | Automated individual decision‑making | Human‑in‑the‑loop override ensures that no solely automated decision is made without review capability. |
4. Cross‑Framework Alignment Matrix
| Requirement Category | NIST AI RMF | EU AI Act | ISO 42001 | SOC 2 | GDPR | ARF Feature(s) |
|---|---|---|---|---|---|---|
| Risk identification and quantification | Measure‑1, Measure‑2 | Art. 9 | 6.1 | — | Art. 35 | Bayesian risk fusion, CVaR, epistemic uncertainty, E‑value |
| Policy enforcement and controls | Govern‑1, Manage‑1 | Art. 9, Art. 14 | 8.1 | PI1.2 | Art. 22 | Policy algebra, Rust gates, human override |
| Data provenance and quality | Map‑1 | Art. 10 | 4.1 | — | Art. 5(1)(f) | context_hash, InfrastructureIntent.provenance |
| Documentation and record‑keeping | Manage‑2 | Art. 11, Art. 12 | 7.5 | — | Art. 30 | Immutable audit log, Ed25519 signatures |
| Transparency and explainability | Map‑3, Manage‑3 | Art. 13 | — | — | Art. 22 | Plain‑language justification, counterfactuals |
| Continuous monitoring and improvement | Map‑4, Measure‑3, Govern‑5 | Art. 9, Art. 15 | 9.1, 10.1 | — | — | Conjugate updates, stability/drift detection, recalibration |
| Human oversight | Govern‑2, Manage‑1 | Art. 14 | — | — | Art. 22 | Escalate action, human approval workflow, RBAC |
| Security and access control | — | Art. 15 | — | CC6.1, CC6.6, C1.1 | Art. 5(1)(f) | Internal API key, gateway auth, NetworkPolicy, CORS |
| Availability and resilience | — | — | — | A1.1, A1.2 | — | Kubernetes HPA, liveness/readiness probes, rolling updates |
| Privacy | — | — | — | P1.1, P4.1 | Art. 25 | Tenant isolation, API key scoping, usage retention |
5. Evidence Collection & Audit Procedure
5.1 Automated Evidence Collection
ARF provides the following automated evidence sources:
- Audit log (PostgreSQL): The
decision_audit_logtable contains every governance decision with timestamp, tenant, risk score, action, justification, and cryptographic hashes. - Prometheus metrics:
arf_evaluations_total,arf_rust_agreement_total,arf_evaluation_duration_secondsprovide real‑time observability. - OpenTelemetry traces: Every request is traced with a unique
trace_id, linking gateway logs to API decisions. - Usage tracker (SQLite/PostgreSQL): Provides per‑API‑key quota consumption and audit logs.
5.2 Independent Auditor Verification Checklist
| Step | Procedure | Expected Outcome |
|---|---|---|
| 1. Deterministic replay | Run GovernanceLoop.run() twice with identical inputs. |
SHA‑256 of serialized HealingIntent is identical. |
| 2. Hash chain integrity | Query decision_audit_log ordered by timestamp; verify that each hash links to the previous entry. |
No broken chains. |
| 3. Signature verification | For any signed intent, verify the Ed25519 signature using the stored public key fingerprint. | Signature verification returns True. |
| 4. Tamper detection | Modify one field of a signed HealingIntent and call verify(). |
verify() returns False. |
| 5. Policy algebra | Run TLC on PolicyAlgebra.tla. |
All invariants hold. |
| 6. Cross‑language policy equivalence | Generate random policy trees and evaluate in both Python and Rust; compare violation sets. | Identical violation sets. |
| 7. Bayesian update correctness | Record a sequence of outcomes; manually compute expected α, β. | BetaStore matches manual computation. |
| 8. Skill gate | Submit intents with varying skill evidence; verify gate behavior. | Low‑evidence skills fail; high‑evidence skills pass. |
| 9. Criticality‑aware gates | Submit intents with criticality=1.0; verify that tolerance is zero and confidence threshold is 1.0. | High‑criticality actions are blocked unless perfect. |
| 10. Context hash verification | Retrieve stored context for any decision; recompute SHA‑256. | Matches stored context_hash. |
6. Continuous Compliance Monitoring
ARF includes built‑in mechanisms for ongoing compliance verification:
- Wilson confidence interval monitor: Every 5 minutes, the Wilson updater checks the Rust enforcer agreement and adjusts the canary promotion status. This provides a statistical control chart for policy enforcement consistency.
- Expected Calibration Error (ECE): Monitored per tenant and category; triggers recalibration when exceeding 0.1.
- Lyapunov stability window: The StabilityGate blocks execution when the recent stability record is poor, preventing the platform from operating in a degraded state.
- Temporal drift detection: CUSUM tracks sustained drift in risk estimates; alerts when the model becomes stale.
7. References
- NIST AI RMF 1.0:
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf - EU AI Act:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0206 - ISO/IEC 42001:2023:
https://www.iso.org/standard/81230.html - SOC 2 Trust Services Criteria:
https://www.aicpa.org/soc2 - GDPR:
https://gdpr-info.eu/ - ARF Mathematical Work Journal:
docs/math_journal.md - ARF Policy Algebra TLA⁺ Specification:
agentic_reliability_framework/spec/tla/PolicyAlgebra.tla - ARF Pressure Test Suite:
tests/pressure/test_pressure.py
This document is proprietary and access‑controlled. Distribution is limited to qualified pilots and enterprise customers under written agreement.