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.
源码审查日期
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.
查看技术记录与证据
业务 ↔ 技术桥梁 · 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.
这是对项目组合与源代码的解读，并非客户、部署、认证或成果声明。
01
业务压力
Every new physical-agent vertical can become another bespoke platform, multiplying integration, operations, support, and assurance cost.
02
产品决策
Choose what belongs in the machine platform, domain pack, vendor interface and optional fleet hub, with explicit authority and integration-profile boundaries.
03
技术记录
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
证据回流
Runtime constraints and validation gaps reopen platform scope, supported-vertical claims, deployment obligations, release decisions, and product economics.
访客及客户数据的 AI 处理限于通过受治理的欧盟端点使用 Mistral。所有者授权的 Helio、搜索及 Product Council 流程已启用。独立的公开来源编辑流程使用 Anthropic，并以受治理的 Mistral 作为备用；该流程不接收网站咨询、客户文档或访客对话。远程 AI 不可用时，确定性工具仍可使用。
源码证据
源码实际能够证明什么
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.
详细技术快照以英文维护。
成熟度
Platform design baseline · in development
证据审查
源码快照截至
产品与架构决策
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.
可核验的证据
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.
声明边界
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.
代码仓库证据不等同于客户、部署、认证或成果证据。
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
工作原理
架构
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.