Memory Shards
-Knowledge that grows without losing history. New observations supersede old via lineage links; identical content from different agents dedupes into a single record. Decay classes prune what shouldn't outlive its purpose.
- -diff --git a/templates/landing.html b/templates/landing.html index c67b62c..311ec4f 100644 --- a/templates/landing.html +++ b/templates/landing.html @@ -3,17 +3,17 @@
-- Content-addressed agent memory for AI systems. Shards that grow without losing history. Hash-chained traces that prove what ran. Encryption you can hand off without handing over keys. A library, not a service. + Durable memory, provable traces, scoped delegation, and entity resolution — a local-first library you drop under whatever agent stack you already run. Your data never leaves your machine. No service, no custody, no rent.
+See it running → frio.help · news.spiritwriter.ai
An agent that cannot remember what it learned, or prove what it did, is not infrastructure. It is a sketch.
-There's no standard library for the layer beneath the agent. So you keep rebuilding it.
+Most memory systems for AI either embed everything into a vector and lose the lineage, or they bolt on a database and surrender locality, ownership, and proof. Spiritwriter takes the older, harder route. Knowledge is broken into atoms with explicit fields. Atoms compose into shards. Shards are addressed by the hash of their contents, so identical content from different agents resolves to the same record — no duplicates, no drift.
+Every agentic app re-solves the same problems. Where does what the agent learned live — and how do you keep it from drifting into contradiction? How do you hand a sub-task to another agent without handing over the keys to everything? And when something breaks three steps back, can you prove what actually happened?
-Above the shards: traces. Every step an agent takes is appended to a hash-chained log; tampering with one entry breaks the chain after it. Entitlements let you delegate work to a sub-agent without surrendering master keys. Encryption comes in two postures, picked by who you don't trust. And entity resolution works by defining fields, not surface forms — so "Bear" the dog never silently merges with "Bear" the brand.
+So you rebuild the glue for each app, slightly different every time. Or you eat the misalignments, the delegation failures, the memory drift. Or you rent a managed service that takes custody of your data and your latency budget.
-It is a library, not a service. One pip install, no daemon, no vector store to host, no GPU. The artifact is the registry — version-controlled, emailed, restored from a backup like any other file.
Few teams do provable tracing or scoped entitlements without standing up heavy infrastructure. The layer beneath the agent has been left to improvisation — re-glued in every codebase, owned by none of them.
Knowledge that grows without losing history. New observations supersede old via lineage links; identical content from different agents dedupes into a single record. Decay classes prune what shouldn't outlive its purpose.
- -Local-first storage on disk; transparently fetches missing shards from a network when one is configured. Named refs handle the "latest version of X" pattern without breaking content addressing.
- -AES-256-GCM when the operator and key-holder cooperate. NaCl sealed boxes when the operator must not see content — multi-tenant hosting, source protection, zero-knowledge monitoring. Pick by who you don't trust.
- -spiritwriter is content-addressed memory, hash-chained traces, scoped entitlements, and deterministic entity resolution — composable primitives you dial from fully public and provable to fully private and zero-knowledge by changing one setting.
+Bring your own everything-else. spiritwriter handles what those layers leave out.
+Delegate scoped access to a sub-agent without handing over master keys. Tokens bundle decryption keys, scope patterns, capabilities, and budget; the store enforces every constraint before decrypting.
- -It's not an agent framework, and it's not a vector database. It's what those sit on.
+Package encrypted content + task + entitlement into one unit of sub-agent work. The orchestrator hands the package over; the sub-agent hydrates, executes, returns a result shard. Every step traced.
- -Tell entities apart when names collide ("Bear" the dog vs. "Bear" the brand) and merge them when surface forms diverge ("Carlos Martinez" vs. "MARTINEZ, CARLOS A"). Same engine, both directions. No graph database to operate, no embedding service to call — define your identifying fields, hand in records, get canonical IDs back.
- -Replay exactly what an agent did, prove nothing's been edited, render the run as workflow / genealogy / multi-agent diagrams. Hash-chained JSONL with optional Ed25519 signing.
- -We didn't write a spec and hope. Two live products run on the same library at opposite ends of the trust dial.
-Tamper-evident security audits for Android APKs. Inputs, evidence, findings, and final report bound into a hash-chained trace plus a self-hashing witness — anyone with the APK can re-run verification offline.
- -A zero-knowledge service that helps families find an incarcerated relative. The operator never sees the searches; matching happens in memory; alerts go out. No one running it can see who looked for whom — local-first taken to its end: the operator can't monetize what they can't see.
+ visit ↗Turn long-form text into atoms without losing facts at chunk boundaries. Overlapping windows + multi-pass extraction; only atoms that appear across multiple passes survive. The result feeds the shard store and the entity-resolution engine: extract once, resolve continuously.
- -A news engine that atomizes articles, rewrites them across the spectrum, and links every variant back to its source. The lineage is public — you can follow a single fact as it mutates from outlet to outlet.
+ visit ↗Same library. The only difference is the shard posture.
+ -A shard is an immutable record of atoms — facts, conventions, observations — bound to a scope and an origin. Its identity is the SHA-256 of what it contains, so writing the same shard twice is a no-op. Hydration returns XML-tagged context, ready to drop into a prompt.
+Store what your agent learns, hydrate it back into a prompt later. Get provenance on day one; lean on delegation and zero-knowledge when you're ready.
You're extracting facts about Aaron from a stack of documents. Document 1 surfaces "Bear is Aaron's favorite." Document 2: "Aaron and Bear were at the park." Document 3: "Aaron's dog Bear, a 10-year-old black lab / border collie mix."
+Entity resolution is where memory systems quietly corrupt themselves — merging two different people, or splitting one across three records. So we held it to a falsification battery, not vibes.
-Each document gives partial defining-field coverage. Your extractor classifies Bear three different ways. Three identifiers for the same entity, and they don't align. A naive system keeps them separate; a sloppy one collapses by surface name and now Bear-the-dog merges with Bear-the-beer-brand from Document 4. Embedding-based systems hallucinate the boundaries — "Bear" the dog scores close to "Bear" the bear scores close to "Bear" the brand, and the merge decisions become unauditable.
+100% auto-merge precision — zero incorrect merges across five benchmark corpora. And it surfaces 100% of same-entity matches: auto-merging the safe ones, flagging the rest for review, so nothing slips through silently.
-The resolver hashes the defining fields — name, entity type, owner, dob — into an Entity Sense Signature: a deterministic identity hash. As more documents land, the field set per entity grows. The growing field set produces a stable ESS the moment you have enough fields to disambiguate. Fields not yet known don't penalize — they're absent from the hash.
+No embeddings, no LLM in the merge path — deterministic hashing, normalization, and tiered escalation that fails loud instead of silently combining two different people. Backed by a falsification battery, a workshop curriculum, and runnable examples.
-The same primitive handles the inverse. "Carlos Martinez", "MARTINEZ, CARLOS A", and "C. Martinez" across three rosters dedupe into one entity, because their defining fields normalize to the same hash regardless of surface spelling.
+Encrypted search shards and fuzzy name matching for monitoring without disclosing the watchlist.
- visit ↗ -Two points of view per story, plus transparent bias detection, source selection, and reader analytics — every judgment auditable through the trace.
- visit ↗ -AI-generated podcasts assembled from multi-agent video production traces.
- visit ↗ -Canonical worked example for traced workflows; checkpointed multi-stage producer agent.
- visit ↗ -| Memory that drifts into contradiction | +Content-addressed shards with lineage, supersession, and decay. | +
| "Can I let a sub-agent see this?" | +Scoped entitlements — keys + scope + capabilities + budget, enforced before decrypt. | +
| "What did the agent actually do?" | +Hash-chained, signable traces you can verify offline. | +
| Duplicate / colliding entities | +Deterministic-then-fuzzy resolution, no embeddings. | +
| Privacy vs. transparency | +The same dial — AES, sealed boxes, or fully public. | +
| Sharing across machines | +Private IPFS swarm, no database. | +
One pip install. No service to host, no vector DB to keep alive. Read the source — it is the documentation that compiles.
+One pip install. No service to host, no vector DB to keep alive, no one in the middle of your data. The artifact is yours — commit it, back it up, hand it off.