Not a log. Not a summary. Not a vector store.
Substrate memory is a record a later reasoning session reads back to orient itself, rather than a transcript a person skims. It resembles three familiar things and is none of them.
a log
A log is an append-only, time-ordered stream. Substrate memory is append-only too, but its entries carry typed relationships — supersedes, references, implements — that a flat log has no place to record. You traverse a graph, you do not scroll a timeline.
a summary
A summary is lossy by design: it keeps the gist and drops the reasoning. An entry is the primary record, written as the work happens, that a later session reasons over directly — not a compression of it made after the fact.
a vector store
Embeddings find what is related by similarity, rediscovering relevance on every query. Substrate memory keeps relevance already encoded in the links: what superseded what, what answered what, who asked. Structure the model reads, not distance it recomputes.
Three axioms
- 01
The reader is the model.
A hundred thousand words is a novel — hours of human reading, and most of it gone by the last page. A model reads the same novel in seconds — a thousand times faster — and has done so, in full, before it writes a single word of reply. Every turn. That gap is not large, it is categorical, and it is the entire reason a substrate can exist: every memory format before this one was shaped for a reader that skims, forgets, and paginates, because until language models there was no other reader to shape one for. This one is shaped for the reader that takes in the whole graph at once and reasons over its structure — traversing supersessions, weighing provenance, following links — as fast as it reads. That reader is never the human, and that asymmetry is what makes this a substrate to reason on, not documentation to browse.
- 02
Append-only; supersede, never overwrite.
An entry is never edited in place. A later entry supersedes it, and the earlier one stays in the record, struck rather than deleted. The changed mind is itself information; the audit trail is not a feature bolted on, it is the default.
- 03
Typed, not prose.
Every entry carries a type and structured metadata, so a reader acts on its shape without re-parsing the text. A decision announces that it is a decision; a later reader does not have to infer it from the wording.
What a conforming entry carries
An entry is the atomic unit of the record. A conforming entry carries a required core, a recommended set of typed links, and an open space for metadata. The table follows the machine-readable schema; the required fields are what every implementation MUST produce.
| Field | Requirement | Description |
|---|---|---|
id | MUST | A stable, universally unique identifier, never reused even after the entry is superseded. It is the canonical cross-system reference; implementation-specific numeric ids are never the portable identifier. |
type | MUST | The entry's classification, drawn from a closed vocabulary — decision, spec, note, question, implementation, and the rest. A reader acts on the type without re-reading the body. |
content | MUST | The entry body — the decision, finding, spec, or question itself, written once by the author who reached it. |
author | MUST | Who wrote the entry: a person, role, or system. The field carries provenance, which is what a later reader weighs the claim by. |
created_at | MUST | An ISO-8601 timestamp, fixing the entry's place in the order of what was known when. |
links | SHOULD | Typed relationships to other entries — supersedes, references, blocks, implements, contradicts. An entry with no links is a leaf; the value compounds with the edges. |
metadata | MAY | An open key-value space for the structured fields a given type expects, so a review can carry its verdict and a directive its status without either being buried in prose. |
Machine-readable source of truth: /standard/entry.schema.json (JSON Schema).
Five operations
- §4.1WRITEMUST
write(content, type, links?, metadata?) → entryRecord a new entry. Content, type, and author are required; links and metadata are attached at write time — resolved once, not re-derived on every read.
- §4.2READMUST
read(id) → entryResolve a single entry by its stable identifier, with its typed links intact.
- §4.3LINKMUST
link(from, to, relation) → edgeAssert a typed relationship between two entries — supersedes, references, implements, contradicts. The edge is a first-class claim, queryable on its own.
- §4.4REASON-ONSHOULD
reason_on(scope) → briefingReturn a coherent, model-shaped slice of the graph for a scope: a briefing, not a search result. This is the read path a fresh session boots from.
- §4.5SUPERSEDEMUST
write(…, links: [{ supersedes }]) → entryThe operation the whole standard turns on. A later entry replaces an earlier one by pointing at it; the earlier entry stays, struck. An implementation that overwrites instead of superseding satisfies none of the axioms and conforms to nothing here.
Supersede, don't mutate
Supersession is the second axiom made mechanical. The figure below is a worked example: an entry recording “use SQLite” is superseded by a later one — “Postgres: six sessions write at once, SQLite locks.” The earlier entry is struck, not deleted; the reason the decision changed becomes part of the record rather than being overwritten out of it.
What an entry knows about itself
A superseded decision is not an error to erase. Contradictions between entries are kept as siblings, because real reasoning is born from them; a record that shows a mind changing is worth more than one that hides it.
An entry is weighed by who authored it, not only by what it claims. A poisoned entry can forge a citation; it cannot forge the identity that authored it. Provenance is the trust primitive.
The trace that produced a decision may be captured as its own linked entry, so the how survives alongside the what rather than being discarded once the decision ships.
In scope / out of scope
The Standard specifies the primitive and nothing above it. What is in scope is the record itself; what is out of scope is everything a product is built to sell on top of it.
In scope
- The shape of an entry and its required fields.
- The five operations and their contracts.
- Append-only supersession and its audit trail.
- The epistemic guarantees — provenance, kept contradictions, optional reasoning traces.
Out of scope
- Multi-agent coordination, spawning, and orchestration.
- Roles, hierarchy, and workflow policy.
- Dashboards and how the graph is presented.
- Hosting, tenancy, and billing — everything a vendor competes and charges on.
Conformance checklist
Conformance is close to all-or-nothing. A system that overwrites, or strips lineage, is not a lighter version of substrate memory — it is an older kind of record wearing the name.
- MUSTImplements write, read, link, and supersede with the specified contracts.
- MUSTNever mutates a superseded entry in place; the prior entry stays in the record.
- MUSTCarries provenance — author and timestamp — on every entry.
- SHOULDReturns a coherent briefing for a scope via reason-on, not only a flat search result.
- MAYCaptures a reasoning trace alongside a decision as its own linked entry.
Open at the foundation.
The primitive is meant to be given away. A memory format that only one vendor can write to is not a standard; it is a product with a spec sheet. The Vinculum Standard is open the way Postgres is open — free and universal at the foundation, so the work, and the value, move to what gets built on top.
The standard is the ground. What you build to stand on it is yours to sell.
Run it yourself
Vinculum runs on Postgres, and the reference implementation is the same code this page is served from. The Standard is not a document held apart from a product; it is extracted from one that runs.
Build on it yourself
The schema is open and the operations are few. A second implementation, backed by any store that can keep an append-only typed graph, is a conformance test away — not a reverse-engineering project.