SDOS Runtime Governance Framework — NIST AI RMF 1.0 (NIST AI 100-1)¶
Version: 1.10
Date: 2026-05-12
Authoring Organization: AAM Cyber (aamcyber.com)
Inventor: Pharns Genece
Change Log: View full version history
Key Facts¶
- What: Control catalog and reference document for the SDOS Runtime Governance Framework — Version 1.10, 24 controls across 9 governance domains.
- Who: AAM Cyber, authoring organization. Pharns Genece, inventor.
- NIST OLIR Status: OLIR Trifecta — all three Concept Crosswalks reached Final status with zero public comments: SDOS-RuntimeGov-to-AI-RMF-v1.0 (Reference ID 220, Final 2026-06-15), SDOS-RuntimeGov-to-CSF-2.0-v1.0 (Reference ID 215, Final 2026-06-22), and SDOS-RuntimeGov-to-SP-800-53-Rev-5.2.0-v1.0 (Reference ID 217, Final 2026-06-22).
- Architectural positioning: Dispatch-time enforcement layer below model alignment — SDOS produces identical governance outcomes regardless of whether the underlying AI model is well-aligned, misaligned, fine-tuned, or untrained.
- Framework library coverage: 17 framework alignments — NIST AI RMF 1.0, NIST CSF 2.0, NIST SP 800-53 Rev 5.2.0, NIST AI 600-1 (GenAI Profile), EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, SOC 2, NAIC MDL-668, NERC CIP, IEEE P2863 (draft), FAA UAS/AAM (principles-mapped).
- Relationship type (NIST OLIR): Supportive — SDOS provides structural enforcement at the AI agent dispatch layer that supports framework subcategory intent without claiming equivalence.
- Applicability: Autonomous and semi-agentic AI workflows where AI agents invoke tools, make decisions, or produce outputs on behalf of an operator. Not designed for static LLM-chat interfaces.
- Patent status: Aspects of SDOS are the subject of U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620.
Purpose¶
The Security Decision Operating System (SDOS) is a runtime governance framework that enforces structured policy controls over AI agent operations at the point of dispatch. It provides a structural layer of enforcement independent of the underlying model's internal alignment or safety tuning, binding AI model selection, tool invocation, outbound execution, and audit logging to verifiable governance rules.
This document catalogs the 24 governance controls that constitute the SDOS public runtime control set. Each control entry specifies the governance function served, a functional description of what the control does, the evidence type that demonstrates it, any applicable patent references, and the related controls it depends on or supports.
This document is intended for use by CISOs, GRC auditors, AI risk assessors, procurement reviewers, and standards bodies evaluating AI governance frameworks for alignment with recognized control catalogs. It does not describe implementation-level architecture, internal data structures, or operational parameters.
How to Use This Document¶
Control ID Schema¶
Control identifiers follow the pattern SDOS-[DOMAIN]-[NN], where:
SDOSidentifies the framework[DOMAIN]is the two-letter governance function code (see table below)[NN]is a zero-padded sequential number within that domain
| Code | Governance Function |
|---|---|
| GV | Governance |
| RM | Risk Management |
| EN | Enforcement |
| IA | Identity and Attestation |
| AU | Audit |
| IN | Integrity |
| DE | Deliberation |
| AD | Admission |
| RS | Risk Measurement |
IP Notice¶
Aspects of the SDOS Runtime Governance Framework are the subject of pending U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620. The scope of pending claims is defined by the as-filed specifications and is not coextensive with the descriptions in this control catalog. Per-control patent notices are omitted to avoid repetition.
Evidence Types¶
Each control entry lists one or more evidence types that demonstrate the control is implemented and operational:
- Audit Log Record — a structured log entry generated at runtime capturing the relevant governance event
- Configuration File — a versioned, human-readable policy configuration that governs control behavior
- Test Suite Result — a passing automated test that verifies the control's behavior under defined conditions
- Module Manifest — a cryptographically signed declaration of module identity and authorized capabilities
- System Behavior — an observable runtime response to a defined stimulus (e.g., halt on integrity failure, block on admission failure)
The evidence types above define the category of evidence. Specific field schemas, log formats, and configuration structures for each control are documented in the SDOS operational documentation available to licensed implementers.
Glossary of Key Terms¶
| Term | Definition |
|---|---|
| Point of Dispatch | The moment a task is assigned to an agent and before any tool execution occurs; the primary governance enforcement boundary |
| Governed Egress | The class of outbound operations subject to pre-execution policy enforcement |
| Model-Alignment-Independent | Enforcement that operates through structural separation from model inference, without reliance on the model's internal safety tuning or alignment claims |
| Admission | The explicit process by which an agent is granted access to governed operations; a precondition for runtime governance evaluation |
| Governance Baseline | The authorized configuration state against which SDOS verifies integrity at startup and on demand |
| Module Manifest | A cryptographically signed artifact that declares a module's identity and authorized capabilities |
| Deliberation Panel | A structured multi-agent evaluation process in which each participating agent operates within a policy-defined role |
| Structural Independence | The property by which policy evaluation occurs in a runtime layer that receives model outputs as data inputs but does not execute model-generated instructions as governance decisions. This layer operates independently of the model inference process. |
| Governance Decision | A policy evaluation performed by SDOS that produces a permit, modify, or block outcome for a given agent operation. Governance decisions are recorded in the audit trail and are distinct from model-generated recommendations or actions. |
Applicability¶
SDOS is applicable to autonomous and semi-autonomous agentic AI workflows in which AI agents invoke tools, make decisions, or produce outputs on behalf of an operator. It is not designed for static LLM-chat interfaces in which no tool invocation or autonomous action occurs.
Framework Alignment¶
Primary Focal Document — NIST AI Risk Management Framework 1.0¶
SDOS maps to the NIST AI Risk Management Framework (AI RMF) 1.0 (NIST AI 100-1, January 2023) as the primary focal document. The table below shows a representative sample of mappings across all four core functions. The complete mapping — 49 subcategories across GOVERN, MAP, MEASURE, and MANAGE — is available in the NIST OLIR Concept Crosswalk submission file.
NIST OLIR Catalog Inclusion. The mapping is cataloged with the NIST OLIR Program as SDOS-RuntimeGov-to-AI-RMF-v1.0 (Reference ID 220). Final informative reference as of 2026-06-15; public review concluded with zero comments.
Catalog link: csrc.nist.gov/projects/olir/informative-reference-catalog/details?referenceId=220
| AI RMF Function | Subcategory | SDOS Controls |
|---|---|---|
| GOVERN | GOVERN-1.1 — Policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks | SDOS-GV-01, SDOS-GV-03, SDOS-GV-05 |
| GOVERN | GOVERN-1.4 — Organizational teams are committed to a culture that considers and communicates AI risk | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03 |
| GOVERN | GOVERN-6.1 — Policies and procedures are in place for third-party and supply-chain AI risk | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03, SDOS-IA-02 |
| MAP | MAP-1.1 — Context is established for the AI risk assessment | SDOS-RM-01, SDOS-IA-01, SDOS-IA-02 |
| MEASURE | MEASURE-1.1 — Approaches and metrics for measurement of AI risks are selected for implementation | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03, SDOS-AU-01, SDOS-RS-01 |
| MEASURE | MEASURE-2.13 — Effectiveness of TEVV metrics and processes are evaluated and documented | SDOS-RS-01, SDOS-AU-02, SDOS-AU-03 |
| MEASURE | MEASURE-3.2 — Risk tracking approaches are considered for settings where AI risks are difficult to assess | SDOS-RM-01, SDOS-AU-01, SDOS-AU-02 |
| MANAGE | MANAGE-1.1 — A determination is made as to whether the AI system achieves its intended purpose and deployment should proceed | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03, SDOS-EN-03 |
| MANAGE | MANAGE-1.2 — Treatment of documented AI risks is prioritized based on impact, likelihood, or available resources | SDOS-RM-01, SDOS-RM-02, SDOS-RS-01 |
| MANAGE | MANAGE-2.4 — Mechanisms are in place to supersede, disengage, or deactivate AI systems demonstrating inconsistent outcomes | SDOS-EN-01, SDOS-EN-02, SDOS-EN-03, SDOS-AD-01 |
| MANAGE | MANAGE-3.1 — AI risks and benefits from third-party resources are regularly monitored and documented | SDOS-IA-02, SDOS-IN-03, SDOS-AU-02 |
| MANAGE | MANAGE-4.1 — Risk treatments are monitored and documented | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03 |
| MANAGE | MANAGE-4.3 — Incidents and errors are communicated and processes for recovery are followed | SDOS-AU-01, SDOS-AU-03, SDOS-EN-04 |
Secondary Alignment — ISO/IEC 42001:2023¶
The following cross-walk is provided as supplementary alignment and is informative only — it is not part of the NIST OLIR submission. ISO 42001 mapping is derived from production audit trail evidence.
| ISO 42001 Control | Title | SDOS Controls |
|---|---|---|
| A.2.2 | AI policy | SDOS-GV-01, SDOS-GV-03 |
| A.2.4 | Review of the AI policy | SDOS-GV-01, SDOS-IN-01 |
| A.3.2 | AI roles and responsibilities | SDOS-IA-01, SDOS-IA-02 |
| A.5.2 | AI system impact assessment process | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03 |
| A.6.2.4 | AI system verification and validation | SDOS-IN-01, SDOS-IN-02, SDOS-IN-03 |
| A.6.2.6 | AI system operation and monitoring | SDOS-GV-04, SDOS-DE-01, SDOS-DE-02 |
| A.6.2.8 | AI system recording of event logs | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03 |
| A.7.4 | Quality of data for AI systems | SDOS-DE-02 |
| A.9.2 | Processes for responsible use of AI systems | SDOS-EN-01, SDOS-EN-02, SDOS-EN-03, SDOS-AD-01 |
Control Catalog¶
SDOS-GV-01 — Configuration-Governed Module Activation¶
Governance Function: Governance
Description: SDOS controls which modules are active within the governance framework through a versioned policy configuration. The set of capabilities available to agents at any given time is determined by the current configuration state. Modules can be activated or deactivated without requiring changes to executable components. This ensures that the operational surface of the governance framework is auditable, reproducible, and change-controlled.
Evidence Type: Configuration File; Audit Log Record
Related Controls: SDOS-GV-04, SDOS-IA-02, SDOS-IN-01, SDOS-IN-03
SDOS-GV-02 — Governance-Tiered Model Selection¶
Governance Function: Governance
Description: SDOS determines which AI model tier is appropriate for a given task at the time of dispatch, based on the task's assessed characteristics. The governance framework — not the agent, the model, or the calling application — makes the model assignment. Agents cannot self-select a model or override the assigned tier. The selection rationale is recorded in the audit trail for every dispatched operation, creating a verifiable chain from task characteristics to model assignment to execution outcome.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-RM-01, SDOS-RM-02, SDOS-RM-03, SDOS-AU-01
SDOS-GV-03 — Default-Deny Pre-Admission Policy¶
Governance Function: Governance
Description: SDOS establishes a default-deny posture as a governance policy: no agent may access governed operations unless explicitly admitted. This control defines the admission policy that governs the criteria under which an agent may be admitted to the framework. It is the policy layer that SDOS-AD-01 enforces at runtime. The admission criteria, including any conditions, restrictions, or scope limitations, are specified in the governance configuration rather than in code, enabling policy updates independently of deployment changes. This control governs what the admission policy states — the criteria and conditions for access. SDOS-AD-01 governs how that policy is enforced at the execution boundary.
Evidence Type: Configuration File; System Behavior
Related Controls: SDOS-AD-01, SDOS-IA-01, SDOS-GV-01, SDOS-IN-01
SDOS-GV-04 — Cross-Module Governance Continuity¶
Governance Function: Governance
Description: A common governance authority and policy source governs all active modules within SDOS. The same authoritative policy source and decision process applies across modules regardless of which module handles a given task. This prevents governance fragmentation, where different modules might apply different rules, which would create exploitable inconsistencies in the enforcement surface.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-GV-01, SDOS-IA-02, SDOS-EN-02, SDOS-IN-01
SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement¶
Governance Function: Governance
Description: SDOS provides a structural layer of governance enforcement that operates independently of the underlying AI model's inference layer. SDOS provides no authorized mechanism by which a model's outputs or generated instructions can override, bypass, or modify the governance constraints applied to that model's operations. Policy is enforced by the governance layer based on verifiable system state, ensuring governance durability across model versions, providers, and alignment states.
Evidence Type: System Behavior; Test Suite Result
Related Controls: SDOS-EN-01, SDOS-EN-02, SDOS-IN-01, SDOS-GV-03
SDOS-RM-01 — Dispatch-Time Risk Classification¶
Governance Function: Risk Management
Description: Every tool invocation is classified by risk tier before any execution takes place. The classification occurs at the dispatch boundary and determines the governance outcome for that invocation: automatic permission, conditional permission, or block. Classification is performed by the governance layer at the time of dispatch, not pre-computed at configuration time, ensuring that the governance decision reflects the current policy state at the moment of execution.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-GV-02, SDOS-RM-02, SDOS-RM-03, SDOS-EN-01, SDOS-AU-01
SDOS-RM-02 — Complexity-Tiered Resource Allocation¶
Governance Function: Risk Management
Description: SDOS assesses the characteristics of each task at dispatch time to determine the minimum model capability tier required for adequate processing. The assessment considers factors including the scope of tool access, decision depth, and governance consequence of the operation. Tasks assessed as requiring higher capability cannot be routed to models below that tier, even if a lower-tier model would otherwise be available or preferred. This prevents governance decisions with high analytical consequence from being processed by models that lack sufficient capability.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-GV-02, SDOS-RM-01, SDOS-RM-03
SDOS-RM-03 — Risk-Floor Model Binding¶
Governance Function: Risk Management
Description: For tasks that fall within policy-defined elevated-risk categories, SDOS enforces a minimum model capability floor independent of the complexity assessment. Tasks in elevated-risk categories require a model meeting a minimum capability standard regardless of what the complexity assessment would otherwise permit. Risk-floor binding is a hard constraint enforced by the governance layer, not a preference or advisory.
Evidence Type: System Behavior; Test Suite Result
Related Controls: SDOS-GV-02, SDOS-RM-01, SDOS-RM-02
SDOS-EN-01 — Pre-Egress Policy Enforcement¶
Governance Function: Enforcement
Description: Governed outbound operations — including writes, external communications, tool dispatches, and data transfers — are required to pass through a policy enforcement point before execution. The enforcement point evaluates each operation against the current policy configuration and either permits, modifies, or blocks it. The enforcement evaluation is logged at the time it occurs, creating a record of every governance decision made at the egress boundary.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-EN-02, SDOS-EN-04, SDOS-GV-05, SDOS-AU-01, SDOS-RM-01
SDOS-EN-02 — Subordinate-Side Enforcement Gate¶
Governance Function: Enforcement
Description: Each module within SDOS confirms governance approval before executing its operation through a secondary module-level authorization check. This confirmation is in addition to the central governance evaluation and ensures that module-level execution does not proceed without a verified governance decision. This distributed confirmation architecture provides a redundant enforcement layer at the module boundary.
Evidence Type: System Behavior; Test Suite Result
Related Controls: SDOS-EN-01, SDOS-GV-04, SDOS-IA-02, SDOS-IN-03
SDOS-EN-03 — Fail-Closed Degradation¶
Governance Function: Enforcement
Description: When SDOS governance infrastructure is unavailable or in an indeterminate state, the system defaults to a restrictive operating posture. SDOS distinguishes two primary failure modes: (1) governance infrastructure unavailability, under which operations pre-authorized under the standing policy configuration may continue; and (2) governance baseline integrity failure, under which all operations halt without exception per SDOS-IN-02. Operations requiring active governance evaluation at elevated risk tiers are blocked in either failure mode until governance infrastructure is restored and the baseline is verified. The set of operations eligible for pre-authorization is defined in the governance configuration and is subject to SDOS-IN-01 integrity verification at system startup.
Partial-degradation states. Real systems can occupy intermediate states between full operation and total halt — for example, one of two SDOS-AU-03 audit repositories unavailable, single-module manifest revalidation failure, or SDOS-EN-02 subordinate gate reachable but slow. These partial-degradation states are governed by a documented degradation policy that specifies which operations remain permitted and which require halt; the degradation policy itself is part of the governance baseline subject to SDOS-IN-01 integrity verification. SDOS does not treat the operating space as binary.
Evidence Type: System Behavior; Test Suite Result
Related Controls: SDOS-EN-01, SDOS-EN-02, SDOS-RM-01, SDOS-IN-02
SDOS-EN-04 — Governed Egress with Tamper-Evident Audit¶
Governance Function: Enforcement
Description: All governed outbound operations are logged in a tamper-evident audit record at the time of execution. Each record captures the governance decision that permitted the operation, the identity of the agent that initiated it, the timestamp, and a protected representation of policy-relevant operation metadata. The log record is written before the operation result is returned to the caller. Tamper-evidence is implemented via chained-hash and signed-record mechanisms; the specific algorithm and signing-key management are documented in operational documentation. The record format is structured to support detection of post-hoc modification through the integrity verification mechanisms described in SDOS-AU-02.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-EN-01, SDOS-AU-01, SDOS-AU-02, SDOS-IA-01
SDOS-IA-01 — Attested Agent Identity¶
Governance Function: Identity and Attestation
Description: SDOS cryptographically verifies agent identity at the start of each governance evaluation. The agent's identity is carried through the full governance pipeline and included in the audit record for every tool invocation associated with that agent. Identity verification precedes governance evaluation: agents presenting without recognized identity are evaluated at admission; if identity cannot be verified, admission is denied. The identity record is extracted and validated by the governance layer against a governance-managed trust root, not self-asserted by the agent. "Verified" here means the identity artifact is signed and validated against the configured trust root; it does not by itself imply hardware-rooted remote attestation. When SDOS is deployed on a TEE-backed substrate, the trust root may itself be hardware-rooted, in which case the verification chain becomes hardware-attested at the substrate layer.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-AD-01, SDOS-GV-03, SDOS-AU-01, SDOS-EN-04
SDOS-IA-02 — Attested Module Identity¶
Governance Function: Identity and Attestation
Description: Each SDOS module carries a cryptographically signed manifest that declares its identity and its authorized capabilities. The governance framework verifies each module's manifest before registering any tools from that module. Modules with missing, invalid, or tampered manifests are rejected prior to tool registration — no tools from an unverified module are made available for dispatch. This prevents unauthorized modules from introducing tools into the governed execution surface without passing identity verification.
Evidence Type: Module Manifest; System Behavior
Related Controls: SDOS-GV-01, SDOS-IN-03, SDOS-EN-02, SDOS-GV-04
SDOS-AU-01 — Per-Invocation Audit Record¶
Governance Function: Audit
Description: SDOS generates a structured audit record for every tool invocation. Each record captures the governance classification assigned, the agent identity, the model binding rationale, the timestamp, and a protected representation of policy-relevant invocation parameters. Timestamp generation is governance-layer-local; cross-system event ordering across distributed deployments requires NTP or equivalent time synchronization at the deployment infrastructure layer. The audit record is written before the tool result is returned to the caller, ensuring that governance decisions are captured regardless of whether the operation succeeds, fails, or is blocked. This provides a complete, ordered record of governance activity that is not conditional on execution outcome.
Evidence Type: Audit Log Record
Related Controls: SDOS-AU-02, SDOS-AU-03, SDOS-GV-02, SDOS-RM-01, SDOS-EN-04
SDOS-AU-02 — Append-Only Audit Log Integrity¶
Governance Function: Audit
Description: SDOS produces audit records in a format that supports append-only semantics and downstream tamper detection through chained-hash or signed-record mechanisms. Records are written to a storage layer that supports append-only behavior — for example, a hash-chained log, a WORM-backed object store, or an equivalent integrity-preserving store. The application layer does not modify or delete historical records through normal operation; the durable append-only property is jointly provided by the SDOS record format and the underlying storage substrate. Storage selection and durability guarantees are deployment-tier obligations.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-AU-01, SDOS-AU-03, SDOS-IN-01, SDOS-EN-04
SDOS-AU-03 — Dual Audit Trail¶
Governance Function: Audit
Description: SDOS maintains audit records in two independently maintained audit repositories simultaneously. Both records are written as part of the same audit event. The dual trail ensures audit continuity is preserved even if one repository is unavailable, corrupted, or compromised. Discrepancies between the two repositories are detectable; SDOS produces the discrepancy signal but does not specify the resolution authority — reconciliation procedures and the responsible party are deployment-defined. Strength against frameworks that require physically separated audit storage (e.g., FedRAMP AU-9(2)) is substrate-dependent: the strongest implementation places the two repositories in separate trust domains with independent administrative control.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-AU-01, SDOS-AU-02, SDOS-IN-01
SDOS-IN-01 — Governance Baseline Integrity Verification¶
Governance Function: Integrity
Description: Before any tools are registered or any agent operations are processed, SDOS verifies the cryptographic integrity of its governance configuration against an authorized integrity baseline. The verification confirms that the configuration has not been modified since it was last authorized. This check occurs at system startup and can be triggered at runtime. A configuration that does not pass integrity verification triggers the halt behavior described in SDOS-IN-02.
Evidence Type: System Behavior; Test Suite Result
Related Controls: SDOS-IN-02, SDOS-GV-01, SDOS-GV-03, SDOS-AU-01
SDOS-IN-02 — Baseline Drift Detection and System Halt¶
Governance Function: Integrity
Description: If the governance baseline integrity check detects that the governance configuration has been modified without authorization, SDOS halts before registering any tools or processing any operations. There is no partial-governance or degraded-governance operating mode following a baseline integrity failure: the system either operates with a verified baseline or does not operate. Recovery requires explicit re-authorization of the governance baseline by a designated administrator.
Evidence Type: System Behavior; Test Suite Result
Related Controls: SDOS-IN-01, SDOS-EN-03, SDOS-GV-01
SDOS-IN-03 — Module Manifest Integrity¶
Governance Function: Integrity
Description: SDOS verifies the cryptographic signature of each module manifest before activating that module. The verification confirms that the module's declared identity and authorized capabilities match their state at the time the manifest was signed. Modules with unsigned manifests, manifests with invalid signatures, or manifests whose declared capabilities do not match the verification result are rejected before any tools from that module are registered in the governed execution surface.
Evidence Type: Module Manifest; System Behavior; Test Suite Result
Related Controls: SDOS-IA-02, SDOS-GV-01, SDOS-EN-02, SDOS-IN-01
SDOS-DE-01 — Governed Multi-Agent Deliberation¶
Governance Function: Deliberation
Description: SDOS supports structured deliberation panels in which multiple AI agents evaluate a question or decision from defined analytical perspectives. The panel composition is defined by governance policy rather than selected dynamically by any participating agent. Each participating agent is subject to the same admission and identity requirements as agents in standard governed operations. The panel process produces a structured, auditable output rather than unstructured consensus. The governance layer defines and enforces the terms of the deliberation.
Limitation — convergence is a deliberation signal, not a correctness guarantee. Agreement across participating agents reduces certain classes of single-agent error, but correlated errors across models with shared training distributions are a recognized failure mode. DE-01 outputs are inputs to human review for elevated-risk decisions, not substitutes for human oversight. Frameworks that require human oversight (e.g., EU AI Act Art. 14, ISO 42001 A.9) treat DE-01 as a technical measure that supports but does not satisfy the human-oversight obligation.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-DE-02, SDOS-IA-01, SDOS-AU-01, SDOS-GV-04, SDOS-RM-01
SDOS-DE-02 — Convergence-Based Decision Record¶
Governance Function: Deliberation
Description: The output of a governed deliberation panel is a structured decision record that captures the degree of convergence across participating agents, the individual assessments provided by each agent, and a scored summary of the panel's collective output. The decision record preserves both convergent and divergent positions, enabling reviewers to distinguish high-confidence unanimous outputs from outputs where agents held materially different positions. The decision record is retained as a governed artifact subject to the same audit requirements as other SDOS outputs.
Evidence Type: Audit Log Record; System Behavior
Related Controls: SDOS-DE-01, SDOS-AU-01, SDOS-AU-02
SDOS-RS-01 — Governed Return on Safety Investment (ROSI) Evaluation¶
Governance Function: Risk Measurement
Description: SDOS includes a value evaluation subsystem within the audit and learning layer that computes a Return on Safety Investment (ROSI) metric, enabling operators to assess whether governance overhead is justified by measurable risk reduction. The evaluation operates on a dual-track framework: Track 1 captures immediate operational metrics — cost avoidance (weighted 0.40), time saved (0.35), and efficiency gain (0.25); Track 2 captures strategic metrics — exposure reduction (weighted 0.40), resilience gain (0.35), and mission continuity (0.25). The two tracks are combined into a composite ROSI score in the range [0.0, 1.0], from which the system generates a priority recommendation. The ROSI report includes per-dimension statistical summaries (mean, standard deviation, sample count) derived from accumulated feedback data, enabling operators to identify which governance dimensions produce the greatest return. ROSI evaluation runs post-hoc over the accumulated query log and feedback records maintained by the audit layer, requiring no additional data collection infrastructure beyond the governed feedback loop already in operation.
Evidence Type: Audit Log Record; System Behavior; Operator Report
Patent Reference: U.S. Provisional Application No. 64/049,300 (filed 2026-04-25), §9.2; Claims 81–84
Related Controls: SDOS-AU-01, SDOS-AU-02, SDOS-AU-03, SDOS-RM-01, SDOS-RM-02
SDOS-AD-01 — Default-Deny Agent Pre-Admission¶
Governance Function: Admission
Description: Agents are denied access to governed operations by default. An agent must be explicitly admitted to the SDOS governance framework before any tool invocations from that agent are evaluated. Admission is a precondition for governance evaluation: an agent that has not been admitted cannot proceed to runtime risk classification, model binding, or tool execution, regardless of its claimed identity or presented credentials. This default-deny posture applies to all agents without exception, including agents operating under previously established sessions.
Evidence Type: System Behavior; Test Suite Result; Audit Log Record
Related Controls: SDOS-GV-03, SDOS-IA-01, SDOS-EN-01, SDOS-AU-01
Primary Mapping Target¶
The SDOS Runtime Governance Framework maps to the NIST AI Risk Management Framework (AI RMF) 1.0 as the primary focal document. The representative mapping table for AI RMF 1.0 is embedded in the Framework Alignment section of this document. The complete 49-subcategory mapping is cataloged with the NIST OLIR Program as SDOS-RuntimeGov-to-AI-RMF-v1.0 (Reference ID 220), a Final informative reference as of 2026-06-15 (public review concluded with zero comments). View in the NIST OLIR Catalog.
Authoritative sources:
- NIST AI Risk Management Framework 1.0 (primary focal document) — NIST AI 100-1, January 2023
- NIST OLIR Catalog Reference ID 220 — SDOS-RuntimeGov-to-AI-RMF-v1.0
- NIST OLIR Program — csrc.nist.gov/projects/olir
- NIST IR 8278 (OLIR submission guidelines) — csrc.nist.gov/pubs/ir/8278/r1/final
- Companion OLIR submissions — SDOS-to-CSF-2.0-v1.0 · SDOS-to-SP-800-53-Rev-5.2.0-v1.0 · SDOS-to-AI-600-1-v1.0
For organizations subject to EU AI Act (Regulation 2024/1689) obligations, a control-level alignment analysis is available at SDOS — EU AI Act Alignment.
Alignment against any framework does not constitute certification by, endorsement from, or affiliation with any of the organizations that maintain them. Organizations should conduct independent assessment to determine whether SDOS controls satisfy their specific compliance requirements.
Frequently Asked Questions¶
What is the SDOS Runtime Governance Framework?¶
SDOS (Security Decision Operating System) is a runtime governance framework that enforces structured policy controls over AI agent operations at the point of dispatch. It binds AI model selection, tool invocation, outbound execution, and audit logging to verifiable governance rules through 24 controls across 9 governance domains. SDOS is model-alignment-independent: it does not rely on the model's internal safety tuning or alignment claims for enforcement.
Is SDOS cataloged with NIST?¶
Yes. The OLIR Trifecta is cataloged with the NIST OLIR Program and all three reached Final status with zero public comments: SDOS-RuntimeGov-to-AI-RMF-v1.0 (Reference ID 220, Final 2026-06-15), SDOS-RuntimeGov-to-CSF-2.0-v1.0 (Reference ID 215, Final 2026-06-22), and SDOS-RuntimeGov-to-SP-800-53-Rev-5.2.0-v1.0 (Reference ID 217, Final 2026-06-22). A fourth submission (SDOS-RuntimeGov-to-AI-600-1-v1.0, filed 2026-05-17) was declined by the OLIR Program; the framework's AI 600-1 (GenAI Profile) mapping remains published on this reference site.
How many controls are in the SDOS catalog?¶
24 controls across 9 governance domains: Governance Policy (5), Risk Management (3), Admission (1), Identity Attestation (2), Integrity (3), Egress Enforcement (4), Audit (3), Deliberation (2), and Risk Measurement (1).
What frameworks does SDOS align with?¶
17 framework alignments are documented in the SDOS Reference Library: NIST AI RMF 1.0, NIST CSF 2.0, NIST SP 800-53 Rev 5.2.0, NIST AI 600-1 (GenAI Profile), EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, SOC 2, NAIC MDL-668, NERC CIP, IEEE P2863 (draft), and FAA UAS/AAM (principles-mapped).
What does "model-alignment-independent" mean?¶
SDOS governance enforcement outcomes are structurally identical regardless of whether the underlying AI model is well-aligned, misaligned, fine-tuned, or untrained. The dispatch-time enforcement layer operates below model alignment — it intercepts AI agent operations at the dispatch boundary and evaluates them against a configuration-governed policy, without relying on training-time safety properties of the model itself.
What is dispatch-time enforcement?¶
Dispatch-time enforcement is the architectural pattern of evaluating AI agent operations against governance policy at the moment immediately before the agent invokes a tool, makes a decision, or produces an output. This is distinct from output filtering (which occurs after the model generates a response) and from agent supervision (which monitors agent behavior over time without structurally constraining individual operations).
How is SDOS different from AI safety alignment?¶
AI safety alignment relies on training-time properties of the AI model itself — reinforcement learning from human feedback (RLHF), constitutional AI, safety fine-tuning. SDOS operates structurally below model alignment: it intercepts AI agent operations at the dispatch boundary and evaluates them against a configuration-governed policy. SDOS produces the same governance outcomes regardless of model alignment state.
Who is SDOS designed for?¶
CISOs, GRC auditors, AI risk assessors, federal program managers, prime contractors evaluating AI governance subcontractors, healthcare and financial services compliance teams, energy sector AI governance teams, insurance carriers subject to NAIC MDL-668, and any organization deploying autonomous or semi-autonomous AI agent workflows in regulated environments. SDOS is applicable wherever AI agents invoke tools, make decisions, or produce outputs on behalf of an operator.
Maintenance¶
This document is maintained by AAM Cyber. Version 1.10 is the canonical version. The framework library covers 17 standards: NIST AI RMF 1.0, NIST CSF 2.0, NIST SP 800-53 Rev 5.2.0, NIST AI 600-1, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, SOC 2, NAIC MDL-668, NERC CIP, IEEE P2863 (draft), and FAA UAS/AAM (principles-mapped). Subsequent version updates will be issued when: (1) controls are added or retired, (2) control descriptions are materially revised, (3) a target focal document releases a new version requiring mapping review, or (4) a new framework alignment is published. Version history is available at /sdos/reference/changelog/.
Contact¶
AAM Cyber
aamcyber.com
Questions about the SDOS Runtime Governance Framework, this reference document, or framework alignment inquiries: [email protected]
Intellectual Property¶
The SDOS Runtime Governance Framework was invented by Pharns Genece. Aspects of the framework are the subject of pending U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620. The scope of pending claims is defined by the as-filed specifications and is not coextensive with the descriptions in this control catalog. AAM Cyber, all rights reserved unless otherwise indicated.
Patent inquiries should be directed to AAM Cyber at aamcyber.com.
SDOS Runtime Governance Framework — Control Catalog and Reference Document, Version 1.10. Published 2026-05-12.