SDOS Runtime Governance Framework — FAA UAS/AAM AI Governance¶
SDOS Version: 1.10
Regulatory Basis: FAA Safety Objectives for UAS Operations (14 CFR Part 107), Air Carrier and Air Taxi Operations (14 CFR Part 135), Advanced Air Mobility (FAA Innovate28), and AI in Aviation (FAA Order 8040.6 (current revision))
Status: Principles-Mapped — No federal standard currently governs the AI dispatch layer for UAS/AAM operations. Governance objectives in this document were derived from first principles against existing FAA safety requirements (Part 107, Part 135, Order 8040.6 (current revision), UTM ConOps, Innovate28). SDOS controls are mapped to those derived objectives. This document does not represent FAA endorsement or regulatory guidance.
Document Date: 2026-05-17 (updated from 2026-05-03)
Authoring Organization: AAM Cyber (aamcyber.com)
Inventor: Pharns Genece
SDOS Control Catalog: View full control definitions
Purpose¶
This document derives governance objectives from existing FAA safety principles and maps SDOS controls against those objectives — establishing what a federal AI governance standard for autonomous UAS and Advanced Air Mobility (AAM) dispatch operations should require, and showing how SDOS is designed to address those requirements.
No FAA-published standard currently governs the AI agent dispatch layer for UAS or AAM platforms. Existing aviation software standards address the flight envelope. The governance gap is above the aircraft — in the AI agent layer that dispatches commands, manages fleet decisions, and coordinates airspace requests. That gap is where SDOS operates.
This document is intended for FAA stakeholders, DoD program managers, AAM platform providers, UAS fleet operators, and federal procurement teams evaluating AI governance controls for autonomous aviation systems.
This is a principles-mapped alignment document, not a compliance certification. Governance objectives were derived from first principles against existing FAA requirements — they were not published by the FAA or endorsed by any federal agency. SDOS controls are mapped to those derived objectives with full mapping rationale. This document does not represent FAA endorsement or regulatory guidance.
The Governance Gap: What DO-178C Does Not Cover¶
DO-178C (Software Considerations in Airborne Systems and Equipment Certification) is the governing standard for software in the flight envelope. It addresses software development assurance, verification, and testing for avionics and flight control systems. DO-178C is rigorous, well-established, and covers the aircraft.
DO-178C does not cover the AI dispatch layer. The dispatch layer is the system above the aircraft that:
- Assigns missions to autonomous platforms
- Routes commands through AI agents before transmission to the vehicle
- Makes fleet coordination decisions across multiple UAS
- Submits airspace coordination requests to UTM systems
- Governs what an AI agent is permitted to do before it acts
No current FAA advisory circular directly addresses the AI agent dispatch decision layer — the system that governs what an AI agent is permitted to do before it acts. Standards bodies including ASTM F38 and SAE G-34 are developing work on UAS C2, fleet operations, and AI in aviation safety-critical systems; those efforts address adjacent layers. The dispatch-time AI agent governance layer — enforcement of policy at the moment an AI agent produces an output — remains unaddressed. That is the exact scope of the SDOS Runtime Governance Framework.
These are non-overlapping scopes. SDOS does not replace or compete with DO-178C — it governs the layer that DO-178C never touches.
FAA Context: Why This Gap Is Urgent Now¶
Advanced Air Mobility (AAM) and Innovate28
The FAA's Innovate28 initiative is accelerating AAM certification timelines in anticipation of the 2028 Los Angeles Olympics. Powered-lift vehicles (eVTOL) — including platforms from Joby Aviation, Archer Aviation, and others — represent a new aircraft category requiring new certification pathways. The FAA published a final rule establishing the powered-lift pilot certification and operating requirements in 2023.
The unresolved question in AAM certification is not flight control software — it is autonomous and semi-autonomous operation at the ground dispatch layer. The current FAA answer is "prove it with extensive operational data" because no governance standard yet exists for this layer.
14 CFR Part 107 — UAS Operations
Part 107 governs small UAS operations. As autonomous UAS operations scale — particularly in Beyond Visual Line of Sight (BVLOS) operations — the AI systems that dispatch flight commands, manage multi-aircraft coordination, and interface with UTM infrastructure are operating without a governance standard that addresses their decision-making layer.
FAA Order 8040.6 — Unmanned Aircraft Systems Policy
FAA Order 8040.6 (current revision) establishes UAS policy across FAA lines of business. It addresses safety, airworthiness, and operational approval — but does not specify technical governance requirements for AI agent dispatch systems.
14 CFR Part 135 — Air Carrier and Air Taxi Operations (AAM/Powered-Lift)
Part 135 governs on-demand air carrier and air taxi operations. It is the certification pathway for commercial AAM operators — the framework under which powered-lift air taxi operators (Joby Aviation, Archer Aviation, Wisk, and others) will operate revenue service. Amazon Prime Air holds a Part 135 air carrier certificate for commercial UAS package delivery. Part 135 imposes operational control obligations, crew qualification requirements, maintenance standards, and safety management requirements on certificate holders.
The AI dispatch layer in a Part 135 AAM or commercial UAS operation is the system that manages vehicle assignment, route authorization, operational control handoffs, and departure clearance requests. Part 135 requires that operations be conducted in accordance with the certificate holder's Operations Specifications (OpSpecs) — which govern what the certificate holder is authorized to do. An AI dispatch system operating within the certificate holder's operational control system is a tool used by the humans who exercise that authority. No current Part 135 requirement or FAA guidance specifies how AI tools operating within the operational control system must be governed at the dispatch layer.
Key Part 135 provisions where the AI dispatch governance gap is most acute:
- §135.77 — Responsibility for Operational Control: The certificate holder is responsible for operational control, exercised by named authorized individuals. An AI dispatch system operates as a tool within that human-governed operational control system — the certificate holder's responsibility does not transfer to the AI, but the governance layer that ensures AI dispatch decisions conform to OpSpecs is currently unaddressed by FAA guidance.
- §135.89 — Pilot in Command Qualifications: §135.89 establishes the qualification requirements for human PICs. For autonomous powered-lift, the question of how AI dispatch decisions interact with the designated PIC's responsibility and authority boundary remains unresolved under current rules. SDOS dispatch-time enforcement provides an architectural boundary between AI-generated dispatch recommendations and authorized execution — the PIC boundary is human; SDOS enforces the dispatch layer beneath it.
- 14 CFR Part 5 — Safety Management System (SMS): The FAA's SMS final rule (effective 2025 for applicable Part 135 operators) requires systematic hazard identification, risk assessment, and risk controls. An AI dispatch system that affects operational safety is a hazard source that must be identified, assessed, and controlled within the certificate holder's SMS. No FAA guidance currently specifies how AI dispatch governance controls satisfy Part 5 SMS requirements.
- §135.415 / §135.417 — Mechanical Reliability Reports and Maintenance: Safety management and operational data reporting obligations. Every AI-dispatched command that affects aircraft operational status must be auditable against these obligations. SDOS tamper-evident audit (AU-01, AU-02, EN-04) provides the dispatch-layer audit trail.
UTM (Unmanned Traffic Management)
The FAA's UTM concept of operations defines how UAS integrate into low-altitude airspace. AI agents that submit flight authorizations, request dynamic corridor updates, or coordinate deconfliction with other operators interact with UTM infrastructure. No governance standard currently addresses the AI agent layer that produces these requests.
Applicability¶
This proposed mapping applies to organizations developing or operating:
- Autonomous or semi-autonomous UAS platforms operating under 14 CFR Part 107 or FAA BVLOS waiver
- Advanced Air Mobility (AAM) / powered-lift (eVTOL) dispatch and fleet management systems operating under or seeking 14 CFR Part 135 air carrier certification
- Commercial UAS operators holding or pursuing Part 135 air carrier certificates (e.g., package delivery, air taxi operations)
- AI agent systems that submit requests to UTM infrastructure or airspace coordination services
- Fleet management systems in which AI agents assign missions, coordinate deconfliction, or issue priority overrides across multiple aircraft
- DoD or federal agency UAS programs evaluating AI governance controls for autonomous aviation operations
SDOS Control Catalog Summary¶
The full control catalog with per-control descriptions, evidence types, and related control dependencies is published at /sdos/reference/v1/. The 24 SDOS controls comprising the public runtime control set are:
| Control ID | Title |
|---|---|
| SDOS-GV-01 | Configuration-Governed Module Activation |
| SDOS-GV-02 | Governance-Tiered Model Selection |
| SDOS-GV-03 | Default-Deny Pre-Admission Policy |
| SDOS-GV-04 | Cross-Module Governance Continuity |
| SDOS-GV-05 | Model-Alignment-Independent Policy Enforcement |
| SDOS-RM-01 | Dispatch-Time Risk Classification |
| SDOS-RM-02 | Complexity-Tiered Resource Allocation |
| SDOS-RM-03 | Risk-Floor Model Binding |
| SDOS-AD-01 | Default-Deny Agent Pre-Admission |
| SDOS-IA-01 | Attested Agent Identity |
| SDOS-IA-02 | Attested Module Identity |
| SDOS-IN-01 | Governance Baseline Integrity Verification |
| SDOS-IN-02 | Baseline Drift Detection and System Halt |
| SDOS-IN-03 | Module Manifest Integrity |
| SDOS-EN-01 | Pre-Egress Policy Enforcement |
| SDOS-EN-02 | Subordinate-Side Enforcement Gate |
| SDOS-EN-03 | Fail-Closed Degradation |
| SDOS-EN-04 | Governed Egress with Tamper-Evident Audit |
| SDOS-AU-01 | Per-Invocation Audit Record |
| SDOS-AU-02 | Append-Only Audit Log Integrity |
| SDOS-AU-03 | Dual Audit Trail |
| SDOS-DE-01 | Governed Multi-Agent Deliberation |
| SDOS-DE-02 | Convergence-Based Decision Record |
| SDOS-RS-01 | Governed Return on Safety Investment (ROSI) Evaluation |
Derived Governance Objectives¶
In the absence of a published standard, this document derives governance objectives from existing FAA safety principles, the NIST AI RMF, and the operational architecture of AI-governed UAS/AAM dispatch systems.
| Objective ID | Proposed Governance Objective | Derived From |
|---|---|---|
| FAA-GOV-01 | AI dispatch systems must enforce mission scope constraints before transmitting commands to any platform | Part 107 operational limitations; FAA Order 8040.6 (current revision) safety principles |
| FAA-GOV-02 | Every AI-dispatched command must generate a tamper-evident audit record before execution | NIST AI RMF MANAGE-4.1; DO-178C auditability principles |
| FAA-GOV-03 | AI agents must operate under cryptographically verified identity — unverified agents must not dispatch commands | FAA Order 8040.6 (current revision); NIST AI RMF GOVERN-1.1 |
| FAA-GOV-04 | Airspace coordination requests submitted by AI agents must be governed by pre-egress policy enforcement before transmission to UTM | UTM ConOps; Part 107 operational approval principles |
| FAA-GOV-05 | Fleet coordination commands must be evaluated against risk tier before dispatch — AI agents must not self-escalate to higher capability operations | NIST AI RMF MAP-1.1; FAA safety risk management principles |
| FAA-GOV-06 | If the governance infrastructure is unavailable, AI dispatch must transition to a pre-authorized safe-state policy. The safe-state policy is defined per mission type and may include: halting new dispatch commands, executing pre-authorized contingency commands (e.g., return-to-launch, loiter, hold), or handing control to a human supervisor. The selected safe-state action must be defined and integrity-verified before mission start; a mid-mission UAS that loses dispatch governance executes its pre-authorized contingency, not a generic stop. "Halt" in this objective refers to cessation of new AI-governed dispatch decisions — it does not refer to aircraft flight control systems, which remain governed by their own safety envelope. | FAA safety-critical system design principles; DO-178C fail-safe requirements; per-mission contingency planning |
| FAA-GOV-07 | Governance configuration must be integrity-verified at startup — no AI dispatch system may operate under a modified or corrupted governance baseline | DO-178C configuration management; NIST AI RMF MEASURE-2.5 |
| FAA-GOV-08 | Dispatch policy must enforce mission boundaries independent of the AI model's alignment or instruction-following behavior | NIST AI RMF GOVERN-1.7; model-alignment-independence engineering principles |
| FAA-135-01 | AI dispatch systems exercising operational control in Part 135 operations must enforce conformance with the certificate holder's Operations Specifications (OpSpecs) before any dispatch decision is executed | 14 CFR §135.77 — Responsibility for Operational Control |
| FAA-135-02 | AI dispatch decisions must be bounded by pre-authorized scope constraints that preserve the designated PIC's authority boundary — AI tools within the operational control system must not autonomously escalate operational authority | 14 CFR §135.77 — Responsibility for Operational Control; §135.89 — Pilot in Command Qualifications (human PIC anchor) |
| FAA-135-03 | If the AI dispatch governance layer becomes unavailable during a Part 135 operation, the system must transition to a pre-authorized safe-state consistent with OpSpecs and applicable contingency procedures — as required under the certificate holder's SMS hazard controls | 14 CFR Part 5 — Safety Management System; DO-178C fail-safe design principles |
| FAA-135-04 | Every AI dispatch decision that affects aircraft operational status must generate a tamper-evident audit record sufficient to satisfy Part 135 safety management and reporting obligations | 14 CFR §135.415 / §135.417 — Mechanical Reliability Reports; Safety Management |
Principles-Mapped Alignment Table¶
| Derived Objective | SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|
| FAA-GOV-01 Mission scope enforcement before command transmission | GV-01, GV-03, EN-01, EN-02 | Strong | Config-governed module activation + default-deny + pre-egress enforcement = mission scope constraints applied at the AI dispatch layer before any command exits the governed boundary. SDOS governs what the AI agent is permitted to output; hardware transmission layers below the dispatch boundary are governed by platform-specific controls. |
| FAA-GOV-02 Tamper-evident audit record per dispatch event | AU-01, AU-02, AU-03, EN-04 | Strong | Per-invocation audit record + append-only integrity + dual audit trail redundancy + governed egress audit = tamper-evident record for every AI-dispatched command |
| FAA-GOV-03 Cryptographically verified agent identity | IA-01, IA-02 | Strong | Verified agent identity + verified module identity = verified identity before any dispatch operation; unverified agents cannot activate |
| FAA-GOV-04 Pre-egress enforcement for airspace coordination requests | EN-01, EN-02, GV-05 | Strong | Pre-egress policy enforcement + subordinate gate + model-alignment-independent policy = governed airspace request transmission |
| FAA-GOV-05 Risk-tiered dispatch — no self-escalation | RM-01, RM-02, RM-03, GV-02 | Strong | Dispatch-time risk classification + complexity-tiered resource allocation + risk-floor model binding = AI agents cannot self-escalate to higher capability tiers |
| FAA-GOV-06 Fail-safe transition when governance unavailable | EN-03 | Strong | EN-03 implements transition to a pre-authorized safe-state policy when governance infrastructure is unavailable. The safe-state action is defined per mission and integrity-verified — it may halt new dispatch, execute pre-authorized contingency commands, or hand control to a human supervisor. EN-03 never bypasses governance to continue uncontrolled dispatch. |
| FAA-GOV-07 Governance baseline integrity verification at startup | IN-01, IN-02, IN-03 | Strong | Governance baseline integrity verification + drift detection with halt + module manifest integrity = verified governance configuration before any operation |
| FAA-GOV-08 Policy enforcement independent of model alignment | GV-05 | Strong | Model-alignment-independent policy enforcement is a named SDOS control — enforcement operates through structural separation from model inference |
| FAA-135-01 OpSpecs conformance enforcement before Part 135 dispatch | GV-01, GV-03, GV-05, EN-01 | Strong | Config-governed module activation enforces only authorized operations; default-deny + pre-egress enforcement = OpSpecs boundary at the AI dispatch layer |
| FAA-135-02 PIC authority boundary preserved — no autonomous escalation by AI tool | GV-02, RM-01, RM-03, AD-01 | Strong | Governance-tiered model selection + dispatch-time risk classification + risk-floor model binding + default-deny admission = AI dispatch tool cannot self-escalate beyond pre-authorized operational scope; PIC authority boundary is enforced structurally |
| FAA-135-03 Safe-state transition during governance unavailability — SMS hazard control | EN-03 | Strong | EN-03 fail-closed degradation transitions to pre-authorized safe-state consistent with OpSpecs contingency procedures when governance infrastructure is unavailable — satisfies Part 5 SMS requirement for defined risk controls on AI dispatch hazards |
| FAA-135-04 Tamper-evident audit for Part 135 safety management obligations | AU-01, AU-02, AU-03, EN-04 | Strong | Per-invocation audit record + append-only integrity + dual audit trail + governed egress audit = tamper-evident dispatch record satisfying §135.415/§135.417 reporting obligations |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | FAA-GOV-01: only explicitly configured dispatch modules may activate |
| SDOS-GV-02 — Governance-Tiered Model Selection | FAA-GOV-05: capability tier matched to mission risk classification |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | FAA-GOV-01: default-deny foundation for mission scope enforcement |
| SDOS-GV-04 — Cross-Module Governance Continuity | FAA-GOV-03: identity chain maintained across fleet coordination modules |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | FAA-GOV-08: policy enforced structurally, not by model behavior |
Risk Management (RM)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | FAA-GOV-05: every dispatch event classified before execution |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | FAA-GOV-05: resource allocation matched to mission complexity tier |
| SDOS-RM-03 — Risk-Floor Model Binding | FAA-GOV-05: minimum capability floor for high-risk dispatch operations |
Enforcement (EN)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | FAA-GOV-01/04: mission scope and airspace request enforcement before transmission |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | FAA-GOV-01/04: secondary enforcement at module boundary |
| SDOS-EN-03 — Fail-Closed Degradation | FAA-GOV-06: governance unavailability triggers transition to pre-authorized safe-state policy (halt new dispatch, execute pre-authorized contingency, or hand to human supervisor — defined per mission type) |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | FAA-GOV-02: tamper-evident record for every governed output |
Identity and Attestation (IA)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | FAA-GOV-03: cryptographically verified agent identity before dispatch |
| SDOS-IA-02 — Attested Module Identity | FAA-GOV-03: module identity is verified before activation |
Audit (AU)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | FAA-GOV-02: audit record for every dispatch event |
| SDOS-AU-02 — Append-Only Audit Log Integrity | FAA-GOV-02: tamper protection for dispatch audit trail |
| SDOS-AU-03 — Dual Audit Trail | FAA-GOV-02: redundant audit record storage |
Integrity (IN)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | FAA-GOV-07: verified governance configuration at startup |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | FAA-GOV-07: unauthorized governance change halts dispatch |
| SDOS-IN-03 — Module Manifest Integrity | FAA-GOV-07: module integrity verified before activation |
Admission (AD)¶
| Control | FAA UAS/AAM Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | FAA-GOV-01: default-deny foundation — no agent dispatches without explicit admission |
Glossary¶
| Term | Definition |
|---|---|
| UTM | Unmanned Traffic Management — the FAA's concept for managing low-altitude UAS operations, analogous to air traffic control for manned aviation |
| BVLOS | Beyond Visual Line of Sight — UAS operations conducted where the pilot cannot see the aircraft with unaided vision; requires FAA waiver under Part 107 |
| eVTOL | Electric Vertical Takeoff and Landing — powered-lift aircraft in the Advanced Air Mobility category (e.g., air taxis, urban air mobility vehicles) |
| AAM | Advanced Air Mobility — the FAA's umbrella term for new aviation markets including urban air mobility, regional air mobility, and autonomous cargo operations |
| Dispatch | In this document, "dispatch" refers to AI-governed assignment of missions, commands, or operational instructions to autonomous platforms — not traditional airline flight dispatch |
| Point of dispatch | The moment a task is assigned to an AI agent and before any command is transmitted to a platform; the primary SDOS enforcement boundary |
| DO-178C | Software Considerations in Airborne Systems and Equipment Certification — the governing standard for avionics and flight control software |
| ASTM F38 | ASTM International Committee F38 on Unmanned Aircraft Systems — the primary standards body developing operational and airworthiness standards for UAS, including BVLOS operations |
| RTCA SC-228 | RTCA Special Committee 228 — the aviation industry standards body that developed MOPS (Minimum Operational Performance Standards) for UAS, including detect-and-avoid and command-and-control link standards |
Use Cases¶
BVLOS UAS Fleet Operations¶
An operator running BVLOS missions with multiple AI-controlled aircraft uses an AI agent to assign waypoints, manage return-to-home decisions, and coordinate deconfliction. SDOS governs the dispatch layer: every command is classified at dispatch, the AI agent operates under verified identity, pre-egress enforcement ensures no command outside mission scope is transmitted, and every dispatch event is recorded in a tamper-evident audit trail.
AAM Ground Operations — Powered-Lift Dispatch¶
A powered-lift (eVTOL) operator uses an AI agent to manage ground dispatch decisions — vehicle assignment, route selection, passenger boarding coordination, and departure authorization requests to local airspace management. SDOS enforces dispatch policy at the AI agent layer: agents cannot self-escalate to departure authorization without explicit admission to that capability tier, and every dispatch decision is auditable.
UTM Airspace Coordination¶
An AI agent autonomously generates and submits flight authorization requests to a UTM system. SDOS pre-egress enforcement evaluates each request against mission scope constraints — altitude band, corridor, time window — before the request is transmitted. Requests outside policy are blocked. Every transmission is recorded with a tamper-evident audit record.
Multi-Operator Fleet Coordination¶
An AI swarm coordination system manages a fleet of UAS across multiple operator domains. SDOS governs inter-agent dispatch instructions: every command one agent sends to coordinate another is evaluated at the dispatch boundary, signed against the originating agent's identity, and recorded before execution.
Part 135 Air Taxi Operations — Powered-Lift Dispatch Governance¶
A Part 135 certificate holder operating a powered-lift air taxi fleet uses an AI dispatch agent to manage vehicle assignment, route authorization, and departure clearance requests. The certificate holder's Operations Specifications define what operations are authorized. SDOS enforces OpSpecs conformance at the AI dispatch layer: the dispatch agent can only activate modules explicitly configured against authorized operations, cannot self-escalate to route types outside its admitted capability tier, and every dispatch decision is recorded in a tamper-evident audit trail that satisfies the certificate holder's §135.415/§135.417 safety management reporting obligations. If the governance layer becomes unavailable mid-operation, EN-03 transitions to the pre-authorized safe-state defined in the certificate holder's contingency procedures — the AI does not continue dispatching without governance.
Strategic Context¶
The SBIR Opportunity¶
The absence of a governance standard for AI dispatch in UAS/AAM operations is a defined federal technology gap. The FAA, DoD, and DHS SVIP all fund technology that addresses unresolved aviation safety and security challenges. A runtime governance framework purpose-built for the AI dispatch layer — with patent-filed claims covering dispatch-time enforcement, pre-egress policy, and verified agent identity, and now listed in the NIST OLIR catalog — is positioned directly against this gap.
The Regulatory Timing Window¶
The FAA's Innovate28 initiative is compressing AAM certification timelines. Standards bodies (ASTM F38, RTCA SC-228) have developed and continue to refine UAS operational standards. The governance standard for AI dispatch does not yet exist. This document represents an initial technical framing for what a governance standard at this layer should require, grounded in existing FAA safety principles and the NIST AI RMF.
Relationship to Other Frameworks¶
SDOS is also mapped to NIST AI RMF 1.0, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, and SOC 2. For UAS/AAM operators subject to federal procurement requirements, SDOS controls address FedRAMP and CMMC obligations simultaneously with the proposed FAA objectives above.
Full NIST AI RMF mapping: SDOS Control Catalog and Reference Document v1.8
Architectural Positioning¶
SDOS operates at the dispatch-time enforcement layer — the moment immediately before an AI agent invokes a tool, makes a decision, or produces an output. The SDOS framework does not replace organizational, physical, or personnel cybersecurity controls. It provides a runtime layer that enforces governance policy at the boundary where AI agents act, adding an architectural layer of cybersecurity assurance for AI-augmented operations.
For alignment purposes, SDOS supports the operational and technical requirements addressing how AI-driven cyber operations are deployed, monitored, and audited. Requirements addressing the organizational, physical, or personnel layer fall outside the SDOS scope and require separate controls.
Maintenance¶
This document is maintained by AAM Cyber as part of the SDOS Reference Library. The library currently covers 17 framework alignments: 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). Version history for every framework alignment is published at /sdos/reference/changelog/.
Subsequent updates to this alignment page will be issued when: (1) screening feedback from a recognized standards body requires revision, (2) the focal framework releases a revision requiring mapping review, or (3) SDOS controls are added or retired affecting the alignment.
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 document. Embodiments contemplated within the broader framework include governed dispatch of autonomous and semi-autonomous aerial platforms, including powered-lift vehicles operating under FAA-regulated conditions, fleet coordination operations for unmanned aerial systems, and airspace coordination requests governed by pre-egress policy enforcement. AAM Cyber, all rights reserved unless otherwise indicated.
Patent inquiries should be directed to AAM Cyber at aamcyber.com.
Contact¶
AAM Cyber
aamcyber.com
Organizations developing AI governance programs for UAS or AAM operations, or federal program offices evaluating this framework for procurement or standards development purposes: [email protected]
SDOS Runtime Governance Framework — FAA UAS/AAM AI Governance Principles-Mapped Alignment. Version 1.7. Published 2026-05-03. Updated 2026-05-17.