Site knowledge
Maps, dock geometry and operational playbooks associated with the site.
PHYSICAL AINew hardware.
New hardware.
Same memory.
A durable memory foundation for robots, inspection systems and fleets. Preserve site knowledge, calibration records and operational history beyond a single machine.
Physical-AI reference integration · Planned
Observe→Persist→Recover
A PROPOSED SCENARIO
The hardware can change. The knowledge should remain.
The whitepaper proposes a physical-AI memory path for disconnected operation, hardware replacement and operational review. Site knowledge and a unit’s experience have different lifecycles, and both need a place to persist.
EXAMPLE WORKFLOWPhysical AI
USER REQUEST
Start with the question.
A replacement unit is joining the next shift. What context should it recover?
Start with the question.WHAT THE WORKFLOW CAN REMEMBER01 02 03
Unit history
Observations and shift decisions written by the previous unit.
Calibration record
The model identity, offsets and maintenance history relevant to review.
Proposed behaviour from the whitepaper.
THE PROBLEMWhen the context
When the context
doesn’t carry forward.
Knowledge stays on one machine
A reset or hardware replacement can separate the next unit from the context accumulated by its predecessor.
Connectivity is intermittent
Robots and field devices need a way to retain pending observations when the network is unavailable.
Site and unit history get mixed
A shared map and one robot’s shift observations need different scopes and update rules.
THE PROPOSED MEMORY FOUNDATIONKeep what matters.
Keep what matters.
Build on what came before.
01SITE MEMORY
Site knowledge with its own scope
The proposed design separates shared maps, dock geometry and playbooks from a unit’s episodic history. Site knowledge stays associated with the place it describes.
Maps
Dock geometry
Playbooks
02UNIT MEMORY
Experience that can follow the unit
Keep observations and shift decisions in an episodic namespace. The proposed recovery path lets an authorised replacement retrieve written records after a reset or swap.
Observations
Shift decisions
Recovery references
03PROPOSED OFFLINE FLOW
A path through disconnection
The planned on-device buffer holds pending records locally. Opportunistic flush writes incremental batches when connectivity to a gateway returns.
Local buffer
Connectivity returns
Batch + CID
04REVIEW CONTEXT
Operational records for review
Preserve procedural notes, calibration records and model identity. Content-addressed references support inspection of the records written before an incident or maintenance event.
Model identity
Calibration
Incident history
PROPOSED WORKFLOWFrom a new observation
From a new observation
to lasting context.
Buffer on the device
In the proposed integration, hold pending observations locally while the device is disconnected.
Flush when connected
Persist incremental batches when a gateway is reachable and retain the returned CIDs.
Recover and validate
Retrieve written records using the namespace credential; validate their suitability before operational use.
The physical-AI reference integration is planned in the September 2026 whitepaper. On-device buffering, opportunistic flush and site-versus-unit namespaces are near-term work; broader fleet namespaces and bring-your-own storage adapters are later roadmap items.
DESIGN YOUR INTEGRATIONA memory layer.
A memory layer.
Your application’s logic.
Use the proposed architecture to scope a reference integration for your hardware and operating environment.
Read the architecture ↗01
Separate shared site records from unit-specific observations.
02
Keep model identity explicit for procedural and calibration records.
03
Plan local buffering, power-loss handling and reconnect behaviour.
04
Validate recovered records in the robot application before use.
COMMON QUESTIONS
Before you build.
Is the physical-AI integration available today?
The September 2026 whitepaper describes the physical-AI reference integration as planned. On-device buffering, opportunistic flush and site-versus-unit namespaces are near-term work.
Does this replace a robot’s control or safety system?
No. The proposed memory path persists and recovers context. Real-time control, safety enforcement and validation of recovered records remain responsibilities of the device and operator.
What happens while a robot is offline?
The proposed design buffers pending observations on the device and flushes them when connectivity returns. Local buffering needs its own implementation and durability considerations.
Can a replacement recover every recent observation?
Recovery covers records that were successfully written to the network. Observations remaining only in a local pending buffer require a separate recovery path.