01
Where did the agent get this?
Compliance asks. You have a model name, a transcript, and three log files in three places. The retrieval set that produced the answer was discarded after the request.
Reproducibility
An AI agent's
memory you can
defend.
For teams shipping AI agents into clinical trials, drug safety, and translational research. A self-hosted memory layer where every output is reproducible from stored evidence, every claim cites its source, and every change is verifiable. One binary. Zero cloud. No patient data ever leaves the machine.
You can't show your work.
Every state-of-the-art agent memory layer treats the model as a trusted writer. The data model assumes good faith. So when the obvious question arrives, you can't answer it in less than four hours.
02
Was that protocol still current?
The agent cited a guideline. It was correct three months ago and superseded last week. Your memory layer has no concept of valid-from and valid-until. The wrong version sat in retrieval.
Time
03
Did the agent see the contradiction?
Two notes in different sessions said different things. The agent silently used whichever was retrieved last. There was no signal that the conflict existed.
Conflict
"The transcript is not the audit trail. The audit trail is the chain of evidence that produced the transcript."
Field note · From a discovery call with a clinical-AI team, 2026
Three primitives.
Plain English.
Wired into the storage layer so they can't be opted out of. Each one replaces an afternoon of manual reconstruction with a single query.
Tamper-evident change log
Every change leaves a fingerprint.
Each note, each edit, each model call gets a fingerprint linked to the previous one. If anything was tampered with, the chain shows you exactly where. Your audit trail becomes a chain you can verify — not a story you have to tell.
Memory that earns its place
Knowledge gets cleaner over time.
Notes earn durability through repeated, time-spread access. Old + replayed = important. Old + abandoned = fades. The graph stops bloating. The most-cited knowledge consolidates into durable schemas.
Citations the system enforces
Every claim cites its source.
A claim that doesn't textually overlap with a cited source is rejected at write time. Not "logged" — rejected. The model can't quietly invent a citation, because the storage layer won't accept one.
Time
Knows when a fact stopped being true
Every link carries valid-from and valid-until. Stale guidance can't quietly resurface.
Conflict
Surfaces contradictions, doesn't bury them
When two notes disagree, the system tells you. No silent overwrites.
New in v0.3
Triages memory the way a brain does
Frequently-accessed knowledge hardens into durable schemas. Abandoned notes fade.
Replay
Re-runs a model call from stored metadata
Same model, same prompt, same retrieval set — bit-identical answer. By design, not by hope.
Footprint
One binary. No services. No cloud.
A 30-megabyte program plus a database file. Air-gappable. Deployable anywhere.
Custody
Your data never leaves your stack
Smriti runs on your hardware, against your database file. No vendor in the middle. No telemetry.
New · Path A
Your documents, queryable by any local LLM
Ingest .txt and .md files into the graph. One call returns assembled context — no cloud, no API key, no embedding model required.
Four real chains.
Every primitive on this page is grounded in a working scenario — across revenue cycle, clinical trials, and biotech — with sources, claim spans, and bit-identical replay. Each demo is replayable against the smriti store — not a screenshot, not a mockup.
$ smriti graph --as-of 2024-03-14 payer-policy-UHC-MN ─── time-aware retrieval ──────────────────── active policy UHC-MN-2024-03 (2024-01-01 → 2024-12-31) superseded by UHC-MN-2025-01 (2025-01-01 →) — excluded: not retroactive to date of service $ smriti audit replay call_5b1e9c3a ─── appeal letter grounding ────────────────── claim "Level-4 visit: 2 of 3 required components" cited policy UHC-MN-2024-03 §4.2 provenance 1.00 literal-match verified spans 6 of 6 stored hash 7c91…4a2f re-run hash 7c91…4a2f match ✓ bit-identical
Use case 01
Prior-auth appeal — grounded to the payer policy in force on the date of service
Which policy applied on the date of service — the one in force then, or the one in force today? Smriti pins retrieval to 2024-03-14, the actual date of service, and returns UHC-MN-2024-03 — not the 2025-01 revision that happens to be current when the appeal is drafted. 18 minutes vs. typical 4 hours.
Pain shape
A wrong policy version doesn't just lose the appeal
Payer policies update quarterly. Appeals are often filed months after the date of service. A naive retrieval pipeline grabs whatever policy is "current" at query time — silently wrong more often than teams realize. Under the False Claims Act (§3729), a wrong citation in a submitted appeal isn't an admin error, it's exposure. Smriti's bi-temporal edges make "true as of the date of service" the default, not an edge case.
Live in store
6 verified claim spans · 2 policy versions tracked · SHA-256 chain intact
Open the live demo →
$ smriti audit replay call_8f7a02e1b ─── reproducibility check (Subject 14) ────── model llama3.2:1b seed 42 prompt template clinical_qa@v3 retrieval set [ n_s3_1, n_s4_1, n_s5_1 ] stored hash a3f2…0e1b re-run hash a3f2…0e1b match ✓ bit-identical $ smriti graph --as-of 2026-03-10 trial-A ─── time-aware retrieval ──────────────────── active protocol v2.1 (2025-11-01 → 2026-03-13) superseded by v2.3 (2026-03-14 →) — excluded: not retroactive (ICH E6(R3) §4.2.1) $ smriti contradictions list ─── open inbox ────────────────────────────── 100bd551 Subject 22 v2.1 vs v2.3 score=0.728 authority=1.00 cite-disagreement
Use case 02
Clinical trial protocol amendment defense
FDA asks: was Subject 14 evaluated against the current protocol? The chain returns the active protocol on the date of screening, the AI-generated summary that cites it, the bit-identical replay, and a flagged contradiction the system surfaced before the regulator did. 11 minutes vs. typical 4 hours.
Pain shape
Reproducibility + Time + Conflict — all three primitives in one walkthrough
Protocol v2.1 was active on 2026-03-10. v2.3 took effect 2026-03-14. Subject 14 was screened 4 days before the amendment. Smriti's temporal edge filtered v2.3 out of retrieval automatically. Without that filter, the AI would have cited the wrong policy and the audit chain breaks.
Live in store
9 notes · 4 sources · 4 verified claim spans · 1 contradiction
Open the live demo →
$ smriti notes_consolidate --dry-run --policy conservative ─── replay signal, senescence panel ───────── episode n_ipf_cohortA access=14 contexts=3 score=0.71 episode n_ipf_cohortB access=9 contexts=2 score=0.64 episode n_ipf_cohortC access=11 contexts=3 score=0.68 ⚠ IL-6 disputed $ smriti graph traverse senescence-panel --depth 1 ─── candidate cluster ──────────────────────── replicated p16INK4a, MMP-7 similarity 0.86 across 3 episodes flagged IL-6 — Cohort C disputes specificity (confounded by concurrent infection) — not deleted $ smriti audit consolidation-events schema_ipf_panel_v1 ─── promotion event ────────────────────────── event promoted_to_schema 0.00 → 0.79 lineage n_ipf_cohortA, n_ipf_cohortB, n_ipf_cohortC
Use case 03
Senescence biomarker panel — three IPF cohorts consolidate into a schema
Mayo IPF Registry (2024), UCSF Aging Lung Cohort (2025), and a multi-center validation study (2026) each cite overlapping senescence markers against FVC decline. Smriti's consolidation engine tracks replay frequency, context diversity, and recency, then promotes the replicated pattern — p16INK4a and MMP-7 — into a durable schema, while routing the disputed marker (IL-6, confounded by infection) to a human review inbox instead of averaging it away.
Pain shape
Replicated knowledge should get more durable, not just bigger
Most memory layers treat consolidation as summarization — compress and move on, dissent included or lost silently. Smriti's CLS-inspired consolidation (McClelland 1995) keeps every source episode addressable, writes an audit event for the promotion, and never hard-deletes a disputed finding.
Live in store
3 source episodes · 1 schema promoted · 1 contradiction flagged · full lineage
The mechanism behind "knowledge gets cleaner over time" (see Approach, ii). Open the live demo →
$ smriti graph traverse CB-209 --depth 2 ─── multi-hop chain ───────────────────────── [compound] CB-209 (PKC inhibitor) ├─ [dosage 100mg] safe; 18% CRP < 30% endpoint └─ [dosage 300mg] efficacious; 29% Tn-T > 0.10 — DLT triggered, cohort closed $ smriti audit replay call_7d3a ─── dose synthesis ────────────────────────── output 200 mg once daily (MTD for Phase III) rationale interpolation 100mg ↔ 300mg reaches efficacy + below toxicity verified spans 2 of 2 → trial protocol → Troponin-T reference stored hash 2e8b…7c4b re-run hash 2e8b…7c4b match ✓ bit-identical
Use case 04
Lab-trial synthesis — IND amendment for CB-209
Two dosage arms produce conflicting evidence: 100 mg is safe but sub-efficacious (18% CRP reduction vs 30% endpoint); 300 mg is efficacious but triggers the dose-limiting toxicity rule (29% of subjects with Troponin-T above 0.10 ng/mL). The AI traverses the compound → dosage → biomarker graph and recommends 200 mg as the maximum tolerated dose. Filed in FDA IND amendment 2024-11-22.
Pain shape
The recommendation must reconstruct on demand
An IND amendment narrative has to defend itself a year later, in front of an FDA reviewer, against the same evidence. Standard memory layers can't replay the model call against the dosage curves and biomarker thresholds as they existed at the moment of the recommendation. Smriti's frozen retrieval set + verified spans solve this structurally.
Live in store
5 notes · 3 sources · 2 verified claim spans · multi-hop traversal
The killer demo:
smriti graph traverse CB-209 --depth 2 returns the full evidence chain in one call. Open the live demo →
The boring receipts.
Measured benchmarks. Peer-reviewed research. No demo magic. Every claim on this page is verifiable against the codebase.
$ smriti verify --chain ─── chain integrity ────────────────────────── events scanned 50,127 chain integrity ✓ verified prior tampering ✓ none detected last event 2026-05-08T14:21:33Z walk time 487 ms $ smriti audit replay call_8f7a02e1b ─── reproducibility check ──────────────────── model llama3.2:1b seed 42 prompt template clinical_qa@v3 retrieval set [ n_s3_1, n_s4_1, n_s5_1 ] stored hash a3f2…0e1b re-run hash a3f2…0e1b match ✓ bit-identical $
Paper
Verifiable Agent Memory
Working draft, 2026 — a formal integrity contract for LLM-augmented knowledge graphs.
Research
Six peer-reviewed foundations
Memory consolidation, belief revision, citation grounding, time-aware retrieval — distilled into one storage layer.
Audit cost
Sub-millisecond per call
The integrity layer adds < 1 ms per LLM call — about 2% of typical inference latency.
Ownership
You own the artifact end to end
Your binary, your database file, your audit trail. No vendor between you and the regulator.
2.5µs
Memory retrieval p50
in-memory · M-series Mac
235ns
Graph traversal
cached two-hop walks
≈ 30MB
Binary footprint
vs ≈ 1 GB Docker stacks
0
Cloud dependencies
offline-first by design
If you've ever had this conversation, talk to us.
In customer discovery, not selling. Twenty minutes; you talk, we listen.
- Your compliance team asked you to defend a model output, and you spent half a day reconstructing what happened from log files.
- You're shipping an agent into a clinical, biotech, or healthcare workflow and existing memory layers don't fit the audit posture.
- You need a memory layer that's self-hosted by default — your data, your hardware, no vendor between you and the regulator.
- You've watched an agent quote a superseded protocol as if it were current and have no clean way to express "true between dates X and Y."
If your compliance team asks that question more than once a quarter, talk to us.
Thank you — we'll be in touch within 24 hours.
We read every message personally. If you don't hear back, ping sruthia9999@gmail.com.
Something didn't send.
Please email sruthia9999@gmail.com directly — we'll reply faster than the form would have anyway.
Or email sruthia9999@gmail.com — same destination, no form.