# Proving the AI Fiduciary: Regulatory Compliance, SR 11-7, and W3C PROV-O Auditability

**Author:** Principal Software Architect
**Date:** June 16, 2026
**Classification:** PUBLIC // ADAM ARCHITECTURE TEAM

## 1. Introduction

As artificial intelligence systems transition from advisory copilots to autonomous execution agents in institutional finance, the regulatory landscape is rapidly shifting. Regulatory frameworks such as the US Federal Reserve's SR 11-7 (Guidance on Model Risk Management) and the EU AI Act require that models—especially those determining credit risk, capital allocation, and trading execution—be explainable, auditable, and resilient.

The "black box" nature of Large Language Models (LLMs) fundamentally conflicts with these requirements. An agent that cannot explain *why* it denied a loan or *how* it arrived at a specific credit rating is a systemic regulatory risk.

This whitepaper details how the Adam Financial Operating System achieves institutional-grade Model Risk Management (MRM) and regulatory compliance by engineering W3C PROV-O lineage tracing, immutable event sourcing, and dynamic Capability Matrices natively into its architecture.

## 2. Regulatory Alignment: SR 11-7 and the EU AI Act

### 2.1 Overcoming the "Black Box"
SR 11-7 mandates robust model development, implementation, and validation. In traditional quant finance, this means documenting the math. In AI, this means documenting the *lineage of the logic*.

Adam achieves this by treating the LLM not as a model to be validated, but as a *reasoning orchestrator* whose outputs must be validated by deterministic systems. The Adam framework aligns with the EU AI Act's requirements for "High-Risk AI Systems" by ensuring Human-in-the-Loop (HITL) oversight, robust logging, and strict data governance.

## 3. The `ProvenanceHeader` and W3C PROV-O

To satisfy auditability requirements, every material decision generated by an agent must include an explicit **ProvenanceHeader**.

Adam leverages the **W3C PROV-O** (Provenance Ontology) standard. PROV-O provides a formalized schema for mapping entities, activities, and the agents responsible for them.

### 3.1 Decision Lineage
When an Adam agent generates an output (e.g., a `SNCAnalystAgent` generating a credit downgrade recommendation), the system logs the precise lineage of that decision:
*   **The Source Material:** The specific SEC filing, ticker data, or macro-economic indicator used as the factual grounding.
*   **The State Checkpoint:** The exact version of the Knowledge Graph and Temporal workflow state at the time of execution.
*   **The Logical Ruleset:** The specific `jsonLogic` version and hash that the PDIL Gatekeeper used to validate the action.
*   **The Model:** The specific LLM version, temperature, and prompt hash utilized.

This is exported via the `ProvJSONLDExporter` (`src/pdil/provenance/prov_jsonld_exporter.py`), translating internal execution graphs into standardized PROV-O JSON-LD elements. If an auditor asks, "Why was this asset downgraded?", the system can provide a deterministic, cryptographically hashed trail leading from the raw data source to the final API call.

## 4. The Capability Matrix and Authorization

Authorization boundaries in Adam are enforced via the **CapabilityEngine** (`src/pdil/authorization/capability_matrix.py`). This is a zero-trust architecture tailored for AI agents.

### 4.1 EU AI Act Risk Classes
`CapabilityRequest` schemas map specific actions (e.g., "Submit Trade", "Update Risk Rating") to EU AI Act Risk Classes.
*   **Minimal Risk:** An agent querying SEC data.
*   **High Risk:** An agent recommending a portfolio rebalance.

### 4.2 Dynamic Escalation and HITL
The engine uses a fail-closed, deny-by-default posture. It incorporates policy bundles, idempotency checks, and dynamically enforces Human-in-the-loop (HITL) approval requirements based on the Risk Class.

Furthermore, the `TrustManager` and `TelemetryLearningEngine` dynamically modulate an agent's authority. An agent gains "trust scores" based on the historical accuracy and successful validation of its outputs. If an agent consistently drifts or produces low-confidence outputs, the CapabilityEngine automatically revokes its write privileges to the ledger.

## 5. The Immutable Event Ledger

Adam abandons CRUD (Create, Read, Update, Delete) databases for its core state management, opting instead for Event Sourcing (`src/core/event_sourcing/ledger.py`).

### 5.1 Append-Only Audit Trails
Every system state change, from a parsed sentiment shift to a covenant stress-test result, is recorded as an immutable `FinancialEvent` on the `EventLedger`.

This guarantees that:
1.  **State is Reconstructable:** The entire financial system state at any exact millisecond in the past can be rebuilt by replaying the ledger.
2.  **Tamper-Evident:** By utilizing cryptographic hashing (e.g., deterministic message IDs via the `EventEnvelope`), the system prevents historical revisionism by compromised agents or malicious actors.

## 6. Conclusion

True institutional adoption of AI requires more than just powerful reasoning; it requires structural legitimacy. By embedding W3C PROV-O standards, strict Capability Matrices, and Immutable Event Sourcing directly into the architecture, Adam provides a verifiable, deterministic audit trail for every probabilistic inference. This approach transforms AI from an unpredictable black box into a fully transparent, regulatory-compliant fiduciary engine.