Mike DiegelA governance and evidence layer exploring how autonomous machines handle lost communication, expired permissions, and uncertain command outcomes.
Project details
What happens when a robot loses contact?
A machine sends a command, loses communication, and receives no confirmation. Did the command fail—or did it execute without the acknowledgment reaching the operator?
Automatically retrying can repeat a physical action. Continuing indefinitely can exceed the operator’s original permission. Stopping also needs a defined behavior appropriate to the machine.
Pulpo Autonomous explores how to keep execution inside explicitly delegated authority when communication and observations become unreliable.
It is a governance and evidence layer for autonomous physical systems, with a shared core and domain-specific modules for robotics, drones, vehicles, industrial systems, and spacecraft.
The central rule is:
Pulpo may enforce and translate delegated authority. It may never become a second authority source.
How it works
An execution envelope identifies the permitted action, target, machine, and expiry. The offline layer adds a bounded mission lease, with limits on disconnected operation and an optional command budget.
The system models connection loss, reconnection, and reconciliation. Its journal records commands, observations, vetoes, and uncertain outcomes.
The important boundaries are:
- Disconnection cannot expand permission.
- Offline operation remains bounded by the original permit and mission lease.
- Duplicate command IDs are treated as idempotent and are not resent.
- An uncertain result stays
UNKNOWN; uncertainty does not authorize a retry. - Execution is blocked during reconciliation.
- Reaching a lease limit records the pre-authorized fallback instead of sending a new command.
- Evidence records what happened; it does not grant permission.
What exists today
The repository includes a Python governance kernel, offline protocol, execution tracking, a hash-chained evidence journal, domain safety checks, and a reproducible simulator evaluation.
Additional repository work covers expiring one-use permits, restart-safe replay state, tamper-detecting audit storage, bounded untrusted inputs, and proposal-only handling of vision and audio observations.
These capabilities have specific test and deployment boundaries. They should be evaluated against the exact source commit and environment being used.
Try the simulator
No physical robot is required for the initial evaluation.
From the repository root, run:
python scripts/run_gtm_evaluation.py --output evidence/gtm-evaluation.json python -m unittest tests.test_offline_autonomy -v
The simulator exercises:
- Execution of an exact permitted command.
- An offline command budget reaching its pre-authorized fallback.
- An uncertain outcome being recorded as
UNKNOWN. - Detection of evidence-journal tampering.
The generated evaluation records the source commit, scenario results, and limitations. It is a simulation artifact, not a hardware-safety certificate.
What Pulpo does not replace
Navigation, stabilization, collision avoidance, braking, flight control, actuator interlocks, and emergency-stop hardware remain the responsibility of the existing platform.
Pulpo’s admission checks must remain subordinate to those controls.
The project does not claim certified physical safety, universal hostile-code containment, rollback-proof host storage, or production readiness. Successful simulator tests do not establish that a real vehicle or robot is safe.
Help test the boundaries
I’m looking for reproducible failures, missing cases, and feedback from people building autonomous systems.
Useful scenarios include:
- Delayed telemetry after an uncertain command.
- Replayed or stale commands following a restart.
- Communication loss near permit expiry.
- Conflicting observations during reconciliation.
- Exhausted offline command budgets.
- Malicious text, QR, vision, or audio inputs attempting to influence authority.
Begin with simulation and synthetic data. When reporting results, include the commit, platform, command, expected behavior, actual behavior, and a minimal reproduction. Keep credentials, private keys, sensitive telemetry, and mission data out of public reports.
What failure scenario would you test first?
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.