RobotGov / External Sandbox Pilot

Access is not authority.

A two-level pilot for whether access to a robot command interface is being mistaken for permission to produce the consequence. Start with exact-command authority, then optionally bind it to one partner-owned freshness dependency.

No production credentials · No hardware path · No external LLM calls
PARTNER PANDA WORKFLOW / V0.2VERIFIED
01
Proposal + plan
untrusted process / ROS domain A
BOUND
02
Separate authority issuer
current pre-state + exact stage commitment
SIGNED
03
Private consequence receiver
13 ordered effects / ROS domain B
APPLIED
04
Read-only Gazebo observer
fresh detached cube state + trusted finalizer
OBSERVED
13governed workflow stages
6frozen suite outcomes
Partner reviewedexternal sandbox owner
ROS 2 + MoveItPanda workflow path
Gazebo 8.11independent final observation
0 LLM callsenforcement path

A complete Panda workflow, governed stage by stage.

James Sunday Akam supplied and reviewed an existing ROS 2 Jazzy, MoveIt 2.12.4, and Gazebo Harmonic pick-and-place sandbox. RobotGov was inserted at the private consequence boundary after the unchanged baseline was reproduced. The final result was merged, tagged, and released as a bounded sandbox integration.

v0.2 frozen Franka Panda 13 consequential stages one-shot child authority read-only final observer
Exact authorized workflowWORKFLOW_COMPLETED
Unsigned accessUNSIGNED_ACCESS_REJECTED
Material mutationMUTATION_REJECTED
Replayed authorityREPLAY_REJECTED_NO_SECOND_EFFECT
Receiver outageRECEIVER_OUTAGE_NO_RECEIPT
Observer outageOBSERVER_OUTAGE_NO_COMPLETION
“With the merge and v0.2 tag complete, I consider my work on the agreed pilot scope finished.” James Sunday Akam · Sandbox owner and technical reviewer

Bounded ROS 2 / MoveIt / Gazebo sandbox evidence · Not production isolation, hardware readiness, robot safety, or certification

Five cases. One command boundary.

The partner chooses a command it already considers consequential. RobotGov sits on the actual sandbox consequence path. The baseline suite tests the exact path, direct bypass, post-approval mutation, replay, and false completion during outage.

01

Exact command

Exact submitted command and valid one-shot authority.

ONE EFFECT
02

Direct access

Receiver is reachable, but the authority artifact is absent.

ZERO EFFECTS
03

Changed command

One material field changes after authority is issued.

ZERO EFFECTS
04

Replay

Previously consumed authority is submitted again.

ZERO ADDITIONAL
05

Outage

Receiver, sandbox, or observation source is unavailable.

NO FALSE SUCCESS

Start with the boundary you need.

Level 1 proves that only the exact authorized command reaches the sandbox consequence. Level 2 adds one partner-owned fact that must still be current when the consequence commits.

LEVEL 1

Exact-command boundary

Bind authority to one exact command, one receiver audience, one validity period, and one use. This is the smallest external integration.

  • Exact command produces one harmless sandbox effect
  • Direct access without authority produces zero effects
  • Post-approval mutation produces zero effects
  • Replay produces no second effect
  • Outage produces no false completion receipt
LEVEL 2

Exact command + authority freshness

Add one operational dependency owned by the partner: operator authorization, maintenance clearance, geofence state, occupancy, mission approval, asset availability, or protected mode.

  • Current governance basis permits one sandbox effect
  • Relevant revocation produces zero effects
  • Undelivered material change is caught by a commit-time read
  • Unrelated state change does not revoke valid authority
  • Dependency semantics remain partner-defined

The downstream receiver enforces authority.

The proposing agent cannot approve itself. The consequence adapter independently verifies the authority artifact, exact command, asset, task, audience, policy, evidence scope, validity period, and durable one-shot state.

AUTHORITY_ACCEPTED

Policy boundary

The exact request fits the declared envelope.

COMMAND_ACCEPTED

Receiver boundary

The downstream adapter verifies the artifact and command.

COMMAND_APPLIED

Application boundary

The partner sandbox acknowledges the bounded request.

EFFECT_OBSERVED

Evidence boundary

A separate state source confirms the consequence.

Small enough to integrate. Strict enough to learn.

The first pilot is a bounded technical evaluation, not a production deployment. The command schema, sandbox, and any Level 2 freshness dependency must come from the partner; an Ark-only demo does not count as external validation.

Partner provides

  • One consequential command schema
  • One simulator or controller sandbox
  • One harmless observable effect
  • A technical owner and policy owner
  • For Level 2, one authoritative state and material event

RobotGov returns

  • Exact command and policy commitments
  • A receiver-side verification adapter
  • Five Level 1 boundary cases
  • Four Level 2 freshness cases, when selected
  • Application, effect, and zero-effect receipts

No external AI dependency

  • No external LLM calls
  • No robot data sent to model providers
  • No token-based processing fees
  • No model-version drift in authority decisions
  • Runs inside the approved environment

Not claimed

  • Robot safety or command feasibility
  • Production security or certification
  • Physical controller integration
  • Customer value or willingness to pay
  • Deployment or operational approval

Which command is too consequential to trust to agent-side rules alone?

Start with the exact-command boundary. Add one partner-owned freshness dependency only when authority must remain current through the moment of consequence.

zolboo@arksovereign.com