Physical AI & Robotics · architecture

Target architecture

One modular stack, not a collection of demos. Probabilistic layers propose; deterministic layers refuse. The column “today” says where each layer exists — or that it does not.

PERCEIVE
MODEL
PLAN
ACT
VERIFY
RECOVER
LEARN

Layers a register entry occupies today are named beside it; hatched means nothing in the cluster occupies that layer yet. The bracket marks the deterministic gate.

Stack

Layer	Nature	Role	Today
01 Perception	probabilistic — may propose	Sensor fusion, detection, tracking, uncertainty.	robot-lidar-fusion 0.4.0 (projection, calibration, occlusion).
02 World model	probabilistic — may propose	Scene state, object poses, pallet state, uncertainty over both.	Pallet state in palletizer planning; scene model not built.
03 Task planner	probabilistic — may propose	Order sequencing, pattern selection, mixed-SKU placement.	palletizer optimizer, MissionPlanner, PatternManager.
04 Motion planner	probabilistic — may propose	Collision-free trajectories for the chosen placement.	MotionController tests exist; no planner benchmark.
05 Simulator	deterministic — may refuse	Executes the plan in physics before any actuator moves.	core/simulation (OPC UA robot mock) and browser Rapier demos; KPI harness pending.
06 Safety / constraint engine	deterministic — may refuse	Refuses anything outside limits. Cannot be argued with by a model.	HazardManager, FaultDetector; authorisation boundary by contract with NeuralBridge.
07 Robot controller	deterministic — may refuse	Vendor SDK or ROS 2 driver behind the RobotInterface.	RobotInterface abstraction; a UR bridge and ROS 2 bridge examples; no certified vendor driver.
08 Actuation	physical	Arm, gripper, conveyor.	None owned. Simulation first.
09 Telemetry	telemetry	Every cycle, fault and intervention as a typed event.	CommunicationInterface publishes telemetry; KPI schema on /palletizer.
10 Failure analysis	telemetry	Classify every failed pick and intervention by cause.	Not built.
11 Learning	probabilistic — may propose	Improve planners from telemetry; never touch safety limits.	Not built. Research program on /research.

Safety gate

Every physical action passes all six steps. A model may participate in PLAN; from SIMULATE onwards the steps are deterministic and the model has no say. Authorisation is a human or a certified runtime, recorded with provenance. No LLM or learned model may bypass safety controls, command an unrestricted actuator, modify a safety limit without authorisation, or silently modify production behaviour.

PLAN
SIMULATE
VALIDATE
AUTHORIZE
EXECUTE
VERIFY

Agent tool	Allowed	Note
`generate_plan`	yes	Propose a pallet plan or inspection plan. Output is a candidate, not a command.
`analyze_scene`	yes	Read perception output and describe it.
`propose_action`	yes	Enter the gate at PLAN. Nothing after VALIDATE is reachable from here.
`retrieve_procedure`	yes	Look up a documented procedure.
`diagnose_failure`	yes	Explain a failed pick or intervention from telemetry.
`optimize_schedule`	yes	Re-order work; the result is validated before it is scheduled.
`generate_simulation_scenario`	yes	Create test scenarios for the simulator.
`command_actuator`	no	Never. Actuators are reached only through the gate after AUTHORIZE.
`modify_safety_limit`	no	Never without human authorisation recorded in the decision log.
`modify_production_behavior`	no	Never silently. Every change is an authorised, logged deployment.
`bypass_gate`	no	Does not exist as a tool. Absence is the control.

Every allowed tool carries a schema, authentication, authorisation, deterministic validation, a timeout, provenance, logging, failure behaviour and test coverage. A tool missing one of these is not deployed.

Robot-agnostic by evidence

Abstraction has a cost. An abstraction is written only if it passes at least two of four tests:

Multiple deployments need it.
It reduces integration time.
It reduces vendor dependence.
It creates a defensible platform capability.

Candidate	Tests passed	Position
Robot arms	3 / 4	RobotInterface exists. Vendor dependence reduced only once two drivers exist.
Grippers	2 / 4	GripperController exists; second gripper type not yet needed.
Cameras	1 / 4	Single intrinsics model. Do not abstract further yet.
LiDAR	3 / 4	Shared across palletizing and inspection — robot-lidar-fusion is the abstraction.
Force sensors	0 / 4	No deployment needs it. Not abstracted.
PLCs	1 / 4	Only when a customer cell requires an interlock handshake.
Safety systems	4 / 4	One authorisation boundary, by contract. The only abstraction that is mandatory.
Conveyors	1 / 4	Not abstracted until a second conveyor type appears.
End effectors	2 / 4	Folded into the gripper abstraction for now.