EmbodiWeave

GraphHacks 2026 · Track 1 · built on FalkorDB

A robot fails.
Choose what it learns next.

The agent follows connected failures, checkpoints and past trials in FalkorDB to choose the next robot training run. The graph supplies the evidence; fixed checks decide whether the result qualifies.

Latest measured result New checkpoint passed all four validation checks and fresh confirmation families. Target confirmation: 8% collisions, under the 10% limit. MuJoCo transfer still missed its target collision limit.

Follow the graph decision Train on the live simulator Watch the 2-minute film
Connecting to FalkorDB
Original rejected runSame recorded layout and seed for both policies

Historical baseline P-static-b

Original adaptation scratch~a7ee2c-s7

Same layout, same seed 1300032. Recorded simulator states replayed, step 0.

3D render of the stored simulator states with nothing added. Lidar rays are recomputed from each recorded pose using the simulator geometry.

LiveFalkorDB, queried as this page loaded MATCH (t:Trial)-[:FROM_PARENT]->(p:Policy) WHERE (t)-[:TARGETS]->(:Family {id:$family}) AND (t)-[:UNDER_CONTRACT]->(:Contract {id:$contract}) Asking the graph whether fine-tuning or training from scratch has worked before
Target success37%87%original run, deployed vs adaptation, 60 episodes
Collisions48%13%limit for promotion is 10%
Promotion gateRejectedOriginal run: 3 of 4 suites failed

Judge walkthrough

Start with the graph decision.

  1. 01 / EvidenceFollow the confirmed checkpointFresh confirmation passed; physics gap reported
  2. 02 / LiveTrain in the simulatorWatch 2D or 3D, then inspect the gate
  3. 03 / FilmWatch the walkthroughGraph evidence and the honest verdict

Live from FalkorDB

Ask the graph what the agent asked

Each question re-runs, right now, the exact read-only Cypher template the recorded agent run used, with the parameters stored in its decision record. Rows come straight back from FalkorDB through GRAPH.RO_QUERY.

LiveCounting nodes
LiveWaiting for FalkorDB 


      

      
Loading rows from FalkorDB

    

  






  
From rows to a decision

  
How the graph chose to train from scratch

  
The frozen rule turns the transfer rows above into a chance of reaching the target threshold for each start option.

  

    

      
Recorded Options ranked by the graph

      
Chance of reaching the threshold is estimated as (reached + 1) / (trials + 2), so an option with no successes yet still scores above zero.

      
  1. Loading the recorded decision

      

    

    

      
Recorded Then the gate measured the result

      
  • Loading the gate verdict

      

    

  






  
How it works

  
Six bounded steps from failure to a tested decision

  
The LLM picks each tool call over MCP. Trusted code enforces contracts, budgets and the gate, and every outcome is written back to the graph.

  
    
    
  1. 1ObserveMeasured failures of the deployed policy. Authored hypotheses stay labelled as hypotheses.
    2. 
    
  2. 2QueryRead-only Cypher templates over lineage, semantic contracts and matched validation.
    3. 
    
  3. 3DecideA frozen rule ranks every parent and scratch by conditioned transfer history, then records why.
    4. 
    
  4. 4TrainOne bounded PPO run from the chosen start. No retries to chase a better number.
    5. 
    
  5. 5MeasureRetained-behaviour suites, tied to the exact artifact hash of the new checkpoint.
    6. 
    
  6. 6GatePromotion only if every suite clears its threshold. The verdict joins the graph.
    7. 
  






  
Experiments

  
What the graph got right, and where it was wrong

  
Final-test success on previously unused test suites, three seeds per arm. Each rule change was committed before its experiment ran.

  

    

      
ExperimentRuleGraph pickedGraph armLatest checkpointBest-validation checkpoint

      
Loading recorded results

    

  

  
exp-1 is a negative result: the first rule could only choose among parents and warm starts from this library plateau.
    The graph's own transfer history showed that, so training from scratch became a graph option. Small samples, so treat these as preliminary.






  
Recorded runtime agent

  
A real LLM ran the loop, and the gate said no

  
Loading the latest recorded agent trace

  
    
  

    


    
  
    Graph model
    
  
    Evidence lives in FalkorDB, decisions read it
    
  
    Authored world facts plus measured evidence appended from immutable records. Hover or focus a node to trace its relationships.
    
  
    
    
      EmbodiWeave graph schema
      Policy is central. A Run produced it, it uses a Contract for a Robot and may derive from another Policy. Evaluations assess it on Suites, Failures are observed in Evaluations and Hypotheses are about Failures. Trials start from a Policy or the scratch Origin, target a Family and run under a Contract.
    
  
    
  
    
    
    
      
    One of the decision queries
    
      
    Which past trials from each candidate parent apply to this exact target, recipe, budget and contract.
    

    UNWIND $ids AS pid
MATCH (p:Policy {id:pid})
OPTIONAL MATCH (t:Trial)-[:FROM_PARENT]->(p)
WHERE t.threshold_id = $threshold
  AND t.recipe = $recipe AND t.budget = $budget
  AND (t)-[:TARGETS]->(:Family {id:$family})
  AND (t)-[:UNDER_CONTRACT]->(:Contract {id:$contract})
OPTIONAL MATCH (t)-[:PRODUCED]->(child:Policy)
RETURN pid AS policy_id, t.id AS trial_id,
       t.threshold_reached AS reached,
       t.steps_to_threshold AS steps_to_threshold,
       child.id AS child_id
    
    
    
    
    
      
    Why a graph
    
      
      
        
    • Transfer history is conditional. A past trial only counts if its target family, recipe, budget, threshold and contract all match, a relationship traversal through the evidence graph.
      • 
        
    • Contracts gate reuse. A checkpoint with a different ray order is rejected before ranking, with the differing fields named.
      • 
        
    • Every decision is provenance. The decision records the graph revision and the exact queries it read, so it can be replayed.
      • 
        
    • The graph query templates are read-only and run through GRAPH.RO_QUERY, so the agent cannot write the graph.
      • 
      
    
    
    
  
    

    


    
  
    01
    Graph-driven, not graph-decorated
    Remove the transfer history and the decision changes. The no-history arm in exp-1 exists to show it.
    
  
    02
    Honest by construction
    Final-test suites are invisible to the agent, spent suites are refused in code and every number traces to a record.
    
  
    03
    Safe what-ifs
    Hypothetical evidence runs on a GRAPH.COPY sandbox and can never launch a training job.