Open core · MIT Zero cloud calls Supervisor on separate silicon

Deterministic edge intelligence for robots.

Adaptive control that runs on the robot, passes every command through a supervisor on separate silicon, and never opens a network socket.

View the core on GitHub How a pilot works

Every figure on this site is a bench measurement with a date, or it is a dash. We do not publish estimates as specifications.

EDGE CONTROLLER · 2 LAYERSdatasheet · rev 0

reflex layer · targetMCU class · part pending bench

adaptation layer · targetSoC with in-package DRAM · part pending

power, steady state— pending bench

step time · worst case— pending bench

RAM · reflex layer— pending bench

RAM · adaptation layer— pending bench

heap allocations per step— target zero, pending

determinism, 100× replay— pending bench

network egress0 bytes · by design

supervisorindependent · deterministic

measured pending safety layer

SANDBOXobstacle avoidance

drag the obstacle into the robot's path →

decision tracelive

NET0 B SUPERVISORidle COREcruise POWER— pending RAM— pending

The sandbox runs a reactive stub so the interface — sensor in, proposal, supervisor check, motor out — can be tried today. The learning core compiled to WebAssembly replaces the stub when the public build lands. The trace format is the real one.

The problem

A data-center brain on a warehouse cart.

Robot foundation models are built for high-level intent: read the scene, decide what to do next. They run at a handful of decisions per second on a compute module costing hundreds of dollars and drawing tens of watts. That is a fair trade for planning. It is the wrong trade for the loop that has to close hundreds of times a second to stop a machine slipping, drifting or hitting something.

We work in that second loop — and not instead of what is already there. A well-tuned PID or an MPC controller solves the modelled case, and solves it properly. We add the part that adapts to what the model never contained: gearbox wear, a drifting cheap sensor, the character of this particular machine, a floor that got mopped ten minutes ago.

Two layers, two kinds of silicon

Reflex layer — microcontrollerobstacle avoidance · traction · supervisor

Adaptation layer — SoC, DRAM in packagetask memory · pattern store · consolidation

For contrast — GPU compute modulehundreds of dollars · tens of watts

relative, not to scalecost and power per layer: pending bench

Two layers, not one big chip

Reflexes and the supervisor live on a microcontroller. Task memory and adaptation live on a small SoC with its DRAM inside the package — a single package with no external memory to route, around a watt, no heatsink, no fan.

Which parts, and how much: measured before published.

Same input, same output

Decisions are reproducible. Record inputs, replay a hundred times, compare action hashes. That is how we test it and how an assessor can too.

Cross-architecture identity is on the bench plan.

Zero bytes leave the robot

The runtime opens no sockets. Learning happens on the device and is frozen into a versioned configuration before shipping.

No cloud dependency to certify, audit or lose.

Architecture

Memory, learning and supervision are separate things.

The core is built after the brain, and its internal module names reflect that. Each block below is shown with its internal name and its engineering meaning.

task compiler

Input filter

Filters raw sensor signals and compiles a task representation. Nothing downstream ever sees unfiltered input.

hippocampus

Working memory of task maps

Builds a topological map of the current task in real time and holds several tasks at once, in RAM. Footprint depends on the task and is measured, never assumed.

neocortex

Long-term pattern store

Matches working-memory maps against stored patterns. New structure is created only in learning mode, from a fixed pool allocated at start-up. When the pool is full it evicts by a documented rule and raises a flag — it never degrades silently. Frozen mode adds nothing.

cerebellum · sleep mode

Offline consolidation

Runs while the robot is idle or charging. Removes spurious connections, strengthens consistent ones, keeps the footprint bounded over years of operation rather than growing without limit.

outside the core

Deterministic supervisor

A small readable rule set that every proposed action must pass: velocity and acceleration limits, minimum distances, forbidden actions. It does not learn, it is not modulated by anything inside the core, and it is the part of the system an assessor reads.

runtime · erlang-style supervision trees

Fault isolation

A failed sensor process restarts without touching motor state. Failures are contained to the subtree they happen in, rather than taking the control loop with them.

Functional safety

Two loops. Only one of them learns.

A learning system cannot be certified. A learning system whose every output passes a deterministic supervisor can be assessed — because the supervisor is what the assessor reads.

SAFETY ENVELOPE · deterministic · outside the learning loop

What gets assessed

The supervisor: a bounded rule set with no learned parameters. The adaptation layer only proposes and holds no authority. How the supervisor is scoped for assessment is being defined with a functional-safety specialist — nothing here is a certification claim.

Independence

The supervisor runs on the reflex microcontroller, not on the chip that learns. Separate silicon, its own sensor path, its own watchdog. A fault in the adaptation layer cannot corrupt it, hang it or relax a limit — a hardware property, not a promise about software discipline.

Why the split exists

For ISO 13849 categories 3 and 4, separation implemented purely in software on a single core is not accepted: one fault can take both channels with it. Splitting the layers across two parts is what makes the architecture assessable at all.

No allocation in the loop

Memory is taken once at start-up from a fixed pool with a ceiling you set. Nothing is allocated while the control loop runs — standard practice for safety-related code, and the reason the timing is bounded rather than hopeful.

Flight recorder

Decisions go to a RAM ring buffer, flushed to flash only on an emergency stop or a supervisor veto. Buffer size: pending bench.

Traceability

Every command carries the sensor context, the proposal, the verdict and the reason. Readable by a person, not a heat map.

Learning modes · a shipped robot is not a robot that keeps changing

Specifications

Every number here is a measurement, or it is a dash.

Green values are measurements with a date. Grey dashes are not measured yet. The controller table is grey today, and we would rather ship it grey than ship it wrong. The first numbers we do have are from the core itself, on math tasks — shown separately below, so nobody mistakes them for a robot.

One row deserves a note. Step time is reported as a worst case, not an average: in a real-time loop the average is decoration, and what decides whether a machine stays stable is the longest step under the heaviest load.

KINETONICS EDGE CONTROLLER · REFLEX + ADAPTATIONrev 0 · bench pending · last update 15.09.2026

reflex layer · part—

adaptation layer · part—

power, steady state—

power, peak—

step time · median—

step time · worst case (WCET)—

RAM · reflex, frozen—

RAM · adaptation, learning—

flash footprint—

ring buffer—

heap allocations per step— target zero

determinism, 100× replay—

network egress0 bytes · by design

external dependenciesnone at runtime

supervisorseparate silicon · deterministic

core licenceMIT

measured or true by construction pending bench safety layer

CORE VERIFICATION RUN · 48 HETEROGENEOUS MATH SUBTASKSauthor's workstation · 15.09.2026 · not robot control

training, all 48 subtasks15–20 s · CPU, no GPU

reload from saved state0.1 ms

balanced accuracy · 10,000 held-out99.20–99.26%

learned state file, all 48≤ 1 MB

catastrophic forgetting0%

buildRust + ISPC · x86 and ARM

A PC-class run of the core on abstract tasks. Controller rows above — step time, WCET, RAM per layer, power — come only from the robot bench.

Foundation-model stackKinetonics

computeGPU compute module on board, hundreds of dollars, tens of wattsTwo layers: a microcontroller for reflexes and a low-power SoC with memory in the package for adaptation — parts and cost pending bench

powerTens of watts, active cooling, heat into the batteryAround a watt per layer · design target — pending bench

auditStatistical model; decisions are not reproducibleSame input, same output. Every command passes a readable supervisor

adaptationRetrain in the cloud, redeploy the fleetLearns on the device, then freezes into a versioned configuration

connectivityCloud dependencies, external APIs, telemetry egressNone. The runtime opens no sockets

wet floorOdometry error propagates into SLAM; emergency stop; manual resetSlip estimated from IMU and encoders, torque adapted — latency pending bench

failure modeModel does something unexplained; nobody can reconstruct whyRing buffer holds the last decisions; flushed on veto or E-stop

Applied · traction

Ask an AMR operations lead what actually breaks navigation.

They will not say SLAM. They will say the floor. Somebody mopped aisle four, the wheels slip, the encoders report two metres while the robot moved one point two, localisation drifts, the robot stops and waits for a human.

Comparing IMU against encoders in a fast loop gives a slip estimate, and torque can be adapted before odometry poisons the map. This is the traction control every car has had for thirty years, applied to the layer of the robot where nobody put it.

Loop rate and reaction time are design targets until measured on a bench. They will appear here as numbers, with a date, or not at all.

encoder-reported distance true distance from IMU fusion supervisor / torque adaptation

Illustrative shape of the failure, not recorded data.

Integration

The coprocessor does not touch your motors until you say so.

A board next to your existing stack. It reads what your robot reads, records what it would have done, and stays in read-only until you have read the report.

Alongside your stack

Connects to your CAN or ROS 2 bus in parallel with Nav2 or your own planner. Your software is not modified.

Shadow mode

The coprocessor only reads sensors and writes decisions to a buffer. Motors stay with your stack for the whole pilot.

Diff report

Every decision where the two stacks disagreed, with sensor context and the supervisor's verdict. Numbers come from your robots, not our brochure.

Handover

You enable motor output only after reviewing the report and setting the supervisor limits yourself.

Developers

Run the core in one command.
Public build in preparation.

The core and its abstract benchmarks are open under MIT. Hardware adapters, the supervisor toolchain and target builds are licensed separately.

# clone and run the obstacle-avoidance example
$ git clone https://github.com/kinetonics/core
$ cd core
$ cargo run --release --example obstacle_avoidance

# C ABI header and static library
$ git clone https://github.com/kinetonics/core
$ cd core && cargo build --release --features c-abi
# headers in target/include, library in target/release

# ESP-IDF component, target build (licensed separately)
$ idf.py add-dependency "kinetonics/core"
$ idf.py set-target esp32s3
$ idf.py build flash monitor

x86-64 host — pending WebAssembly — pending STM32H7 — pending ESP32-S3 — pending NXP i.MX RT — pending adaptation SoC — pending

A target becomes a solid badge only once a build runs on it and the numbers on this page come from it.

Contact

Two conversations, two doors.

Robot manufacturers and integrators

Planning a new AMR line, or trying to take cost and heat out of an existing fleet? A shadow-mode pilot runs on your robots, in your facility, without touching your control stack. Pilot slots open soon.

Join the pilot list

Investors

The counter-trend to GPU scaling in physical AI. The same core ships first in games, as Actorics. The thesis, the bench plan and the open questions are in one document — including the questions we have not answered yet.

Request the pre-seed memo