The operating-system platform for Physical and Industrial AI.
Each new machine can mean rebuilding model integration, permissions, device interfaces, updates and fleet operations. Which parts should become a reusable platform?
Machine builders, industrial OEMs and robotics platform leads
Permission is not proof of execution. The design keeps AI proposals, machine authority and independent physical protection separate.
An application or model proposes work through the platform API. Identify the machine, intended effect, owner and operating constraints.
Read the alternative outcomes
Permission expires. An expired lease cannot authorise a new action. Re-evaluate the request and current state; expiry is not completion.
Local veto. Preserve the controller’s refusal. The platform cannot overrule it or report execution.
Read back. Verify observed state and retain the journal. Reconcile ambiguity before considering another request; permission alone never proves success.
Designed action path · authority, device control and observed state
Engage now
A scoped architecture review: target machine, integration profile, authority boundary and implementation and qualification evidence to build.
Inspect
Platform design baseline · in development
A platform architecture and component-design baseline covering builds, runtime, authority, hardware interfaces, AI, recording and updates.
Still to validate
The next platform is in design: no implementation, assessed release or deployable product is established by this record. The predecessor’s software and simulation do not validate the next implementation.
Implement and verify the platform baseline, then validate independent interoperability and target hardware before evaluating a bounded field trial.
Source reviewed
The decision behind the system
What should an intelligent machine inherit from its platform?
Auralink is being designed around a Rust-owned core: configurable machine images, AI applications, deterministic on-device authority and vendor interfaces. Local open-weight inference and optional fleet services belong to the same platform design.
The next Auralink design extends beyond coordination into a machine operating system and application platform. Its Rust-owned core, domain packs and optional hub are design work; the predecessor's implementation records remain separate.
A configurable machine platform
The design combines a Linux substrate, Rust-owned runtime, hardware interfaces and permissioned applications, with full-OS and existing-Linux integration profiles.
Bounded authority
AI proposes work. A deterministic on-device service is designed to check identity, policy and current state; independent protective functions retain their own authority.
A lifecycle beyond inference
Recording, replay, model evaluation, signed updates and compatibility checks are planned alongside domain packs and an optional self-hosted fleet hub.
Read the complete system walkthrough
Request
An application or model proposes work through the platform API. Identify the machine, intended effect, owner and operating constraints.
Bound
The on-device authority service is designed to check identity, permissions, policy and state freshness before granting bounded authority.
Act or veto
The device interface must enforce the permitted scope. Local controllers can refuse; the safety island and hardware protective functions have separate responsibilities.
Read back
Observed state and journals must distinguish completion, refusal and ambiguity. Recording and replay support investigation; a permission never proves physical success.
Inspect the source, test conditions and operating limits in the technical record.
Platform architecture · design baseline
One machine platform. From image to intelligent application.
Auralink is being designed as an operating-system platform for Physical and Industrial AI. The next version combines a configurable Linux foundation with a Rust-owned core, a permissioned application model and vendor interfaces. Implementation has not started.
Applications and AI
Permissioned applications and agents, local open-weight inference and policy-selected hosted models. An offline profile is part of the design.
On-device authority
A deterministic service evaluates proposals against identity, policy, permissions and current state. Models and fleet services do not acquire machine authority.
Runtime and device interfaces
The Rust-owned runtime and vendor interfaces connect applications to machine capabilities. The safety-island design and hardware protective functions have independent responsibilities.
Configurable machine image
Kconfig selections, Buildroot images and a real-time Linux foundation define what belongs on each machine. Adopted components remain outside the Rust-owned core.
Build, evaluate, update
The design includes recording and replay, model evaluation and shadow operation, signed updates, compatibility checks and rollback paths. Each needs implementation and verification before release.
Two integration profiles
Full platform OS
The target profile controls the machine image, boot, kernel, updates and runtime. Its guarantees depend on the selected hardware and completed qualification.
Runtime on existing Linux
An integration path for machines that retain their existing OS. It has a narrower control boundary and cannot inherit the full-OS guarantees.
Optional fleet hub
A self-hostable hub is planned for enrolment, identity, tenant boundaries, audit, rollout, data and operator interfaces. Domain back-office modules sit outside the core. Machines are designed to keep local functions available without the hub; it holds no machine-authority keys.
Planned domain packs
A common core. Domain-specific machines.
Four planned domain packs separate protocol and application work from the reusable platform. Each pack needs its own implementation, interoperability and hardware evidence.
EV charging
A planned charging pack for charger interfaces, energy constraints and operator workflows. Optional hub modules cover central-system and back-office responsibilities.
Mobile robotics and robot cells
Robot and fleet interfaces, bounded machine actions and shared-resource coordination. Motion control and physical protection retain explicit owners.
Smart-city infrastructure
A planned pack for infrastructure interfaces and constrained coordination across public assets. Each installation needs its own operational and safety assessment.
Industrial machines and gateways
Industrial interfaces and permissioned applications over a common machine platform. Existing PLC, SCADA and protective-system responsibilities remain explicit.
Pack selection does not establish device support. The target machine, vendor interface and operating environment determine the qualification work.
Explore the technical record and evidence
Business ↔ technology bridge · Physical AI platform design
Keep one product boundary across cloud, edge, devices, and local safety authority.
Connects machine-platform product decisions to a Rust-owned operating-system design and its implementation and qualification plan.
This is a portfolio and source interpretation—not a customer, deployment, certification, or outcome claim.
01
Business pressure
Every new physical-agent vertical can become another bespoke platform, multiplying integration, operations, support, and assurance cost.
02
Product decision
Choose what belongs in the machine platform, domain pack, vendor interface and optional fleet hub, with explicit authority and integration-profile boundaries.
03
Technical record
A design baseline for configurable images, a Rust-owned core, on-device authority, local inference, application permissions, domain packs, signed updates and fleet services.
04
Evidence return
Runtime constraints and validation gaps reopen platform scope, supported-vertical claims, deployment obligations, release decisions, and product economics.
Repository/runtime boundary
This page interprets source from a separate venture repository. Source presence does not make the venture a service running inside hyperion-consulting.io.
Visitor and client-data AI processing is restricted to Mistral through the governed EU endpoint. Owner-authorized Helio, Search and Product Council paths are enabled. A separate public-source editorial lane uses Anthropic with governed Mistral backup; it receives no website enquiries, client documents or visitor conversations. Deterministic tools remain available when remote AI is unavailable.
Source evidence
What the source actually establishes
The next Auralink is a proposed operating-system and application platform for Physical and Industrial AI machines. The reviewed design covers a Rust-owned core, configurable Linux images, deterministic on-device authority, model integration, domain packs and an optional fleet hub.
Maturity
Platform design baseline · in development
Evidence review
Source snapshot through
Architecture and product decisions
Keep model proposals separate from on-device authority and independent physical protective functions.
Separate the reusable platform, vendor interfaces, domain packs and optional fleet services.
Qualify the full-OS and existing-Linux runtime profiles against their different guarantees.
Inspectable evidence
A platform architecture and component-design baseline covering builds, runtime, authority, hardware interfaces, AI, recording and updates.
Domain-pack and optional fleet-hub designs, a predecessor-parity register and a staged implementation and verification plan.
The review inspected design documents; it did not execute venture suites. Earlier Auralink source and simulation records belong to the predecessor, not this platform's implementation.
Claim boundary
The next platform is in design: no implementation, assessed release or deployable product is established by this record. The predecessor’s software and simulation do not validate the next implementation.
No production hardware integration, independent protocol or safety certification, or customer deployment is asserted. Public source availability and licence rights are not granted here.
Implementation, software verification, independent interoperability, hardware-in-the-loop and operational qualification remain required; real hardware is NO-GO until those gates pass.
Repository evidence is not client, deployment, certification, or outcome evidence.
A practical path from question to evaluation.
A practical path from question to evaluation.
Start with one machine, one application and named owners. Establish the implementation and acceptance evidence before considering any physical trial.
01
Frame the opportunity
Select the business outcome, target machine and full-OS or existing-Linux integration profile. Name the product, engineering and operating owners.
02
Map the constraints
Review conflicts, policy, data, hazards, economics and the evidence needed to make a decision.
03
Observe before acting
Plan approved replay data, simulation and read-only observation to evaluate the proposed authority and model boundaries once implemented.
04
Exercise a sandbox
After implementation, test expiry, local veto, ambiguous outcomes, readback and recovery against an authorised virtual interface.
05
Qualify the physical path
Consider hardware-in-the-loop or a bounded pilot only after separate hardware, security, safety and operator gates are met.
Development path: implement, verify, qualify
Implementation and qualification
Design becomes a product through evidence.
The next platform starts from an architecture and planning baseline. Progress depends on implementation and demonstrated behaviour, with separate software, interoperability and physical qualification gates.
01 →
Implement the core
Build the configurable image, Rust-owned runtime, on-device authority and reference interfaces. Verify denial, recovery and update boundaries.
02 →
Evaluate applications
Implement recording and replay, model routing and permissioned applications. Compare model behaviour against task-specific acceptance criteria.
03 →
Prove interoperability
Exercise domain packs and vendor interfaces against independently implemented peers, including failures and degraded operation.
04 →
Qualify one machine
Use target hardware, measured timing, fault injection and named operator acceptance before considering a bounded field trial.
AI proposes. Machine authority decides.
Model output must not grant itself access to an actuator. On-device checks, local controllers and independent protective functions have different roles to verify.
No inherited validation
Earlier Auralink software and simulation results inform the replacement design. They do not qualify the next implementation, its hardware interfaces or any future release.
Earlier Auralink: research and controlled access
These technical documents, source-access paths and authorized research results concern the predecessor. They inform the next design; they do not establish that the new platform is implemented or qualified.
Inspect the predecessor technical record
How It Works
Architecture
Applications propose work through vertical interfaces and shared capabilities to the horizontal coordination runtime. Device, edge and cloud describe where the work runs. The technical reference explains the coordination specification and its EV-charging research lineage.
These documents contain proprietary architecture details, benchmarks, and implementation specifics. A quick NDA protects both parties.
Marketing Whitepaper
Why a coordination plane is the missing primitive for distributed physical AI, and what it is designed to enable across EV / robotics / smart-city / IIoT.
NDA Required
Research Paper
ACS v0.1 — six proposed normative resource types, four safety classes, graceful-taper preemption, federated learning under differential privacy. With the TLA+ formal model.
NDA Required
Technical Whitepaper
Full system architecture across cloud and edge, charger OS in Rust, agent bundle in Go, deployment topology, RAG backbone, and megaproject playbooks as documented design scope.
NDA Required
Source Code
Code Access Agreement
Request access to source repositories and any configured model artefacts under the applicable agreements.
Please sign the NDA first before requesting code access.
GitHub Repository
Sign Agreement to Access
HuggingFace Models
Sign Agreement to Access
Work with Hyperion
Review one machine-platform decision
A scoped architecture review: target machine, integration profile, authority boundary and implementation and qualification evidence to build.
Bring a short description of your situation, constraints and decision. We agree the scope, responsibilities and quote before work begins.