Edge sovereignty
Mission data and inference can remain on the device or inside an agreed network boundary when latency, bandwidth, resilience, or data control requires it.
00Governed edge intelligence
Local AI for robotics. Human authority by design.
NeuraOS places perception, sensor fusion, autonomous planning, and local inference close to robotic hardware—especially where connectivity is intermittent, latency is bounded, and every consequential action needs explicit governance.
Current public source snapshot · 27 August 2026 · release identity and technology pins remain canonical on GitHub
- Current public edition
- 2026
- Linux foundation
- 6.18 LTS
- ROS 2 baseline
- Lyrical LTS
- Final authority
- Human
01Operating principles
Govern the autonomy around the model.
Model confidence is not command authority. NeuraOS treats AI as a fallible subsystem inside explicit policy, identity, safety, release, and evidence boundaries.
Bounded autonomy
Policy, time, geography, confidence, identity, and resource limits are enforced outside the model rather than trusted to a prompt or confidence score.
Deterministic safety
Probabilistic AI does not replace the independent command arbiter, watchdog, emergency protection, or predefined minimum-risk state.
Evidence-first engineering
Models, configurations, workload releases, approvals, runtime decisions, faults, overrides, and rollback actions remain attributable and reviewable.
Open interoperability
Robotics, autonomy, data, and inference boundaries are shaped around maintained ecosystem standards and explicit adapters rather than hidden lock-in.
Product capability is always paired with an operating control.
Robotic perception
Product capability
Multi-sensor detection, tracking, fusion, and scene understanding close to hardware.
Operating control
Calibrated confidence, stale-data rejection, provenance, and operator-visible uncertainty.
Ground, air, and maritime robotics
Product capability
Navigation, route planning, mission workload, and vehicle-interface support.
Operating control
Independent motion or flight controller, geofence, command arbitration, and minimum-risk state.
Multi-vehicle operations
Product capability
Telemetry, task allocation, and resilient coordination across heterogeneous devices.
Operating control
Authenticated membership, rate limits, loss-of-link policy, local refusal, and recovery evidence.
Disconnected edge AI
Product capability
Local vision, speech, language, and portable inference without a permanent cloud dependency.
Operating control
Approved model allowlists, resource limits, signed identity, and no silent online learning.
Simulation and digital twins
Product capability
Software- and hardware-in-the-loop validation, deterministic replay, and fault injection.
Operating control
Reproducible test evidence, hazard traceability, release gates, and rollback proof.
02System architecture
Governance authorizes. Local safety can still refuse.
The governance plane grants authority and records evidence, but it is not a data-plane dependency for every real-time cycle. The independent safety envelope can reject, pause, override, or move the system to a predefined safe state.
L01
Human operator
Mission authority, operating intent, approval, pause, override, and residual-risk ownership.
L02
Governance and policy
Identity, rules, authorization, model and workload approval, evidence capture, and audit.
L03
Robotic workloads
Perception, navigation, planning, mission behaviors, fleet tasks, and health-aware coordination.
L04
Edge AI runtimes
ONNX Runtime, LiteRT, ExecuTorch, OpenVINO, llama.cpp, vision, and sandboxed extensions.
L05
Robotics fabric
ROS 2, DDS Security, Zenoh, MAVLink 2, and versioned adapters across constrained links.
L06
Independent safety envelope
Command arbitration, limits, sensor validity, watchdogs, safe state, and authenticated human override.
L07
Platform trust and hardware
Linux LTS, PREEMPT_RT, Buildroot, measured boot, immutable root, signed A/B updates, SBOM, and heterogeneous compute.
Portfolio boundary
NowFlow can govern mission workflow, agents, approvals, and machine handoffs above the edge. NeuraOS carries approved workloads close to robotic hardware. NODERIQ evaluates broader verifiable robotic-workflow patterns. None replaces the target platform's independent safety authority or proves a field deployment by itself.
03Current technology stack
Maintained foundations, pinned for evidence.
The August 2026 public record uses supported LTS foundations and current stable robotics, inference, and security runtimes. Operational images require immutable revisions, hashes, machine-readable SBOMs, and signed provenance.
Kernel
Linux 6.18 LTS + PREEMPT_RT
Long-lived, real-time-capable platform baseline
Embedded build
Buildroot 2025.02.17 LTS · 2026.05.2 Stable
Minimal, reproducible, board-specific Linux images
Robotics
ROS 2 Lyrical Luth
LTS nodes, lifecycle, tooling, and ecosystem interoperability
Real-time data
Fast DDS 3.6.2 + DDS Security
Authenticated, policy-controlled publish and subscribe
Edge fabric
Eclipse Zenoh 1.10.0
Store, query, and pub-sub across constrained or disrupted links
Vehicle APIs
MAVLink 2 · MAVSDK 3.17.3
Versioned vehicle telemetry and command integration
Autopilot adapters
PX4 1.17.0 · ArduPilot 4.7.0
Companion-computer integration with independent safety authority
Portable inference
ONNX Runtime 1.29.0
Cross-vendor CPU, GPU, and NPU execution providers
On-device ML
LiteRT 2.2.0 · ExecuTorch 1.4.1
Compiled, quantized, accelerator-aware edge models
Intel inference
OpenVINO 2026.3.0
CPU, integrated GPU, and NPU acceleration
Vision
OpenCV 5.0.0 · ncnn 20260526
Vision pipelines and compact native inference
Local AI and extensions
llama.cpp 0.3.0 · WasmEdge 0.17.1
Offline assistance and capability-limited portable workloads
Version snapshot: public neuraparse/neuraos main branch, commit 49a27b3, inspected 27 August 2026. GitHub remains the canonical source for later release changes.
04Governed autonomy
High confidence never bypasses authority.
NeuraOS uses NIST AI RMF's Govern, Map, Measure, and Manage functions and the six principles in NATO's revised AI strategy as public governance references—not as certification badges.
AI may act inside approved constraints
- Detect, classify, summarize, and prioritize inside the approved operating domain
- Recommend or plan within declared geographic, temporal, policy, and resource limits
- Use only approved models, data, tools, interfaces, and device privileges
- Surface uncertainty, conflicts, degraded state, and reasons for refusal
AI may not become its own authority
- Change mission objectives or widen policy, time, geography, identity, or resource boundaries
- Disable watchdogs, safety interlocks, evidence capture, operator override, or safe-state transitions
- Approve its own model, update, privilege, deployment, or operational authorization
- Become the sole authority for a safety-critical, irreversible, or consequential action
05Safety and assurance
Treat every AI workload as fallible.
Primary flight, motion, and emergency-protection loops remain under independently assured deterministic control. Assurance level, separation, and acceptance stay specific to the platform, use case, jurisdiction, and sponsor.
S01
Command arbitration
Validate source identity, freshness, rate, device state, and the allowed command range before execution.
S02
Spatial and temporal limits
Enforce geofences, altitude or speed limits, mission windows, and resource budgets outside the model.
S03
Sensor validity
Reject stale, contradictory, spoofed, or physically implausible observations before they influence control.
S04
Health supervision
Watch deadlines, heartbeat loss, thermal and power limits, memory pressure, and degraded-mode transitions.
S05
Independent override
Provide authenticated operator control, hardware emergency stop where applicable, and a minimum-risk state.
S06
Recovery discipline
Preserve evidence while returning to a last-known-good image, policy, model, or operating state.
Security baselineDevice, workload, update, supply-chain, audit, and resilience controls
- Verified or measured boot with hardware-backed identity where the target supports it
- Minimal, read-only operating image with integrity verification and least privilege
- Unique device and workload identities with deny-by-default authorization
- Segmented, mutually authenticated communications and an explicit offline mode
- Signed model allowlist, provenance, encrypted sensitive storage, and poisoning or spoofing tests
- Signed A/B updates, anti-rollback policy, staged rollout, health confirmation, and recovery
- SPDX or CycloneDX SBOM, VEX, signed provenance, vulnerability triage, and licence inventory
- Time-synchronized, tamper-evident events with retention, redaction, and export controls
- A01
Scope
Declare intended and prohibited use, accountable owner, risk class, operating domain, and safe state.
System boundary · authority · hazard inputs
- A02
Prepare
Review data, model, software, licences, threat paths, and the initial technical baseline.
Lineage · model card · threat model · SBOM
- A03
Validate
Exercise nominal, adversarial, timing, sensor, network, and resource behavior in reproducible laboratory and SIL/HIL tests.
Replay · fault injection · calibration · hazard log
- A04
Authorize
Promote only the signed release whose residual risk, operating limits, training, recovery, and evidence are accepted.
Release manifest · approval · rollback proof
- A05
Operate
Monitor health, drift, incidents, overrides, patches, performance, and evidence expiry under named ownership.
Run history · incident · review date
Current public product record
Start with the operating boundary, not a hardware promise.
The public repository describes product capability, architecture, technology, governance, safety, security, and owned visuals. It does not distribute NeuraOS source code or binary releases, and it does not establish certification, customer deployment, or universal hardware support.