Robot Integration connects the Laws Of Robots architecture to sensing, navigation, drivers, middleware, and physical actuation.
◌ IN DEVELOPMENT
The adapter boundary is in development; this page makes no compatibility or availability claim for a particular robot.
Current scope
This section will explain how ROS 2, proprietary middleware, RobotSim, and eventual hardware connect through adapters rather than becoming foundational dependencies.
Authority boundary
Integration owns sensing and execution mechanics. It acts on authorized goals but does not decide whether consequential work is permitted.
What this section will add
A later development pass will add adapter contracts, evidence return paths, cancellation behavior, and honest compatibility status.
Robot Integration connects authorized work to sensing, navigation, drivers, middleware, simulation, and eventual physical actuation—without giving any of those systems authority to decide what should be done.
◌ IN DEVELOPMENT
The adapter boundary is in development. This page defines its intended contracts; it does not claim compatibility or availability for any ROS 2 distribution, vendor platform, robot model, or physical deployment.
One boundary, four contracts
Translate the mechanics without translating the decision
01
Capability declared
Report the exact sensing, navigation, control, and stop behavior an adapter can provide—including limits, health, and known failure modes—before work is accepted.
02
Goal kept intact
Bind every command to the authorized goal, its constraints, and its decision identity. Translation may change mechanics, never purpose or permitted scope.
03
Stops kept intact
Give cancellation, timeout, and local protective stops an explicit path. A stop is not a new goal, and a failed stop cannot be reported as complete.
04
Evidence returned
Return observations, progress, faults, and terminal state with their source and time so the outcome can be correlated without rewriting the authorization.
Contract map
Evidence moves up; authorized work moves down
The adapter boundary keeps upstream authority, translation mechanics, and the robot-facing surface visibly separate.
The robot is observed
Upstream contract
Cognition receives attributable evidence; RES may later use it as decision context.
Integration boundary
Attach adapter and device identity, time, quality, and health without certifying the observation as true.
Robot surface
A sensor, simulator, driver, or middleware source emits data and diagnostics.
A goal is admitted
Upstream contract
Only an RES-authorized goal arrives, carrying its scope, constraints, and decision identity.
Integration boundary
Validate that the declared capability can honor the complete envelope; reject it before starting if it cannot.
Robot surface
Receive only the mechanical commands needed to carry out that bounded goal.
Work changes or stops
Upstream contract
A cancellation or narrower constraint remains bound to the same tracked work.
Integration boundary
Prioritize the stop or adjustment, preserve the new bound, and never substitute a different objective.
Robot surface
Acknowledge the actual stopped, holding, continuing, or faulted state.
Work ends
Upstream contract
Cognition correlates returned evidence; the original RES decision remains distinguishable from its outcome.
Integration boundary
Report terminal state, measurements, faults, and remaining uncertainty against the tracked goal.
Robot surface
Return what physically or simulatively occurred—not what was expected to occur.
Authorized goal lifecycle
Every accepted goal remains bounded and observable
1
The adapter declares capability, limits, health, and failure semantics.
2
An authorized goal envelope arrives with its decision identity and constraints.
3
The adapter accepts the whole envelope or rejects it before consequential execution begins.
4
Commands are translated and tracked without widening the authorized purpose or bounds.
5
Progress, cancellation, timeout, protective stops, and faults remain observable.
6
Terminal evidence returns with source, time, outcome, and unresolved uncertainty.
Failure posture
A fault changes capability, not authority
If capability is unavailable
The goal does not start. The adapter returns an explicit unavailable or rejected result instead of silently choosing a weaker substitute.
If feedback becomes stale
Stale or missing feedback cannot become success. Active work follows the adapter's declared hold, stop, or failure behavior and the uncertainty is returned as evidence.
If coordination is unavailable
No new consequential goal is inferred. Already-authorized work remains inside its recorded limits and declared timeout or stop behavior.
Honest compatibility ledger
Compatibility is a tested contract, not a logo
Surface
Current state
What is claimed
RobotSim
PROVING TARGET
The public Scenario Lab is a deterministic replay. This page does not expose or claim a live simulator-control bridge.
ROS 2
ADAPTER FAMILY IN DESIGN
No distribution, package set, navigation stack, or hardware combination is presently claimed compatible.
Vendor middleware
CONTRACT PATTERN ONLY
No vendor integration, certification, endorsement, or production connector is claimed.
Physical hardware
FUTURE PATH
There is no shipped third-party robot deployment and no public physical-control endpoint.
Deliberate limits
What Robot Integration does not do
It does not decide whether consequential work is permitted or required; that authority remains exclusively with RES.
It does not invent a goal, broaden a constraint, or convert partial execution into implied permission.
It does not make ROS 2, vendor middleware, a simulator, or a robot maker foundational to governance.
It does not treat missing, late, or contradictory feedback as proof of success.
It does not claim a universal robot interface or expose a live public control surface.