Skip to content
ZeptoDB

Action-Outcome Evidence

This page summarizes the Action-Outcome Memory evidence currently visible in the ZeptoDB repo. It is written as product evidence, not as a GA claim.

Use it as the starting point for action outcome research: it connects each action outcome experiment to interpreted results, raw artifacts, limitations, and readiness boundaries.

The important distinction: completed experiment validation is not the same as promoted product readiness. The current path supports research evidence, experimental runtime paths, and controlled pilots with explicit boundaries.

Evidence summary

Section titled “Evidence summary”
ExperimentWhat it testedResult
013Physical AI action recommendation baselines vs context-gated Action-Outcome MemoryContext-gated variant reached 1.00 recovery Top-1 and 1.00 risky-repeat avoidance.
014Native ZeptoDB SQL replay of robot action/outcome evidenceOverall SQL replay passed, including ASOF JOINs, suppression audit JOINs, windows, and spatial checks.
016Bounded edge-to-fleet feed replay52/52 feed events acknowledged through duplicate, late, outage, and restart scenarios.
021Shadow supervisor A/B and durability replay15/15 hazardous proposals suppressed, 5/5 safe proposals allowed, restart replay skipped 20/20 duplicates.
022Supervisor node replacementExpired lease takeover fenced stale owner and converged commit, decision, and evidence rows.
023Commit-ledger stress12/12 proposals converged after injected projection faults and runtime restarts.

What actually improved

Section titled “What actually improved”

Recovered the right action

The context-gated variant selected reroute_zone, safe_stop_clean_lens, pause_recalibrate, reroute_cold_dock, and return_to_base for the five Physical AI query families.

Avoided unsafe repeats

Similar-incident retrieval, runbook priors, and reflection-only memory repeated the hazardous Top-1 action on hard distractors. Context-gating did not.

Kept the audit trail

Suppressed misleading evidence is not discarded. It remains queryable through suppression audit JOINs for later inspection.

Survived replay and restart

Decision and commit ledgers preserve idempotency when a runtime restarts or replays already-seen proposals.

SQL replay surface

Section titled “SQL replay surface”

Experiment 014 validates that the Physical AI fixture is not only a Python research artifact. It materializes into live ZeptoDB SQL tables and passes:

  • failed-repeat JOIN,
  • context top-action JOIN,
  • suppression audit JOIN,
  • action/outcome JOIN,
  • robot state ASOF JOIN,
  • sensor ASOF JOIN,
  • ROW_NUMBER window,
  • LAG window,
  • spatial ST_Within.

The key product claim is narrow and useful: ZeptoDB can keep robot state, sensor summaries, actions, outcomes, recommendations, retrieval evidence, and suppressions in one replayable SQL path.

Edge/fleet replay surface

Section titled “Edge/fleet replay surface”

Experiment 016 validates the edge/fleet split:

SignalResult
Edge outbox events52
Fleet acknowledged events52
Duplicate inbox attempts1
Late inbox attempts2
Outage telemetry rows1
Restart reload telemetry rows1

This matters because robot safety decisions cannot wait for a central fleet layer. The edge node can make immediate suppression/recovery decisions while the fleet node receives bounded evidence later for audit and policy learning.

Shadow supervisor surface

Section titled “Shadow supervisor surface”

Experiment 021 tested the supervisor before widening runtime scope.

MetricValue
Total shadow proposals20
Hazardous baseline proposals15
Suppressed hazardous proposals15
Safe context-gated proposals5
Allowed safe proposals5
Restart duplicate skips20

The supervisor is intentionally shadow-oriented. Hazardous baseline proposals are suppressed to manual review; safe context-gated proposals are allowed in the fixture. This is evidence for controlled shadow pilots, not a promise of autonomous actuation.

Runtime maturity

Section titled “Runtime maturity”
ComponentStatusBoundary
Action-Outcome research fixtureResearch completeEvidence and comparison only.
Native SQL replayResearch completeValidates table/query shape, not broad production automation.
Edge/fleet feed replayResearch completeDeterministic replay semantics, not generic replication.
Edge/fleet C++ connector and SQL/HTTP adapterExperimental runtime pathAdmin-gated, bounded, pilot-scoped.
Action-Outcome supervisor runtimeExperimental runtime pathShadow-only; SQL lease is not consensus.
Edge/fleet controlled pilotControlled pilotOne approved environment at a time; no GA/SLA language.

Promotion gates

Section titled “Promotion gates”

Before broader promotion, the ZeptoDB path still needs:

  • 24h+ live pilot soak and fault windows,
  • dashboard and alert evidence for worker lag, ACK gaps, retries, failures, late events, and admin audit events,
  • documented supported schemas, limits, rollback, and non-goals,
  • release-grade x86_64 and aarch64 verification,
  • a new production gate for moving from controlled pilot to Limited Operator Feature.

This explicit boundary is part of the point. Action-Outcome Memory is useful because it preserves evidence, including the evidence that a runtime is not ready for a broader claim yet.

Full research catalog

Section titled “Full research catalog”

Every public experiment, supporting research note, and generated result artifact is linked below. Start with the experiment record for interpretation; open the raw artifact when you need the underlying tables and replay output.

Experiment records

Hypotheses, fixture boundaries, measured outcomes, and promotion gates.

  1. EXP 023 Experiment 023: Physical AI Supervisor Commit-Ledger Stress Stress the Action-Outcome supervisor's supervisor-specific commit-ledger sink contract under repeated projection failures, fresh runtime objects, bounded bat...
  2. EXP 022 Experiment 022: Physical AI Supervisor Node-Replacement Validation Validate that the experimental SQL-backed Action-Outcome supervisor can survive a node-replacement shaped handoff without duplicate decisions, lost proposals...
  3. EXP 021 Experiment 021: Physical AI Shadow Supervisor A/B And Durability Validate the first two commercialization gates for the Physical AI Action-Outcome supervisor:
  4. EXP 020 Experiment 020: Physical AI Edge/Fleet Worker Runtime Move the Physical AI edge/fleet connector beyond lifecycle-only server control by adding a bounded server-managed worker foundation.
  5. EXP 019 Physical AI Action-Outcome Experiment 019 Server Lifecycle Move the Physical AI edge/fleet connector from standalone replay-tool ownership toward server-managed lifecycle ownership.
  6. EXP 018 Physical AI Action-Outcome Experiment 018 C++ Connector Replay Connect the C++ EdgeFleetFeedConnector to the existing two-node Physical AI edge/fleet SQL replay and prove that the connector can replace the Python feed wo...
  7. EXP 017 Physical AI Action-Outcome Experiment 017 Runtime Connector Promote the Experiment 016 bounded edge-to-fleet feed semantics from a Python research harness into a reusable C++ runtime connector.
  8. EXP 016 Physical AI Action-Outcome Experiment 016 Edge/Fleet Feed Replay Validate a bounded, explicit edge-to-fleet feed shape for Physical AI Action-Outcome Memory:
  9. EXP 015 Physical AI Action-Outcome Experiment 015 Edge/Fleet Replay Experiment 014 proved the single-node native SQL replay. Experiment 015 splits that evidence across two live ZeptoDB HTTP endpoints.
  10. EXP 014 Physical AI Action-Outcome Experiment 014 SQL Replay Replay the Physical AI Action-Outcome fixture through live ZeptoDB native SQL so the robot-safety result from Experiment 013 is validated outside the Python-...
  11. EXP 013 Physical AI Action-Outcome Experiment 013 Compare similar robot incident retrieval, runbook/action-prior recommendation, reflection-only memory, and context-gated Physical AI Action-Outcome Memory on...
  12. EXP 012 Action-Outcome Experiment 012: Operational Placement Policy And Telemetry Verify that bounded small-table Action-Outcome JOINs can use explicit operational table placement instead of relying on accidental (stabletableid, symbolid=0...
  13. EXP 011 Action-Outcome Distributed Vendor SQL Replay Experiment 011 Experiment 010 proved the vendor baseline comparison on a single ZeptoDB SQL endpoint. Experiment 011 runs the same vendor replay through a two-node ZeptoDB...
  14. EXP 010 Action-Outcome Vendor Baseline Experiment 010 Experiments 016 and 017 identified the industry-adjacent baselines around Action-Outcome Memory: similar incident recommendation, runbook/action-prior automa...
  15. EXP 010 Action-Outcome Vendor SQL Replay Experiment 010 The first Experiment 010 report compared similar-incident retrieval, runbook/action-prior recommendation, reflection-only memory, and context-gated Action-Ou...
  16. EXP 009 Action-Outcome JOIN/Window Replay Experiment 009 Experiment 009 extends the Action-Outcome replay harness beyond load, row counts, projection, and top-action filtering. It checks whether replay recommendati...
  17. EXP 008 Action-Outcome Distributed Live SQL Replay Experiment 008 Experiment 007 validated Action-Outcome replay on a single live ZeptoDB HTTP endpoint. Experiment 008 validates the same seed through a real two-node HTTP/RP...
  18. EXP 007 Action-Outcome Live SQL Replay Experiment 007 Experiment 006 proved the Action-Outcome replay contract with a local SQL executor. Experiment 007 runs the generated SQL seed through a live ZeptoDB HTTP SQ...
  19. EXP 006 Action-Outcome SQL-Backed Replay Experiment 006 Experiments 001-005 used Python fixtures directly. That proved the research logic but did not yet connect the Action-Outcome Memory Engine to ZeptoDB's core...
  20. EXP 005 Action-Outcome Context Gate Experiment 005 Experiment 004 showed a critical failure mode: successful historical actions can be harmful evidence when the success occurred under a different causal conte...
  21. EXP 004 Action-Outcome Noisy Distractor Experiment 004 Experiment 003 showed that the base fixture is too clean. Removing the actionoutcome signal changed one top action after the ablation correction, but headlin...
  22. EXP 003 ActionOutcomeReplay Experiment 003: Signal Ablation Experiment 002 showed that guarded retrieval can reduce weak cross-family candidates while preserving successful-action hit rate and failed-action avoidance...
  23. EXP 002 ActionOutcomeReplay Experiment 002: Retrieval Guardrails Experiment 001 showed that action-outcome retrieval can avoid repeating failed actions in the clean synthetic fixture. It also exposed a weakness:
  24. EXP 001 ActionOutcomeReplay Experiment 001 Define the first replay experiment for the Action-Outcome Memory Engine.

Methods and operating boundaries

Schemas, governance, roadmaps, research scans, and runtime plans.

Raw result artifacts (23)

Generated tables and replay outputs are kept public for reproducibility, but excluded from site search so that interpreted evidence ranks first.

Product pages

Section titled “Product pages”
Action-Outcome Memory The product use case and runtime shape
Physical AI & Robotics ROS 2 ingest, typed profiles, and replayable robot timelines
Agent Memory Live evidence, memory retrieval, prompt cache, and AgentOps replay
Benchmarks Benchmark criteria and performance scope