Latest result Timeline Current evidence All experiments Public experiment record
This is where ZeptoDB shows its work. The product documentation explains how to use the database. This area records what we tried, what happened, and how much confidence the result deserves.
Read the interpreted experiment first. Open the raw artifact when you want the replay tables, output, or acceptance evidence.
The newest runtime validation stresses one narrow commit-ledger contract used by the experimental shadow supervisor. It asks whether committed state can be repaired after projection failures; it does not make a general transaction claim.
EXP 023 Runtime validation
12/12 proposals converged after injected projection faults Can fresh runtime objects repair committed state without duplicating decision or evidence rows?
Proposals converged 12/12
Faults repaired 3/3
Duplicate ids 0 The commit ledger held as an effectively-once boundary for the bounded supervisor sink.
Boundary: Supervisor-specific contract; not a generic multi-table SQL transaction.
The sequence matters more than any isolated benchmark number. Each experiment removes one assumption from the previous result, moving from an offline fixture toward bounded runtime failure cases.
EXP 013 2026-06-23
Context gating avoided every risky repeat in the fixture
The result moved the problem from incident search to evidence-backed action reuse.
EXP 014 2026-06-23
The action-outcome result survived native SQL materialization
Robot state, sensor evidence, recommendations, suppressions, and outcomes became one inspectable SQL path.
EXP 016 2026-06-23
52/52 feed events converged through outage and restart cases
The replay preserved bounded transfer, duplicate handling, late delivery, and restart recovery.
EXP 021 2026-07-04
15/15 hazardous proposals were suppressed in shadow replay
The experiment connected historical outcomes to explicit allow, suppress, and manual-review decisions.
EXP 022 2026-07-09
A replacement owner fenced stale work and converged all rows
The bounded runtime recovered ownership and completed the remaining proposal stream exactly once.
EXP 023 2026-07-09
12/12 proposals converged after injected projection faults
The commit ledger held as an effectively-once boundary for the bounded supervisor sink.
01 Context changes action reuse Similarity alone can surface an episode whose outcome does not fit the current zone, payload, sensor motif, or policy context.
02 The decision trail can stay queryable Native SQL replay keeps robot state, retrieved evidence, recommendations, suppressions, and outcomes inspectable together.
03 Bounded failures can be tested Feed replay, restart idempotency, owner replacement, and projection repair have explicit experiment records instead of implied reliability claims.
These results support continued experiments and controlled shadow pilots. They do not establish certified robot safety, autonomous actuation, generic replication, consensus, or general multi-table transactions.
Surface Current status Meaning Action-Outcome comparison and SQL replay Research complete Reproducible evidence and schema/query validation Edge/fleet feed and shadow supervisor Experimental runtime path Admin-gated, bounded, monitored, and pilot-scoped Autonomous control or certified safety Not claimed Policy and actuation remain outside ZeptoDB
Promotion requires longer live soak windows, operator dashboards and alerts, documented limits and rollback, cross-architecture verification, and an explicit decision to widen the current shadow-only boundary.
Interpreted experiment records now live here, separate from product documentation. Methods and raw outputs remain under Research for independent review and reproducibility.
Browse the complete experiment record (31 experiments) Experiment records Hypotheses, fixture boundaries, measured outcomes, and promotion gates.
EXP 030 Experiment 030: Physical AI VLA Confidence-Safety Dual Gate On EKS Test whether confidence and an independent, VLA-free safety index can identify a low-risk historical-action slice that preserves paired LIBERO task quality w... EXP 029 Experiment 029: Physical AI VLA Trajectory Fork On EKS Determine whether the Experiment 028 closed-loop skip-rate collapse is caused by a retrieved historical action moving the robot into observations with lower... EXP 028 Experiment 028: Physical AI VLA Skip Region Discovery On EKS Find a bounded region of sequential LIBERO observations where a task-partitioned ZeptoDB historical action can replace a SmolVLA call with measurable latency... EXP 027 Experiment 027: Physical AI VLA Closed Loop On EKS Test whether the Experiment 026 ZeptoDB action-reuse path retains real closed-loop LIBERO task success while reducing VLA calls, GPU work, and decision latency. EXP 026 Experiment 026: Physical AI VLA Early Exit On EKS Determine whether confidence-gated reuse of historical actions retrieved from ZeptoDB can reduce real VLA calls, online GPU time, and mean decision latency w... EXP 025 Experiment 025: Physical AI Vision Retrieval On EKS Replace Experiment 024's deterministic observation proxy with real robot camera images and a real vision-language encoder, then measure retrieval quality, GP... EXP 024 Experiment 024: Physical AI Agent Memory EKS Replay Measure whether ZeptoDB Agent Memory can provide a low-latency, replayable action-outcome prior for Physical AI and future VLA experiments on the existing ze... 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... 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... 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: 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. 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. 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... 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. 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: 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. 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-... 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... 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... 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... 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... 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... 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... 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... 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... 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... 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... 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... 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... 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: EXP 001 ActionOutcomeReplay Experiment 001 Define the first replay experiment for the Action-Outcome Memory Engine. Methods and operating boundaries (2) Schemas, governance, roadmaps, technical scans, and runtime plans stay in the Research layer.
Raw result artifacts (30) Generated tables and replay outputs are public for reproducibility, but excluded from site search so interpreted evidence ranks first.
Raw evidence Generated tables and replay output, kept separate from the interpreted result