Heather
Storage native intelligence
Storage native intelligence. Heather is a blueprint for systems whose intelligence comes from how data is organised, not from what runs over it afterwards. HeatherDB is the first system built to that blueprint: a database that learns from every write, without a model, a training run, or a GPU. Embed it in your process or run it as a server; the memory is the same either way.
Those two names are worth separating before anything else. Heather is the paradigm — a claim about where intelligence can live, and a set of properties a system has to hold to keep it there. HeatherDB is one implementation of it, the one you can install this afternoon. The blueprint is not finished by the database; agent memory, embedded intelligence on hardware that cannot host a model, and reasoning engines all sit on the same primitives.
The name is a debt. Kanerva is Finnish for heather, and Pentti Kanerva is the researcher whose sparse distributed memory and hyperdimensional computing this system descends from — the lineage is its own page.
Organisation as computation
Every paradigm answers one question differently: what does it mean to compute? Von Neumann fetches an instruction, decodes it, executes it, repeats. Dataflow pushes tokens through a graph. Neural networks push an input through a pile of learned weights. All of them keep storage and processing apart — you put data somewhere, then you move it to the thing that thinks.
Heather removes the second step. Intelligence is a property of the arrangement, so the act of placing data is the computation. A write is not a save; the system finds where the new pattern belongs among everything it has already seen, forms associations with whatever it lands near, and reshapes the neighbourhood so the store stays a good map of the data it holds. Nothing runs afterwards to make the data meaningful. The organisation is the meaning, and reading is just letting a query fall into it.
This makes Heather the counterpart of the neural-network paradigm rather than a variation on it.
| Model native | Storage native | |
|---|---|---|
| Where intelligence lives | In weights, learned offline | In the arrangement of stored data |
| When learning happens | A training run, then inference | Every write |
| Absorbing new data | Retrain, fine-tune, or re-index | Write it |
| Hardware | GPUs | Whatever runs a database |
| What comes back | A prediction | A reconstruction, with a fidelity score |
What emerges from it
Intelligence here is not a feature list; it is what a well-organised memory does for free. Four behaviours come out of the arrangement, and they are the ones the brain gets without trying.
Reconstruction is the first. Three seconds of a song through a bad speaker in a loud room and you have the whole track — you did not scan a catalogue for the nearest match, the fragment pulled the memory into shape. Hand HeatherDB a corrupted vector, a partial query, or a noisy sensor reading and it settles onto the pattern that fragment belongs to, then tells you how far it had to travel to get there.
Association is the second, and it costs nothing extra. You do not keep two separate words for bank; you keep one, and the surrounding sentence decides whether you are standing on a river or in a queue. Nobody built you that graph. Here the associations are a by-product of storage: things that mean similar things are written near each other, so relatedness is where they sit rather than an edge somebody declared.
Learning starts at the first write. A baby is intelligent on day one — badly informed, but already generalising. There is no threshold of data below which nothing works and no warm-up period to sit through; the first write makes the system slightly better at its job, and the millionth does exactly the same thing.
And none of it erases itself. Learning your new phone number does not delete the old one, but train a neural network on a new task and it will happily overwrite the last — catastrophic forgetting, the reason most learned systems are frozen the moment they ship. Writes here settle alongside what is already stored rather than on top of it, which is what makes a system that keeps learning in production a reasonable thing to run.
Not a vector database
Both store vectors, and the resemblance ends there. A vector database is an index; Heather is a memory.
An index gives you back the rows nearest your query, and its answer is always something you put in. A memory gives you back the pattern your query is trying to be — which may be a stored item, or the shape a family of stored items agree on, and that shape is no single row you ever wrote. The intelligence in a vector stack also arrived with the data: an embedding model made the vectors meaningful, and the index only finds them quickly. Nothing is learned after ingestion. Here the structure is produced by the writes themselves, and it keeps forming after the data lands.
That difference shows up as maintenance. Relationships in a vector stack are things you build and keep building — metadata filters, a knowledge graph, a re-ranker — and the index itself is built, then rebuilt when the distribution drifts. Heather has no separate index to fall out of date, because every write is already a small reorganisation. Drift is absorbed rather than repaired.
Algebra over stored meaning
Because everything is a vector in one high-dimensional space, meaning can be composed arithmetically: bind a role to a filler, bundle several bindings into one vector, subtract what you do not want, ask what does not belong. A whole structured record fits in a single vector you can do algebra on. This is the vector symbolic tradition, an old and quiet line of AI research that never needed a neural network.
It stayed quiet because every one of those operations leaves the answer approximate, and an approximate vector is useless without something to snap it back onto the item it was reaching for. That something is a cleanup memory, and it is usually the part nobody has. Heather is the cleanup memory — reconstruction is its read path — so the expensive half of symbolic computation is the half the database already does. That is what makes knowledge algebra a query language here instead of a research demo. The operations are in the vector algebra reference; the reasoning behind them is on the vector symbolic architectures page.
What it is for
The practical consequence of putting intelligence in the store is that it goes wherever storage goes. No GPU, no ML runtime, no serving stack — an edge device or the small VPS you already pay for is enough, and the system that runs there keeps learning instead of being frozen at deploy. What you get in return for that modesty is a system whose operations you can point at: bind, bundle, subtract, reconstruct, over data you can name, at a moment when the alternative is an opaque model and a bill.
The two tracks
These pages are two things at once, and you can take either without the other.
Heather is the paradigm — what similarity means and how you choose it, what a memory can be asked, how to know an answer is trustworthy, and where the technique stops. Start at storage native intelligence and what similarity means; the encoding guides turn it into practice.
HeatherDB is the implementation — a single binary you install, tune, secure and back up. Start at Deploy HeatherDB and Run it in production. None of it asks you to accept the paradigm first.
Where to start
Every technical term on this site has a page of its own — bind, fidelity, attractor, and the rest of the glossary — each explained twice: once like you are twelve, with a picture, and once precisely.
Getting started installs the engine on your platform —
container, pre-built binary, or one cargo build — and has you reconstruct a
corrupted vector within ten minutes. The tutorials are the argument on this page,
demonstrated rather than asserted: five lessons, each turning on one result you
produce yourself — reconstruction, learning without a training step, structure
without a schema, fidelity as a judgement, and new knowledge that leaves the
old intact.
How the memory works is the mechanism
underneath it, and the paper is the
formal account of Elastic Associative Memory, the model Heather implements.
Start here
Install the engine and watch it reconstruct something.
Tutorials
Learn the engine by watching it do something a database should not be able to do.
Everything you know about making a computer do something intelligent probably starts the same way: choose a model, collect data, train it, serve it, watch it drift. This lesson is the first of five that take that sequence apart. There is no model here and no training step — only a store you write to and read from.
In Your first memory you wrote 200 vectors, handed the engine a query that was only 0.77 similar to the pattern it came from, and got back one that was 0.99 similar. You also saw that 200 vectors became 51 hard locations — the engine grew a codebook rather than filing your rows.
Every vector so far arrived ready-made. Your first memory and It learns while you watch drew random directions and added noise to them, which was honest for showing what the memory does but dodged the only question you will actually have to answer on your own data: what should the numbers be?
Encode something real left you with three collections of card transactions and a problem: a read returns 128 numbers. Not a transaction. Not an id. Not a row you can put in front of a human or an alerting system.
Two lessons in, a vector has been one indivisible thing: you write it, you get a cleaned-up version of it back. It learns while you watch showed the memory sharpening as data arrives, but everything it stored was a single blob with no parts.
Three lessons in, every question you have asked has had an answer worth having. You wrote patterns and read them back; you built records and pulled their fields out. The engine cooperated because you only ever asked it about things it knew.
You can encode data, store it, ask questions of it, and turn an answer back into a thing. Every lesson so far ended with a number that looked good.
Four lessons in, you have a memory that reconstructs corrupted queries, sharpens as data arrives, holds structured records in single vectors, and tells you when it does not recognise something.
Eight lessons, all on data chosen to make a point. You have watched a reconstruction beat the row it came from, watched a memory sharpen without a training step, held a record in one vector, made an answer legible, derived a threshold instead of guessing one, measured a claim honestly, and written an unrelated subject on top of a first without disturbing it.
How-to guides
Task-shaped directions for someone who already knows what they want.
Turn a row of typed columns — an order, a transaction, a sensor reading, a user profile — into one unit vector whose direction carries every distinction you want reads to see.
Turn a string — a title, a description, a message, a document — into a vector whose direction carries what the string is about.
Give a continuous value a direction whose similarity falls off smoothly with numeric distance, instead of the step function a bucket gives you.
Pick the one number you cannot change later. Dimension is set at database creation, immutable afterwards, and it is an interference knob — not a capacity setting you raise until the warnings stop.
Subtract your corpus mean before you compare anything that came out of a learned model. Without it, cosine over embeddings is near-1 for every pair and discrimination collapses.
When recall falls as a collection fills, split it into many collections and route each query to one of them. Capacity is per pool, so the escape from a capacity wall is more pools — not more dimensions.
Evolve a field — an image, a temperature grid, an option price surface — to any time you ask for, in one round trip per timestamp, with no timestepping loop.
Differentiate and integrate a function without a difference quotient, a quadrature rule, or a step size — by binding it with one operator vector, and unbinding it with the same one.
Hand the method raw trajectories — pairs of states, nothing else — and it returns the combination of features that does not change along the flow. No equations, no model class, no candidate law. The true quantity, where one is known, enters only to grade the answer.
Most systems conserve nothing. Their law is still readable from raw trajectories: fit the operator that advances the state, eigendecompose it, and each eigenvalue is a decay rate and a frequency.
Write history as windows, then read the next window back by pattern completion: put the part you know into the query, leave the part you want predicted blank, and the memory fills it in. No training step, no forecaster object.
Store (state, action) → next state as bindings and the collection predicts. This page builds one, rolls it forward, and measures how far it can be trusted. The concepts are in World models.
Predict what a treatment, perturbation or configuration change will do to a subject you have never applied it to — from before-and-after measurements alone, with no equation for the mechanism.
Keep a procedure so a situation recalls it — no name to look up, no key to remember — and so several instances collapse into one vector that handles a case none of them covered. The mechanism is in Mnemonics; this page is the recipe.
Make an agent that explores an unknown space on its own — no reward signal, no map, no gradient — using the store's own familiarity number as the compass. Why that number points anywhere is in Curiosity; this page is the loop.
Dreaming is the engine reprocessing its own memory. It is a write: it changes what a collection holds, and in replay mode it changes it in place. This page is the operational procedure — when to run it, which mode, what moves afterwards, and the four ways it surprises people.
Rank a catalogue for one person from what that person has already done, with no training step and no nightly rebuild.
Flag observations that do not fit a stream's normal, using only normal examples, and report what normal would have looked like instead.
Retrieve passages by meaning, and keep retrieving them when the query is partial, misremembered or noisy.
Assign a label from a handful of examples per class, and add a new class by writing it.
Suggest the word that follows what someone just typed, learned from their own text, with no model in the process.
Decide, for each incoming record, whether it is a duplicate of something the system has already absorbed, a near-duplicate worth flagging, or new.
Give an agent associative context across sessions without carrying the entire history in its context window. This recipe uses competitive learning: turns contribute to a shared representation, rather than guaranteeing exact episode reconstruction. A language model still produces the language response; see Pair the memory with a language model.
Use competitive mode for an adaptive associative memory. Use plain mode when each supplied vector should remain a separate, unchanged location. Both modes support associative recall; they differ in how writes represent observations. The mode applies to every collection in a database.
A read returns a vector, not a row. To turn that 128-float array back into a title, an id or a sentence, keep a sidecar store of item → vector and resolve the reconstruction against it.
A document is a vector written with metadata attached. It keeps its own id and stays individually retrievable, searchable and deletable, alongside the hard locations that absorbed its vector.
A gate is the threshold that decides whether an answer is worth returning. Derive it from a labelled held-out sample; do not choose it.
Before believing a score, measure what it reads on data that has none of the structure you are claiming. That reading is the floor. Your number means whatever it means above the floor, and nothing below it.
Attribute an answer to what produced it, using the read path itself. No second model, no surrogate, no post-hoc explainer.
Combine, weight and subtract whole bodies of knowledge with the collection algebra, and verify each operation with a fingerprint before and after.
Split the work along its natural seam: the memory does storage, recall and scoring; the model does language. Anything you can do with a dict, keep in ordinary code.
HeatherDB is a single Rust binary with no GPU, no accelerator, and no system dependency beyond libc. Every install path below lands on the same layout — /usr/bin/heather, /var/lib/heatherdb, /etc/heatherdb/env — so they are interchangeable and you can move between them later.
Deploy HeatherDB gets a process running. This page is what to settle before real traffic reaches it, and what to keep doing afterwards. Work top to bottom the first time; the checklist at the end is the version you copy into a runbook.
HeatherDB uses HTTP Basic Auth, on by default, backed by an LMDB-resident user store at $HEATHERDATADIR/system/data/. Passwords are hashed with Argon2id.
One HeatherDB server hosts N databases. Each has its own LMDB environment, its own db.toml, its own directory under $HEATHERDATADIR/db/, and — the part that usually drives the decision — its own vector dimension.
Most deployments never touch any of this. Reach for it when you have a concrete symptom.
Three operations, each for a different situation.
Every database keeps a persisted access log of who read what, when, and what came back. It is on by default — a security control, not a feature you have to discover.
HTTP API
Every route the engine serves, one page per resource.
The front door to the HTTP API section. Everything here applies to every endpoint; the per-resource pages document only what is specific to a route.
Liveness and readiness. These four are the only unauthenticated routes: the auth middleware whitelists them before it looks at any header (auth::isunauthroute). See Overview for conventions.
Session tokens. Basic auth pays an Argon2 verify (~11 ms) on every request; a bearer token skips it. Both routes are exempt from the scope check — minting and revoking your own token is an identity operation, so any authenticated user may call them regardless of database scope.
Create, list, inspect and drop databases. A database owns one LMDB environment, its own vector dimension, and its own collections.
Lifecycle and introspection of collections. A collection is one Adaptive Elastic Associative Memory inside a database; it inherits the database's dimension.
Two ways to put vectors into a collection: write, which learns competitively, and bulkload, which does not.
Recall from a collection. Six routes: the plain Hopfield read, three attention variants, analyze (a read with its activation trace), and batchanalyze.
A document is a vector written with metadata (see write). It keeps its own id and is retrievable and searchable independently of the hard locations that absorbed it.
Vector algebra over whole collections. Each op reads one or two source collections, computes, and writes the result into a target collection, creating the target if needed. Sources must exist (404 otherwise).
Stateless vector math: no collection, no database, no persistence. These are the only routes with no /db/{db} mirror, because they never touch storage.
The per-database access log. One route, and no legacy form — the audit log is addressed by database only. See The audit log and privacy and Read the audit log.
On-demand consolidation. One route, and no legacy form — dreaming is addressed by database only. See Dreaming.
Reference
Look things up here while you work.
The HTTP API is documented one page per resource group under docs/api/. Start at the API overview for the conventions that apply to every route: the legacy vs /db/{db} dual-route shapes, authentication, scope, the error format, and the server-side caps.
Three layers, in order of scope:
Every knob, what it controls, and what a wrong value looks like from outside.
The catalogue of ways to turn a thing into a vector.
The measured limits of superposition, and what to do at each wall.
Measured source revision: 0e08be78b7164b3733f7d60654b73f6a1862ec08. Binary: heather 1.0.0. The benchmark page presents native execution time, authenticated HTTP latency, associative recall and shared-pattern learning as separate measurements. These measurements apply to the recorded source revision.
Read the HeatherDB release history for version-specific changes, upgrade guidance, known limitations and artifact links. Historical entries preserve their source revision and publication date.
Behaviour a caller must know before it bites. The Loud? column is the one to read first: a loud behaviour returns a status code you can branch on, a silent one returns 200 and a plausible-looking result.
The heather binary is both the server and the admin tool. With no subcommand it starts the HTTP server; with a subcommand it runs synchronously against the data directory and exits.
Registered before running the experiment, 5 November 2026. This is a synthetic learning benchmark, not an individual-record recall benchmark or a standard industry leaderboard. Production engine algorithms and defaults are unchanged.
Status: release contract for 1.0.0, 5 November 2026. Acceptance evidence and operational limits are recorded in the release audit.
How HeatherDB keeps vectors on disk, and how it stays safe when the bytes it reads are not what it expects.
Explanation
Background reading, for when you want to know why.
Storage-native means the arrangement of the data is the computation: there is no model beside the store that has to be trained, served, and watched for drift.
The encoding decides which two things count as similar, and that decision is the entire design surface of a storage-native system.
A read that reports its own confidence gives refusal for free: the same number that answers the query says whether the query should have been answered.
HeatherDB is a Rust workspace of three crates behind one HTTP binary. This page covers how they fit together, the one routing pattern that surprises people, and the concurrency and storage models underneath.
In competitive mode (the default), HeatherDB learns a shared representation. It stores patterns distributed across a self-organising network of hard locations and reconstructs them from approximate queries. This page explains what that actually means mechanically, and what it costs. Plain writes (competitive: false) instead retain each vector as its own location. See Choose a memory mode for individual recall, adaptive learning and graceful forgetting.
HeatherDB's competitive mode supports associative recall and shared-pattern learning. Plain mode preserves individual vector locations. The two modes use different write representations.
Transformer attention and an associative-memory read are the same operation: under stated settings, HeatherDB's read reproduces attention bit-exactly.
Capacity is a property of a pool, not of a database: roughly D/32 patterns can be superposed into one pool before per-read recall degrades.
Every algebra operation leaves its result approximate, so composition is reliable only when a cleanup read sits between levels to reset the noise floor.
When the engine has been idle for a while, it can reprocess its own memory: no external input, no second collection, nothing to ingest. A collection simply wakes up better organised.
On top of the associative memory sits a compositional algebra: Vector Symbolic Architecture in the Holographic Reduced Representation tradition. It is what lets you build structure — roles bound to fillers, sequences, sets — out of fixed-width vectors, and pull it back out again, with no neural network in the loop.
A vector symbolic architecture is a way of doing symbolic computation without symbols — no parser, no graph, no neural network. Structure is represented as arithmetic over high-dimensional vectors, and the structure can be taken apart again by the inverse arithmetic. It is the tradition HeatherDB's algebra comes from, and this page is the reasoning behind it. For the operations themselves, see vector algebra.
A world model answers one question: (state, action) → next state. That is a binding held in an associative memory, so a collection that stores transitions is a world model. No module is added to the engine to get one.
Storing a worked example is not storing the formula. A worked example answers tasks shaped exactly like the one it came from and nothing else. The general form of a relationship is a different object — a single vector, built by binding, that derives the case it has never seen.
An honest memory answers "I have not seen this" and stops. A curious agent reads the same sentence as an instruction: go there. Curiosity is abstention with the sign of its own signal flipped.
Replaying what a memory already holds through the rule that wrote it changes what the memory holds. Nothing is ingested and nothing is queried, yet the collection afterwards is not the collection before — because the write rule is order-dependent, and a stored collection is partly a record of the order it arrived in.
A linear operator that is diagonal in the Fourier basis becomes a single multiplication there — and multiplication in that basis is exactly what binding is. Evolving a field is therefore one database operation, and time is a parameter of it rather than a loop.
Almost everything in this system descends from the work of one researcher, and the project is named after him.
The regime in which a storage-native store is the right instrument, stated as properties rather than caveats.
Every database keeps a persisted record of who read what, when, and what came back. This page is about the three design decisions behind it, each of which trades something away deliberately.
Glossary
One idea per page, explained twice — once like you are twelve, once precisely.
A list of numbers that stands for a thing — and, read as coordinates, a direction in space.
A space with thousands of directions, where random things almost never point the same way.
Two vectors pointing in unrelated directions — at right angles, sharing nothing.
How closely two vectors point the same way, from 1 (identical direction) through 0 (unrelated) to -1 (opposite).
The tendency of learned vectors to crowd into a narrow cone, so that everything looks similar to everything else.
The noise every stored pattern contributes to every other one — the price of keeping many things in the same space.
Combining two vectors into a third that resembles neither, and can be taken apart again.
Undoing a bind: given the compound and one of its parts, get back the other part, approximately.
Adding several vectors into one of the same size that still resembles all of them.
Several things stored in one vector at once, all still readable.
Shuffling a vector's components in a fixed, repeatable way — the trick that encodes order.
Turning a continuous quantity into a vector by raising a base vector to a fractional power, so nearby values give nearby vectors.
Storage that is addressed by content rather than by location — you ask with part of the thing, not with where it lives.
A dent in the landscape that nearby states roll into — the shape a remembered pattern makes.
The 1982 model that made "memory as a landscape you fall into" precise — and the direct ancestor of how a read works here.
How much the memory had to change your query to make it into an answer.
The thing that takes a smudged vector and hands back the clean item it was reaching for.
A version of your data with the structure you are claiming removed, and everything else left intact — run through the identical pipeline.
Scoring a memory with the answer barred from participating — the only way a score means anything once the data is already stored.
A quantity that does not change while everything else does.
Something that answers one question: if the world looks like this and I do that, what happens next?
Running a prediction forward more than one step by feeding each answer back in as the next question.
A sequence of actions chosen by imagining where each one leads.
Choosing where to go by finding where the memory is emptiest.
A stored rule rather than a stored answer — the thing that produces cases you have never seen.
What a memory does with idle time: replaying what it already holds, and keeping what recurs.
Learning from each example as it arrives, instead of from a dataset in a training run.
A substantial, unwanted loss of previously learned behaviour while learning new data or a new task. Shared representations can change in ways that impair earlier tasks; the severity depends on the data, architecture and learning rule. Replay, regularisation and separate capacity are among the ways to limit it.
The gradual reduction of an earlier pattern's influence as an adaptive memory learns changing patterns. It is useful when current knowledge should take priority over reproducing every past observation.
Kanerva's model of memory as a huge address space, sparsely occupied, where writing touches many places at once.
The memory model HeatherDB implements: an associative store whose structure reshapes itself as data arrives.
Doing symbolic computation with high-dimensional vectors and arithmetic, instead of symbols and pointers.