RejoinProof · Research technology inside SafeHarbor
Don't restore what you haven't verified.
RejoinProof investigates how to determine which robot capabilities and dependent states require revalidation after a cybersecurity incident.
An example
A malicious map update affects 100 delivery robots.
Not every robot necessarily consumed that update.
Some consumed it but have cached routes derived from it.
Some systems rolled back the map but may still have dependent decisions based on its corrupted version.
RejoinProof investigates
- 01Which robots consumed compromised data?
- 02Which decisions depend on affected data?
- 03Which caches and capabilities require invalidation?
- 04What independently trusted evidence is needed for recovery?
- 05Which capabilities might be restored after required verification?
- 06Which capabilities must remain restricted or require manual intervention?
Introducing RejoinProof
Don't restore what you haven't verified.
RejoinProof investigates a dependency-selective recovery process for autonomous robot systems.
Instead of assuming every component is trustworthy after a reboot or rollback, the proposed method examines which downstream states are affected and what independent checks may be required before individual capabilities are restored.
Scenario: 100 simulated delivery robots. One compromised shared map revision. Choose a stage.
Illustrative numbers. 100 simulated robots, not a real fleet.
Before incident
100 simulated robots share one map service.
Each robot pulls map revisions and builds route caches from them. Nothing is known to be wrong yet.
- 100No incident known
Interactive lab preview
Try the idea on a synthetic fleet.
RejoinProof lab preview
Synthetic research demonstration — not a safety-certified recovery system.
2. Inspect cached decisions
3 of 5 cached decisions depend on shared map revision: R-01 cached routes, R-02 cached routes, R-03 obstacle priors.
3. Run a deterministic revalidation simulation
Upstream sources
Shared data and services
Robot decision caches
Robot capabilities
Each layer depends on the one above it. Tap a node to inspect its dependencies.
- Selected as compromised
- Requires revalidation
- Replaced (assumed known-good)
- Verification completed in simulation
- Dependency unresolved
- Waiting on unresolved upstream
- Requires manual review
- Not on a dependency path
Inspector
R-02 cached routes
- Layer:
- Robot decision caches
- Depends on:
- Route tile service, Zone speed policy
- Synthetic evidence:
- No evidence
- Depends on the compromised node?
- Yes. Shared map revision → Route tile service → R-02 cached routes
Simulation results
Run the simulation to see which nodes clear in simulation and which stay unresolved.
How the demo finds dependencies
- The graph is synthetic: 17 made-up nodes in four layers. Each node lists what it depends on.
- A node is affected when you can reach it by following those links downstream from the node you picked. That is plain graph reachability.
- The inspector shows one shortest dependency path, so you can see why a cached decision is affected.
How the simulation decides, and what it assumes
- The compromised node is assumed to be replaced with a known-good version. The demo does not check this.
- Every node carries an invented evidence label. Independent evidence clears a node in simulation. Self-reported or missing evidence leaves it unresolved. Conflicting evidence goes to manual review.
- A node cannot clear while anything it depends on is still unresolved.
- No real verifier runs here. A result in this demo says nothing about the safety of any real robot.
This preview shows the shape of the problem. It is not the RejoinProof method and does not disclose one. Research on how recovery obligations and evidence should be defined is ongoing.
Recovery should be selective
Understand the blast radius. Preserve what remains trustworthy.
Conventional broad recovery (illustration)
- Suspected fleet compromise
- Large-scale suspension or rebuild
- Full-system revalidation
RejoinProof research direction
- Incident identified
- Dependency graph analysed
- Recovery obligations determined
- Affected capabilities tested
- Selective restoration candidates identified
The goal is to keep what can be shown to be unaffected and to check what cannot. We make no claim that this is faster or cheaper. That needs benchmarks, and we have not run them yet.
CRVP · Causal Recovery Verification Protocol
A record of what recovery depended on.
CRVP is a proposed protocol and interface for recording recovery dependencies, revalidation obligations and restoration evidence. The idea is that each restored capability should come with a record of what it depended on and what was checked.
CRVP is under research. It is not an adopted industry standard and no other organisation has agreed to use it.
Research pilot and partnerships
Help shape the next layer of autonomous security.
We are looking for robotics teams, security researchers and others who want to work on recovery after compromise. Tell us a little about your work.
- We only use your details to reply to this enquiry.
- We do not sell or share your details.
- Please do not send confidential incident details here.
Prefer email? [email protected]