Site knowledge
01Maps, dock geometry and operational playbooks associated with the site.
Persistent memory
for physical AI.
A proposed memory integration for robots and devices. Preserve written site knowledge and operational records across shifts and hardware changes.
Planned reference integration PROPOSED WORKFLOWPhysical AI
Operations agentPrepare a replacement unit
Context starts here
The next response starts with what your agent already knows.
LIGHTHOUSE MEMORY03 RECORDS
Operational context
Unit history
02Observations and shift decisions written by the previous unit.
Calibration record
03The model identity, offsets and maintenance history relevant to review.
Context available to recall
Reference scenario for a planned integration. An operator validates recovered records before use.
34,000Builders on Lighthouse
Saved context.
Available to connected applications.
THE PROBLEMWhat gets lost
What gets lost
between sessions.
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 FOUNDATIONWhat an agent’s brain
What an agent’s brain
could remember.
The proposed integration separates shared site records from each device’s observations. It covers local buffering, network writes and recovery for operator review.
Separate shared site records
The proposed design keeps maps and operating instructions separate from device observations. Shared records stay associated with their site.
Retain device history
Save observations and shift records for each unit. A replacement could recover successfully written records for operator review.
Buffer while offline
The planned integration holds pending records on the device, then writes batches when a gateway becomes reachable.
Keep operational records for review
Save model identity, calibration notes and maintenance history. Operators must validate recovered records before using them.
PROPOSED WORKFLOWHow the workflow
How the workflow
uses memory.
Buffer locally, write when connected, then recover and validate the records.
- 01
Buffer on the device
In the proposed integration, hold pending observations locally while the device is disconnected.
- 02
Flush when connected
Persist incremental batches when a gateway is reachable and retain the returned CIDs.
- 03
Recover and validate
Retrieve written records using the namespace credential; validate their suitability before operational use.
WHAT LIGHTHOUSE PROVIDES
The physical AI reference integration is planned. Device buffering, reconnect behaviour and recovery need integration work. Only successfully stored records can be recovered from the network.
IMPLEMENTATIONSet up the records.
Set up the records.
Connect your application.
Choose what to store, how to retrieve it and which checks your application must perform.
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 QUESTIONSBefore
Before
you build.
Is the physical-AI integration available today?
The physical-AI reference integration is planned. On-device buffering, opportunistic flush and site-versus-unit namespaces still require integration 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.
