Checks that protect the check.
Reference engines, external workflows, corrupted responses, concurrency, and interrupted-run recovery.
Make your deletion workflow a repeatable test. Explore the reference lab or connect a staging adapter, inspect the observations, and keep the evidence.
Python CLI · Local dashboard · MCP tools
your-verification-labILLUSTRATIVE PREVIEWRun the reference application’s deletion workflow.
A successful acknowledgment starts the check. It does not establish that every declared copy is gone.
↳ A repeatable check. More than a success response.
automated
tests passed
reference
failure patterns
local vector
backends
MCP
tools
Look beyond a green badge. Open a receipt, inspect the outcomes, and keep its boundaries in view.
↳ Recorded 3 November 2026
Local workloads · not production accuracy
Reference engines, external workflows, corrupted responses, concurrency, and interrupted-run recovery.
A deletion response is the beginning of the story. Follow the copies, then explore what a complete check needs to observe.
Baseline established. The document has more than one representation.
A workflow that asks you to observe, not just assume.
Keep your local tools. Use the local dashboard for reference fixtures. The CLI and MCP also support configured staging runs, persistent evidence, and saved regression contracts.
Preserve a confirmed failure as a fixed regression definition. Compare broken and corrected fixtures using the same assertions.
Missing observations stay inconclusive. An unrelated control must survive. A pass covers the declared fixture contract.
Small defects. Different lifecycles.
Each one has a broken and a corrected reference implementation.
A successful source deletion can leave derived records searchable. Check the index independently.
The first 100 records disappear. The last 25 don't. Trace enumerates the complete fixture inventory.
A worker reads an old snapshot and publishes after deletion. The fixture controls that exact interleaving.
Source and vectors are empty. Repeating the query can still return a cached synthetic canary.
A successful API call isn't a full inventory.
Choose an evidence set to see what it actually covers.
No store inventories or control observation have been established.
Illustrative coverage comparison. This is not a live verification, confidence score, or guarantee of universal erasure.
Choose a failure pattern. Run the browser model.
Then switch to its corrected implementation.
Runs entirely in your browser.
No uploads or external API calls.
This interactive explanation uses a simplified JavaScript model. It is not a live Python/Qdrant run. Download Trace to execute the actual local tests and inspect their evidence.
Run synthetic checks against an application you configure. Keep the assertions fixed as the implementation changes.
Register the application locally. Establish retrieval, inspect declared inventories, and preserve an unrelated synthetic control through the observation window.
Persist evidence and an immutable regression definition. Checkpoints record synthetic IDs before writes, so interrupted runs leave a cleanup record.
Rerun the same lifecycle with fresh synthetic records. Compare compatible runs and their cleanup outcomes through CLI or MCP.
Validated locally with unmodified Mem0 2.2.1 and embedded Qdrant, using synthetic records. Active-memory deletion passed; audit history remained. This is a scoped local integration. Copies appearing after the observation window or in undisclosed stores can still be missed; this is not proof of complete erasure.
Read the staging integration guide ↗ Mem0 evidence and limits ↗ Stress results and blind spots ↗Connect an assistant to your locally registered staging target. Inspect the contract, run synthetic deletion checks, save a failure, and replay the same assertions after a fix. The original reference tools remain available.
Inspect & planKnow the target and test effects.
Run & investigateRead actual observations.
Save & replayKeep the same assertions.
trace.inspect_targetDISCOVERtrace.plan_testsPREVIEWtrace.start_runEXECUTEtrace.get_runOBSERVEtrace.save_regressionPRESERVEtrace.replay_regressionREPEATtrace.compare_runsCOMPAREtrace.get_learningEXPLAINtrace.external_targetsTARGETStrace.external_planPLANtrace.external_startRUNtrace.external_getPOLLtrace.external_saveSAVEtrace.external_replayREPLAYtrace.external_compareCOMPARE# After extracting the engine and installing its MCP extra:
python scripts/launch.py mcp-configThis prints a configuration using your local Python executable and paths. Add it to a compatible client; configuration formats vary.
python -m pip install -e ".[mcp]"The official Python MCP client was integration-tested. Compatibility with every commercial client is not claimed.
List registered external targets and inspect the plan for my-staging. Run its synthetic deletion contract and poll for final evidence and cleanup status. Save a confirmed failure. After I fix the staging app, replay the saved regression and compare without changing the assertions.
Eight tools cover reference fixtures; seven cover registered staging targets. Register endpoints locally first. MCP does not automatically inspect your repository or other tools.
The release suite checks both reference backends, external history and regression replay, and official-SDK MCP workflows. The release adds adversarial HTTP and interrupted-process checks. A separate seeded benchmark matched 170 expected labels, and ten Mem0 load lifecycles passed across 397 created records. These local results are not a production accuracy percentage.
Read the validation notes ↗| Local backend | Broken → FAIL | Corrected → PASS |
|---|---|---|
| SQLite | 4 / 4 ✓ | 4 / 4 ✓ |
| Embedded Qdrant | 4 / 4 ✓ | 4 / 4 ✓ |
These historical v0.1.0 benchmark results cover the supplied fixtures. They are not a measure of external-app accuracy, production security, or learning performance.
Yes. The base engine, CLI, and dashboard use Python's standard library and run on your existing computer. No paid model API, GPU, cloud database, or subscription is required. Optional MCP and Qdrant support use downloadable open-source packages. Hardware, electricity, and internet access are still resources; an assistant client may have its own fees.
Version 0.3.0 can test a configured staging application through its documented HTTP adapter, using synthetic records. It requires explicit local setup and declared inventory coverage. The integration has been verified against a local Mem0-backed staging service. Its audit history is retained and outside the active-memory contract; customer and hosted deployments remain unvalidated. Production scanning is not supported.
The current engine can prioritize tests using a transparent frequency-based heuristic from its local history. It does not train a model or demonstrate generalization. Adaptive generation and prioritization need evaluation against a strong fixed suite before we claim measurable learning.
It establishes that the selected reference or staging test met its stated API-visible deletion contract at the sampled observations, with an unrelated synthetic control preserved. It does not establish physical erasure, deletion from backups or model weights, legal compliance, or absence from unobserved systems.
No. It is a labelled, simplified JavaScript simulation designed to explain the failure patterns. The downloadable Python engine executes real local source, vector, and cache operations and exports its own evidence.
Start locally. Inspect the outcome.
Keep the test that catches it next time.
python scripts/launch.py servesynapsoul-trace folder. Run the command.http://127.0.0.1:8765 on the same computer.