◈   SynapSoul Trace.

A SHORT INTRODUCTION / ILLUSTRATED WORKFLOW

Every copy
leaves a trace.

Follow the data. Verify what remains.

LOCAL FIRST. EVIDENCE LED.
INTRO / 04 SECONDS
✦DELETION LIFECYCLES✦Vector stores✦CONTROL PRESERVATION✦MCP tools✦REPEATABLE EVIDENCE✦Local-first testing✦DELETION LIFECYCLES✦Vector stores✦CONTROL PRESERVATION✦MCP tools✦REPEATABLE EVIDENCE✦Local-first testing
AI DATA LIFECYCLES, WITH EVIDENCE

Don’t just delete data.
Verify the evidence
behind it.

Make your deletion workflow a repeatable test. Explore the reference lab or connect a staging adapter, inspect the observations, and keep the evidence.

◈ Local first↻ Repeatable checks⌘ MCP ready
IN YOUR EXISTING WORKFLOW

Python CLI · Local dashboard · MCP tools

SCOPE → TEST → VERIFY
your-verification-labILLUSTRATIVE PREVIEW
VERIFICATION LIFECYCLE03 / 07
DELETE

Exercise the deletion path.

Run 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.

101

automated
tests passed

04

reference
failure patterns

02

local vector
backends

15

MCP
tools

Built around the way
data actually moves.
THE EVIDENCE DESK / RECORDED LOCAL RESULTS

Proof has
layers.

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

TRACE / BUILD RECEIPT01 / 03
REGRESSION SUITE101checks passed

Checks that protect the check.

Reference engines, external workflows, corrupted responses, concurrency, and interrupted-run recovery.

v0.3.2 · SYNAPSOUL LABS
◈Next: adversarial fault catalogue
RECORDED EVIDENCE

Regression suite

THE BOUNDARY

Download underlying evidence ↓
THE MEMORY ATLAS / INTERACTIVE ILLUSTRATION

One document.
More than one place.

A deletion response is the beginning of the story. Follow the copies, then explore what a complete check needs to observe.

PROJECT LANTERNILLUSTRATION · NOT A LIVE RUN

Baseline established. The document has more than one representation.

01 / THE EXPERIENCE

From “deleted”
to “here’s the evidence.”

A workflow that asks you to observe, not just assume.

⌘

Your workflow.
A more deliberate check.

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.

01Scope↗
02Establish↗
03Delete↗
04Observe↗
05Replay↗
◎

A failure you can
reproduce and replay.

Preserve a confirmed failure as a fixed regression definition. Compare broken and corrected fixtures using the same assertions.

Observe↗Preserve↗Replay
↗

Show the observations.
Keep the boundaries.

Missing observations stay inconclusive. An unrelated control must survive. A pass covers the declared fixture contract.

PASSFAILINCONCLUSIVE
Failure modes

Four ways data
can stay behind.

Small defects. Different lifecycles.
Each one has a broken and a corrected reference implementation.

YOUR ENGINE BACKENDBuilt in · no dependencies
SQLite reference PATTERN 01 / INDEX CLEANUP

The source is gone.
The vectors aren't.

A successful source deletion can leave derived records searchable. Check the index independently.

SQLite reference PATTERN 02 / BULK BOUNDARIES

One page deleted.
More pages waiting.

The first 100 records disappear. The last 25 don't. Trace enumerates the complete fixture inventory.

SQLite reference PATTERN 03 / INDEXING RACES

Deleted once.
Restored by a worker.

A worker reads an old snapshot and publishes after deletion. The fixture controls that exact interleaving.

SQLite reference PATTERN 04 / ANSWER CACHES

An old answer.
A surviving copy.

Source and vectors are empty. Repeating the query can still return a cached synthetic canary.

An evidence walkthrough

The same response.
Different things established.

A successful API call isn't a full inventory.
Choose an evidence set to see what it actually covers.

✓Delete request acknowledged.WHAT DO WE KNOW?
0/4DECLARED CHECKS
Acknowledgment only

No store inventories or control observation have been established.

Source —Vectors —Cache —Control —

Illustrative coverage comparison. This is not a live verification, confidence score, or guarantee of universal erasure.

03 THE INTERACTIVE LAB
BROWSER SIMULATION

Watch a deletion
break its promise.

Choose a failure pattern. Run the browser model.
Then switch to its corrected implementation.

REFERENCE SCENARIOS 04
IMPLEMENTATION

Runs entirely in your browser.
No uploads or external API calls.

trace / orphan_vectors
READY
THE TEST CONTRACT

Remove the source. Check the search index.

▤SOURCE
—source records
◈VECTORS
—indexed records
ϟCACHE
—cached answers
→ Waiting for your first simulation.
SYNTHETIC DATAOBSERVATIONS → VERDICT

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.

NEW IN v0.3.2 / STAGING WORKFLOW

One contract.
Every replay.

Run synthetic checks against an application you configure. Keep the assertions fixed as the implementation changes.

01

Connect a
staging target.

Register the application locally. Establish retrieval, inspect declared inventories, and preserve an unrelated synthetic control through the observation window.

02

Save the failure.
Keep the contract.

Persist evidence and an immutable regression definition. Checkpoints record synthetic IDs before writes, so interrupted runs leave a cleanup record.

03

Replay.
Compare the evidence.

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 ↗
03 CONNECT THROUGH MCP
ONE ENGINE. YOUR EXISTING WORKFLOW.

Your next run
starts right here.

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.

01

Inspect & planKnow the target and test effects.

02

Run & investigateRead actual observations.

03

Save & replayKeep the same assertions.

Set up locally ↗
◈ trace.mcpSTDIO / LOCAL
trace.inspect_targetDISCOVER
trace.plan_testsPREVIEW
trace.start_runEXECUTE
trace.get_runOBSERVE
trace.save_regressionPRESERVE
trace.replay_regressionREPEAT
trace.compare_runsCOMPARE
trace.get_learningEXPLAIN
Seven staging tools · locally registered targets only
trace.external_targetsTARGETS
trace.external_planPLAN
trace.external_startRUN
trace.external_getPOLL
trace.external_saveSAVE
trace.external_replayREPLAY
trace.external_compareCOMPARE
04 THE BUILD RECEIPTS
RECORDED NOVEMBER 3, 2026

A small release.
Verified locally.

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 ↗
✓
101 automated tests passedv0.3.2 · Windows / Python 3.13.12
LABELLED REFERENCE BENCHMARKv0.1.0
Local backendBroken → FAILCorrected → PASS
▤ SQLite4 / 4 ✓4 / 4 ✓
◈ Embedded Qdrant4 / 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.

A FEW IMPORTANT DETAILS

Good questions.
Clear boundaries.

Can I run it without funding?

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.

Will this scan my live application?

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.

Is Trace already a self-learning AI?

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.

What does a passing test establish?

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.

Does the browser demo run the actual engine?

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.

BUILD WITH SYNAPSOUL LABS

Run the check.
Keep the evidence.

Start locally. Inspect the outcome.
Keep the test that catches it next time.

Download Trace v0.3.2 ↓Python 3.11+ · Source ZIP · v0.3.2
$python scripts/launch.py serve
Extract the ZIP. Open the synapsoul-trace folder. Run the command.
Then open http://127.0.0.1:8765 on the same computer.
↑ ↓ navigate↵ openEsc close