01 · Overview
An operating layer for edge AI.
Furcate is the layer above the operating system and below the application. On Linux- and Android-class devices it runs as a userspace runtime. On microcontrollers it ships as firmware. Across both, it provides the same primitives: peer-to-peer mesh, multi-modal ingestion, on-device intelligence, and a sovereignty/control plane.
Furcate does not replace the open stacks the industry already runs on. It joins them. The integrations on this page are verifiable and concrete — companion computer next to PX4, ROS 2 node on a Jetson, container under SOAFEE, application on NASA cFS, firmware library on ESP32.
02 · Hardware
Four anchors. One platform.
Furcate runs on four anchor families that together cover the working span of edge deployment — from a $5 microcontroller in a sensor to a multi-GPU workstation in a substation.
NVIDIA Jetson
Edge AI class
Server-grade models on-site. Furcate runs as a Linux userspace runtime on JetPack, using CUDA, TensorRT and the Jetson media stack where the workload needs them. Used on vehicles, in substations, on factory lines, and now in orbit.
Raspberry Pi
Field class
The single-board workhorse of the field. Furcate runs as a Linux userspace runtime on Raspberry Pi OS or any aarch64 Linux. Vision, audio and language models on the wall — recognising what they see without uploading it.
Arduino
Sensor class
Furcate ships as a library for the Arduino core on Arm Cortex-M MCUs. Sensors, actuators, and small ML models at the perimeter. Joins the mesh via BLE, LoRa or Wi-Fi depending on the board.
ESP32
Sensor class
The high-volume firmware target. Furcate runs on FreeRTOS via the ESP-IDF SDK. Native Wi-Fi and BLE on every variant; LoRa via SX127x / SX126x shields. Designed for fleets in the thousands per site.
03 · Substrate
Linux and Android, with a firmware path for MCUs.
The Linux-class anchors (Jetson, Raspberry Pi, and the broader server/SBC family) host Furcate as a userspace runtime. The supported kernels include mainline Linux on aarch64 and x86_64, the Jetson BSP/JetPack family, Yocto-based builds for embedded Linux, and AOSP (Android Open Source Project) where Android is the host — including Android Automotive.
The MCU-class anchors (ESP32, Arduino, STM32) host Furcate as firmware. The supported real-time environments include FreeRTOS, Zephyr, NuttX, and bare-metal builds. On flight-grade silicon, Furcate additionally targets RTEMS, VxWorks and QNX — see Space.
For appliance-class builds — network gateways, routers, field hubs — Furcate also targets OpenWrt. Buildroot is supported alongside Yocto for image generation where a smaller footprint is required.
04 · Connectivity
The radios and buses the mesh runs over.
Furcate’s peer-to-peer mesh is link-agnostic. Devices on a site can be connected over any combination of the following, simultaneously, with store-and-forward across links when one drops.
Wi-Fi
Wireless · high bandwidth
The primary link on every Linux-class anchor and on ESP32. Used for high-throughput peer-to-peer between Furcate nodes on a site — video, audio streams, model deltas, telemetry.
Bluetooth / BLE
Wireless · short range
Short-range mesh for low-power sensors, device pairing, and zones where Wi-Fi is congested or unavailable. Native on Jetson, Raspberry Pi and ESP32; via module on Arduino.
LoRa
Wireless · kilometre range
Kilometre-range, low-bandwidth backbone for sites where Wi-Fi can’t reach — agriculture, utilities, distributed sensors. Furcate uses the radio directly (SX127x / SX126x) rather than going through LoRaWAN, so devices remain peers on the mesh.
Wired buses
Embedded · deterministic
CAN, CAN FD, UART, SPI, I²C, RS-485, Ethernet. Used between MCUs, between an MCU and its host Linux board, and as the deterministic side of a vehicle or instrument.
Private 5G & O-RAN
Wireless · fleet scale
For fleets that span a campus, a port, a quarry, or a battlefield, Furcate operates over private 5G and O-RAN deployments. Nodes are addressable as peers inside a 3GPP network slice (TS 23.501), and Furcate’s mesh runs unchanged on top of the slice. Compatible with O-RAN Alliance fronthaul/midhaul splits.
05 · Inference runtimes
The model layer Furcate runs underneath.
Furcate is the platform, not a model framework. The actual inference is executed by the runtime that best fits the device and the model — Furcate places it, signs it, and observes it.
ONNX Runtime
Cross-vendor · Linux & MCU
The cross-vendor lingua franca for inference. Furcate uses ONNX Runtime for models that need to run unchanged across NVIDIA, Intel, Arm and accelerators like Coral and Hailo, with vendor execution providers wired in where available.
LiteRT
On-device · mobile & MCU
Google’s rebrand of TensorFlow Lite. Furcate uses LiteRT for on-device inference on Android, Linux SBCs, and through LiteRT for Microcontrollers on the MCU class.
NVIDIA TensorRT
Jetson · server class
On Jetson and on the on-prem GPU server tier, Furcate compiles models through TensorRT where the workload benefits — INT8/FP8 quantisation, CUDA kernels, and the Jetson media stack for vision pipelines.
OpenVINO
Intel CPU · iGPU · NPU · VPU
On the Intel NUC anchor and Meteor Lake / Lunar Lake class devices, Furcate uses OpenVINO to run models on the Intel iGPU and on-chip NPU. Also the path for Movidius VPU-class accelerators in cameras and industrial sensors, and the reference back end behind WASI-NN.
llama.cpp
LLMs · GGUF · CPU & GPU
The reference runtime for running Llama, Mistral, Qwen, Phi, Gemma and other open-weight LLMs on the edge. Furcate uses llama.cpp for on-device language inference in GGUF format across CPU, CUDA, Metal and Vulkan — from a Raspberry Pi 5 up to an on-prem GPU server. Quantised models down to 2-bit fit on field-class hardware.
Apache TVM
Compiler · portability
Used where a model needs to be compiled to a target Furcate already runs on but a vendor runtime doesn’t reach — including RISC-V silicon and custom accelerators.
06 · WebAssembly
A portable execution surface, from MCU to server.
Furcate uses WebAssembly as a portable execution surface for application logic and model glue across the fleet. A function compiled once runs the same on a Jetson, a Raspberry Pi, and an ESP32-S3 (via Wasm-on-MCU runtimes). Sovereignty is preserved at the runtime boundary — Wasm modules are sandboxed by default and capability-scoped.
Inference inside the Wasm sandbox uses WASI-NN, the standardised neural network interface that lets a single module call hardware-backed inference (ONNX Runtime, OpenVINO, TensorFlow) wherever it’s deployed. For orchestration of Wasm workloads across a Furcate fleet, wasmCloud, Spin and WasmEdge are supported control surfaces.
- WebAssemblyBytecode Alliance · W3C
- WASI-NNneural net interface
- wasmCloudCNCF
- SpinFermyon
- WasmEdgeCNCF
07 · Integrations
How Furcate plugs into the stacks the industry runs.
Each section below names the open frameworks and protocols Furcate connects to, the deployment pattern, and the hardware anchors involved. Every surface named here is public and verifiable.
Integration
Embedded devices.
On the MCU class, Furcate is firmware. It runs on FreeRTOS, Zephyr, NuttX or bare metal, shipped as a library against the vendor SDK (ESP-IDF for ESP32, Arduino core for Arduino-class boards, STM32Cube / Zephyr for STM32). Devices speak to the rest of the fleet over BLE, LoRa or Wi-Fi, and to their local peers over CAN, UART, SPI or I²C.
Where the surrounding ecosystem expects it, Furcate additionally speaks micro-ROS (for ROS 2 environments — see Robotics) and OpenCyphal (for vehicle and avionics buses — see Drones & UAS).
- FreeRTOSprimary RTOS target
- ZephyrLinux Foundation RTOS
- ESP-IDFESP32 SDK
- Arduino coreCortex-M boards
- micro-ROSMCU-class ROS 2
- OpenCyphalintravehicular bus
Integration
Drones & uncrewed systems.
Furcate runs on the companion computer next to the autopilot — the standard pattern across the open drone industry. The autopilot keeps flying; Furcate handles perception, decision and coordination with the rest of the fleet.
PX4 (Linux Foundation, Dronecode) is the primary open autopilot target. Furcate commands the vehicle via MAVLink using MAVSDK or offboard mode, and consumes telemetry the same way. On the deterministic side of the vehicle — actuators, ESCs, smart sensors — Furcate speaks OpenCyphal over CAN FD.
- PX4Linux Foundation · Dronecode
- MAVLinkMAVSDK · offboard mode
- OpenCyphalCAN FD · Ethernet
- Jetson · Picompanion computer
ArduPilot follows the same companion-computer and MAVLink pattern. Commercial PX4 distributions — including Auterion for defence — integrate through the same surfaces.
Integration
Robotics.
Furcate is a first-class ROS 2 node. It publishes and subscribes ROS 2 topics, advertises and calls services, and participates in the DDS data fabric like any other node — on full robots over Cyclone DDS or Fast DDS, and on microcontrollers over micro-ROS. No exotic adapter, no parallel runtime.
On a typical robot, Furcate runs on the Jetson or Pi that already hosts the higher-level ROS 2 graph, while micro-ROS nodes on ESP32 or STM32 join the same graph from the sensor side.
- ROS 2Apache 2.0
- micro-ROSMCU class
- DDSCyclone · Fast
Integration
Autonomy.
Autonomy — the perception, planning and control loop — cuts across drones, robotics and vehicles. Furcate runs as a node inside the open autonomy stacks the industry has built, rather than shipping its own.
The reference open stacks are Autoware (Autoware Foundation; the open-source self-driving framework adopted across automotive and shuttles), Apollo(Baidu’s open autonomous driving platform), and Nav2(the navigation framework for ROS 2 robots). Furcate joins each of these as a ROS 2 / CyberRT node.
On the safety and conformance side, Furcate is built to operate within the standards an autonomy programme has to satisfy: SAE J3016 for the autonomy levels, ISO 26262 for functional safety, ISO 21448 (SOTIF) for the safety of the intended function, UL 4600 for the safety case, and UNECE WP.29 R155 / R156 / R157 for cybersecurity, software update management, and ALKS.
For verification, Furcate connects to the open simulation surfaces: CARLA for the runtime, and ASAM OpenSCENARIO + OpenDRIVE as the scenario and road description formats. For vehicle-to-everything coordination, Furcate speaks C-V2X and 5G NR-V2X (3GPP Release 16/17).
- AutowareAutoware Foundation
- ApolloBaidu · CyberRT
- Nav2ROS 2
- CARLAsimulation
- ASAM OpenSCENARIOscenario format
- ASAM OpenDRIVEroad description
- C-V2X · NR-V2X3GPP
Integration
Automotive & SDV.
Furcate is the kind of workload SOAFEE (Arm + Linux Foundation) was designed to host: a containerised edge runtime on automotive-grade Arm SoCs, orchestrated cloud-native on the vehicle. The open reference implementation is EWAOL.
On the data side, Furcate ingests and emits COVESA VSS (Vehicle Signal Specification), so telemetry, sensor readings and command surfaces are portable across OEMs without schema rewriting.
In the cabin, Furcate runs on the Android Automotive (AAOS) partition. It reads vehicle state through the Vehicle HAL (VHAL), and exposes inference and decisions to the infotainment stack through Car Service APIs.
Where vehicles use Adaptive AUTOSAR, Furcate interoperates through standard ARA::COM service APIs — interoperable, though not open-source.
- SOAFEEArm · Linux Foundation
- EWAOLopen reference impl
- COVESA VSSsignal schema
- Android AutomotiveVHAL · Car Service
- Adaptive AUTOSARARA::COM · interop
Integration
Space & satellites.
Furcate is delivered as an application on the NASA Core Flight System (cFS) software bus — the same pattern NASA uses for guidance, navigation and command-and-data-handling apps. cFS is the open flight-software framework behind Intuitive Machines, Blue Origin, and a growing share of NewSpace primes.
On CubeSats, SmallSats and instruments, Furcate runs as an F´ (F Prime)component — NASA JPL’s open C++ component framework — or alongside it on the same Linux board. Jetson-class compute is increasingly used in orbit, and that’s the same Linux target Furcate already runs on at ground level.
- NASA cFSApache 2.0
- F´ / F PrimeNASA JPL
- Linux · RTEMSflight OS
- VxWorks · QNXflight OS
Integration
Industrial & manufacturing.
On the factory floor and in process industries, Furcate joins the established industrial data fabric. The primary surface is OPC UA — the IEC 62541 standard that every modern PLC, robot controller and MES speaks. For deterministic real-time work, Furcate runs OPC UA over TSN (Time-Sensitive Networking, IEEE 802.1Q/AS), so the same wire carries control traffic and AI inference without one starving the other.
Furcate ingests and emits OPC UA Companion Specifications for the relevant verticals — Robotics, Machinery, Pumps, Process Automation — so models are portable across the floor without bespoke gateways. Plant hierarchy follows ISA-95; cell-level twins follow ISO 23247 and the Asset Administration Shell (IDTA) so each asset has a verifiable digital representation that Furcate can attest to and update.
- OPC UAIEC 62541
- TSNIEEE 802.1Q/AS
- OPC UA CompanionRobotics · Machinery
- ISA-95plant hierarchy
- ISO 23247digital twin
- AASAsset Administration Shell · IDTA
Integration
Energy & grid.
In the substation, the windfarm and the rooftop, Furcate operates inside the published power-system protocols. IEC 61850 is the substation-automation standard — GOOSE for breaker-class messaging, MMS for SCADA-class data, Sampled Values for protective relays. Furcate runs as an IEC 61850 logical node where the substation permits it, and observes the bus otherwise.
On the distributed-energy-resource side, Furcate speaks IEEE 2030.5 (Smart Energy Profile / CSIP) — the standard for utility-to-DER communication used in California Rule 21, the Australian CSIP-AUS mandate, and the Hawaii Rule 14 programme. For demand response and grid services, Furcate also speaks OpenADR 3.0.
- IEC 61850substation automation
- IEEE 2030.5DER · CSIP
- OpenADR 3.0demand response
- Modbus · DNP3legacy interop
Integration
Defence.
Furcate joins defence platforms through the same pattern it uses everywhere else — a node on the published bus. On uncrewed systems, that bus is STANAG 4586(NATO’s standard for UAS command and control across coalition forces). On crewed ground vehicles, it is STANAG 4754 / NGVA (the NATO Generic Vehicle Architecture, which mandates DDS for the data fabric — the same fabric Furcate already runs on through ROS 2).
On manned airborne platforms, Furcate aligns with the FACE ConsortiumTechnical Standard (Future Airborne Capability Environment) — the US Department of Defense’s portable avionics software architecture, which likewise mandates DDS for data distribution. Sovereignty guarantees (signed artefacts, on-site keys, attestation) are designed against the assumption that the operating environment is contested.
- STANAG 4586UAS C2
- STANAG 4754 · NGVAground vehicles
- FACEairborne · DoD
- DDS-Securityfabric
Integration
Smart spaces.
In homes, buildings and small sites, Furcate uses Matter (CSA, the Connectivity Standards Alliance) as the device interoperability layer and Thread as the low-power wireless mesh that carries it. Matter is the industry-wide settlement of the consumer-IoT protocol wars; Thread is the IPv6-based mesh underneath. Together they let Furcate orchestrate lighting, climate, sensors and access devices from any major vendor without per-vendor adapters.
For commercial buildings, Furcate additionally interoperates with BACnet and KNX through the same gateway pattern used in industrial sites.
- MatterCSA
- ThreadThread Group
- BACnetcommercial buildings
- KNXbuilding automation
Integration
Healthcare.
In a hospital, a clinic or a connected medical device, the open data surface is HL7 FHIR — the standard for clinical data exchange and, increasingly, device-level interoperability through the Caliper FHIR Accelerator. Furcate reads and writes FHIR resources at the edge so on-site inference participates in the clinical record without copying patient data into a third-party cloud.
Where Furcate is part of a regulated medical device, it is built to operate under IEC 62304 for medical-device software lifecycle and to align with IEC 82304-1 for health software products. Data residency, attestation and the audit ledger are designed for HIPAA / GDPR contexts by default.
- HL7 FHIRclinical data
- IEC 62304medical software lifecycle
- IEC 82304-1health software
08 · Security & trust
Sovereignty backed by verifiable artefacts.
Sovereignty is not a slogan; it is a chain of signed, attested, auditable artefacts that runs from the model file to the silicon. Every guarantee Furcate makes about keys, data residency and the ledger is underwritten by the surfaces below.
Software supply chain
Every Furcate artefact ships with an SBOM in both SPDX and CycloneDX formats, and a SLSA provenance attestation. Build provenance and release signatures are produced through sigstore and in-toto, the standards behind GitHub’s native artefact attestation. Model files travel under the same regime — a model deployed to a device is a signed, provenance-bound object, not a blob.
Confidential compute & device attestation
On the silicon, Furcate uses the confidential compute features the hardware exposes: Arm CCA Realms on Armv9 SoCs, Intel TDX on Xeon-class servers and Meteor Lake / Lunar Lake clients, AMD SEV-SNP on EPYC, and NVIDIA Confidential Compute on Hopper and Blackwell GPUs. A Furcate fleet can require remote attestation before a node receives a model, a key or workload.
Post-quantum cryptography
Edge fleets ordered today will outlive classical cryptography. Furcate supports the NIST PQC suite end-to-end — FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures — alongside classical algorithms in hybrid mode, in line with NSA CNSA 2.0 guidance for long-life devices.
OTA & device lifecycle
Updates follow SUIT (RFC 9019 / RFC 9124), the IETF standard for signed firmware and software update manifests for constrained devices. Every update is signed, every device supports A/B rollback, every key can be rotated and ultimately destroyed on decommissioning. Larger Linux-class anchors additionally interoperate with Mender and RAUC where those tools are already in place.
Robotics & middleware security
The ROS 2 / DDS surfaces named on this page run under DDS-Security (OMG) with the authentication, access-control and crypto plugins enabled, exposed through SROS2. The fleet is not just interoperable — it is mutually authenticated.
Observability
Telemetry from a Furcate fleet is emitted through OpenTelemetry — traces, metrics and logs in a single standard format that any modern operations stack can consume. On Linux-class anchors, Furcate uses eBPF for low-overhead kernel-level observability without shipping a fork of the kernel.
- SBOMSPDX · CycloneDX
- SLSAbuild provenance
- sigstore · in-totosigning
- Arm CCA · Intel TDXconfidential compute
- AMD SEV-SNP · NVIDIA CCconfidential compute
- FIPS 203 / 204 / 205PQC
- SUITRFC 9019 · OTA
- DDS-Security · SROS2middleware
- OpenTelemetry · eBPFobservability
09 · Governance & compliance
Designed for the regulatory shape of 2026.
Furcate is built to be operable under the AI governance regimes institutional buyers actually face. The platform doesn’t make legal claims on a customer’s behalf — it provides the evidence and the controls that an internal compliance team needs to make those claims.
EU AI Act
High-risk AI obligations under the EU AI Act become fully applicable on 2 August 2026. Furcate’s attestation, audit ledger, data-residency guarantees and model-provenance surfaces are designed to satisfy the technical-documentation, logging, transparency and human-oversight requirements of high-risk system providers and deployers.
NIST AI Risk Management Framework
Furcate’s controls map to the four functions of the NIST AI RMF — Govern, Map, Measure and Manage. The audit ledger and SBOM surface the artefacts that an AI RMF profile requires; the sovereignty guarantees address the Trustworthy AI characteristics directly.
ISO/IEC 42001
For organisations seeking certification of their AI management system, Furcate is built to be operable within an ISO/IEC 42001 AIMS — providing the runtime evidence (logs, attestations, model provenance) that an audit requires without leaving the customer’s perimeter.
- EU AI Actapplies 2 Aug 2026
- NIST AI RMFGovern · Map · Measure · Manage
- ISO/IEC 42001AIMS
10 · Interoperable standards
Furcate is proprietary at its core and committed to open source and standards.
The Furcate runtime is proprietary. Every integration on this page exists because Furcate is committed to the open frameworks and protocols the industry has built — PX4, ROS 2, NASA cFS, F´, micro-ROS, OpenCyphal, SOAFEE/EWAOL, COVESA VSS, Android Automotive — and contributes to them as a peer, not as a replacement.
Some of the standards relevant to institutional deployment are themselves not open source: the specification or runtime is licensed by a standards body or a third-party vendor. Furcate interoperates with them through the published service interfaces. Naming them here keeps the distinction clear.
ECSS
European Cooperation for Space Standardization
ECSS specifications are published but require registration and licensing. Furcate is built to operate in alignment with ECSS, while the standards documents themselves are not freely redistributable.
Adaptive AUTOSAR
Automotive standard · commercial implementations
A standard, with commercial runtime implementations provided by Vector, ETAS, Elektrobit and others. Furcate interoperates with Adaptive AUTOSAR SoCs through standard ARA::COM service APIs.
OpenMBEE
NumFOCUS · model-based engineering
Open-source itself, used by JPL and large research facilities. Relevant to Furcate as a traceability and reference surface for institutional buyers rather than a runtime integration.