Local first
The network can go dark. The cloud can be unreachable. The Guardian still decides, with no one else’s permission.
Trust, at the
point of action.
An open physical-interlock architecture. Bounder verifies narrow authority, checks live conditions locally, and permits only what signed policy and those checks allow.
The proposition
Digital governance needs a last metre.
Policy platforms can decide. Assurance systems can attest. Devices can act. But none of them own the moment a machine is about to move and a person is in the way.
Bounder is a small, inspectable gate at that boundary. It checks signed policy against local conditions and permits only what both allow, while a device-specific adapter owns the physical response.
The film
Bounder, in two minutes.
Follow authority from human intent to a bounded physical response, then explore the simulation testbed.
Read the transcript
When software can move a machine, its decisions enter a world shared with people. Bounder explores how a clear boundary can accompany that movement, so that every requested action remains within an explicitly defined scope.
The process begins with human and organisational intent. Creed Space Fleet translates that intent into protective policy for a particular device, specifying the conditions under which it may act.
That policy travels in a signed envelope. The local Guardian checks its authenticity, its intended recipient and its validity, connecting the permission that was issued to the device that receives it.
Before an action proceeds, Bounder evaluates the request against verified policy, current platform state and fresh evidence. A device-specific adapter then translates the bounded result into the safest response available for that platform.
This separation matters when connectivity fails. An unavailable audit channel cannot change the local decision, while cached authority still expires. Communication problems remain distinct from the question of whether movement is permitted.
Each decision leaves a signed receipt, linking the outcome to the inputs and authority behind it. These records support accountability, allowing a reviewer to follow what happened without turning evidence into a new permission.
Bounder is currently simulation-only. Its public browser laboratory lets you explore recorded scenarios, inspect published contracts and verify supplied evidence locally, while physical safety remains a separate engineering and validation responsibility.
For engineers and researchers, it offers a concrete architecture to examine: explicit authority, local evaluation, bounded response and inspectable evidence, carried together from an intention to the edge of physical action.
Four layers. One narrow handoff.
Authority narrows as it approaches the machine. By the time it reaches motion, only the minimum necessary permission remains.
-
Govern
Creed Space Fleet, the policy service, distributes a signed protective rule across an enrolled fleet. The policy is immutable once issued.
-
Issue
Fleet creates a short-lived, device-bound projection for every Bounder Guardian, the local checker on each machine. It expires; it cannot be replayed.
-
Bound
The local Guardian checks the signature, subject, expiry, replay sequence, action scope, and what its own sensors see right now.
-
Act safely
A reviewed adapter chooses hold, return, land, isolate, escalate, or no state change.
Authority that expires. Safety that stays local.
Cryptographically narrow
Policies bind issuer, subject, validity, sequence, actions, and constraints.
Deny new authority
Silence is not consent. Missing, stale, replayed, or ambiguous evidence creates no permission.
Fail physically safe
When something goes wrong, the machine takes the safest response it has: land, stop, hold position. Each response is defined by that device’s hazard analysis.
The pattern travels beyond drones.
Guardian is the general pattern.
Bounder is the Guardian for embodied movement and physical-action boundaries.
Creed Space Fleet distributes and governs its policies.
Anywhere a machine is about to move and the stakes are physical, the same architecture applies: ground robots, autonomous boats, warehouse vehicles, inspection platforms, fixed machinery.
Autonomous vehicles
No departure without identity, location, battery, and a current signed policy. The gate holds until every condition is met.
Laboratory systems
Hazardous modes unlock only when operator, protocol, and physical conditions all agree. One missing piece and the interlock holds.
Robots in shared space
Before a robot enters a room where people are, it needs current consent and supervision evidence. Not a schedule. A live check.
Critical maintenance
A signed window, a physical key, measured state, and a receipt recording what was decided and why. Every step auditable.
Creed Space Fleet staging
One policy. A hundred Guardians.
One hundred software Guardians across six platform classes — aerial, ground, marine, warehouse, inspection, and fixed machinery — each independently fetch policy, verify checkpoints and make protective decisions locally. When the live feed is reachable, this page verifies its signed aggregate proof in your browser; when it is not, the recorded run stands in, labelled as such. No Guardian trusts another’s word for it.
- Guardians
- Checking
- Policies verified
- Checking
- Checkpoints
- Checking
- Local decisions
- Checking
- Proof issued
Recorded run · not live
- Guardians
- 100
- Platform classes
- 6
- Expected outcomes
- 100 of 100
- Local decisions
- 13 allow / 87 hold
- Recorded
Checking the live feed’s signature and freshness.
Watch the boundary hold.
Explore how Bounder holds a machine back: outside civilian buffers, protected sites and humanitarian corridors, away from the operator’s own teams, and whenever a person may be surrendering or incapacitated. An unconfirmed identity, an unresolved consequence check or missing human authorisation keeps a high-consequence request on hold. In this simulation such a request is never allowed, whatever is confirmed: these conditions are only ever reasons to hold. One Creed Space policy governs the whole simulated fleet.
Development roadmap
The path to deployment.
Prove it in simulation first. Then validate it on the platforms where the stakes are real.
- Policy checks: signatures, expiry, replay, assurance, commands and sensors.
- Fleet exercises: recorded runs with 16 and 100 Guardians, covering six platform classes, revocation, disconnects and audit trails.
- Next steps: device integration, hardware-in-the-loop testing and platform-specific safety validation.
Help build the missing boundary.
Use the pattern. Challenge the threat model. Extend the simulator. Or bring a governance layer that needs a physical boundary beneath it.