Shared language

Copy page

The memory pages — and the wider systems and reference pages — all lean on the same handful of words. This page defines them once, in plain terms, so you can read the rest without guessing what a word means. Every other page links here rather than redefining them.

Throughout these docs, you are the operator: the person running the platform or wiring a project into it. When a page addresses “the operator,” it means you.

Start with the core eight below. If you are setting up your first memory store, read that group top to bottom once — it is the whole vocabulary the memory idea assumes. The two groups after it — the platform’s parts and setup and operation — are a reference. Dip into them when a word on the systems or reference pages is unfamiliar; you do not need them all up front.

The core eight

Friction

The repeated cost of working with an agent that forgets: re-explaining the same context, watching it repeat a mistake, losing a correction by the next session. Memory exists to end friction.

It is the thing you are trying to get rid of. If you have never worked with an agent that remembers, friction is the background hum you may not have noticed yet — every session starting from zero. The rest of these words describe how a memory store removes it.

Record

One memory. A few words worth keeping, a fingerprint of their meaning, and a few labels.

A record is the unit the store holds. Not a whole conversation, not a file — one small, durable thing: a correction you gave, a decision you made, a fact about a project. The store is a collection of these.

Correction

When you tell the agent it got something wrong. Saved as a record, it becomes standing guidance it follows from then on.

A correction is the highest-value kind of record. You give it once — “no, we use pnpm here, not npm” — and because it is saved, the agent follows it in every session afterward instead of making you say it again.

One-time learning

A cost you’d otherwise pay every session, paid once instead: a correction saved once is guidance forever.

This is the shape of the whole payoff. Without memory, the same explanation is a cost you pay every time you sit down. With memory, you pay it once. That conversion — a repeating cost turned into a single one — is what the store is for.

Recall

The system surfacing the right records by meaning, not keyword, the moment they’re relevant — automatically.

You do not search for a record by remembering its exact words. When something you once saved becomes relevant again, recall brings it back on its own, matching by what it means. This is why the store is useful even when you have forgotten what is in it.

Scope

Who or what a record belongs to: you (a hard wall — never another person’s memory), a project (a soft sort — a filter, not a barrier), and machine (deliberately none — same key, same memory everywhere).

Scope is the answer to “who sees this record?” There are three parts, and they behave differently on purpose:

You is a hard wall. Your records are yours; the store will not hand another person’s memory to you or yours to them.
Project is a soft sort. Within your own records, project labels sort things by project — a filter you can lift, not a wall. A record can even belong to two projects at once.
Machine is deliberately absent. There is no “which machine” boundary. Your laptop, your desktop, and a scheduled job all reach the same memory, because reaching it from everywhere is the point.

Fingerprint

The 384-number stand-in for what a record’s words mean, so recall can match by meaning instead of exact words.

When a record is saved, a small model on your own machine reads its words and produces 384 numbers that stand for their meaning. That is the fingerprint. Recall compares fingerprints to find records close in meaning, which is how it can surface the right one even when your words this time differ from the words you saved.

Label

The marks on a record — whose it is, which projects, who wrote it, when — that keep one shared store sorted.

Labels are the bookkeeping on each record. They are what make one shared store usable: because every record carries who it belongs to and which projects it touches, the store can stay sorted by owner and project even though everything lives in one place.

The platform’s parts

These name the moving pieces of the platform. You meet them on the systems and explanation pages once you look past the memory store itself.

The observer

The part of Tapestry that watches your work for patterns that keep recurring and flags them for a closer look — trends, not single events.

It runs as plain scripts, not an AI reading your code. The one that runs in your own setup is the session observer, at the end of each session (which skills you used, what the session’s upskilling report flagged). A second, repo-wide observer — a scheduled job that scans your repos for structure that has drifted — is part of the design, but it runs as a platform service, not something a fresh project setup starts on its own. What either flags is called a candidate. The observer surfaces; it never decides — promoting a candidate is your call.

Discipline (the discipline stack)

Tapestry’s name for the always-on rules and automation that keep the agent honest — recall memory, check the real files before claiming anything, save a correction the moment you make it.

It ships as a Claude Code plugin (tapestry-discipline) that installs four hooks. “Stack” just means the whole bundle of rules and hooks taken together, not a piece of infrastructure. Without it the agent reverts to plain Claude Code — no memory, no PROBE reminder, no guardrails.

Hook

A script Claude Code runs automatically at a fixed moment — not something you call yourself.

The discipline plugin uses four: SessionStart (pull your memories into a new chat), UserPromptSubmit (add the PROBE reminder to each message you send), PreToolUse (a check before an edit), and Stop (the end-of-session upskilling check). Hooks bind when a session opens, which is why enabling a plugin only takes effect after you restart Claude Code in that project.

MCP (Model Context Protocol)

The standard way an outside tool or server plugs into Claude Code so the agent can call it.

The memory store you are setting up is an MCP server — loom-memory, reached over HTTP — and it provides the agent’s memory_recall / memory_write tools; the discipline plugin is what wires it in (and adds the automatic recall). Because every project shares the one store, it also acts as a cross-agent channel: here “channel” means shared memory that agents in other projects can read, not a chat channel.

Signal, interpretation, pattern

The three stages by which raw events become something worth acting on: a signal is one raw event a hook emits; interpretation is the observer reading many signals together; a pattern is the recurring shape it finds.

The docs write it as “signal → interpretation → pattern.” The principle behind it: one event proves nothing — only the trend across many does. Telemetry produces the signals; everything downstream is interpretation.

Candidate and promotion

A candidate is a recurring pattern the observer noticed but has not acted on — it waits in a list for a second look. Promotion is the deliberate step of turning one into durable structure: a rule, a skill, or an agent.

A candidate carries a status that hardens as evidence repeats (draft → observed → recurring). The observer only ever raises candidates; whether one gets promoted is a decision you make, not the observer.

Architecture snapshot, diff, drift

A snapshot is an automatic structural map of your repo — services, dependencies, MCP servers, env-var keys — taken at each session start. The diff lists what changed since the prior snapshot. Drift is structure that has moved away from where it belongs (a duplicate showing up in two places, one package that split into two).

The point is that the agent begins each session already knowing what changed, instead of you re-explaining it. If you delete the snapshot output directory to tidy up, you lose only the historical record — the map rebuilds from the next session forward.

The Observatory

The web dashboard where you watch how you and your agents are working together over time — trends, not live status.

It answers trajectory questions (“is coordination getting smoother or rougher?”) rather than point-in-time status like “is the API up right now.” The docs sometimes call it the console; it is the same surface. It is your own deployment, with a read-only public demo running on sample data.

Coordination

How well you and the agent are working together over the life of a project — the thing Tapestry watches and tries to improve.

It is the platform’s core measure, so the word turns up everywhere the platform describes what it is for. One stretch of you-and-agent working on a single thing is a working episode; “coordination quality” rising or falling over time is what the Observatory plots.

Upskilling

Turning a repeated pattern into a reusable skill or rule, so the same thing is not solved from scratch again.

The upskilling audit is the end-of-session check (the Stop hook) that fires loudly when a substantial session — a commit, or many tool calls and turns — ends without producing such a report. It is the same job the observer does, caught at the moment a session ends rather than across many.

Setup and operation

These are the words you meet while standing the platform up and wiring a project into it — the setup and reference pages assume them.

Operator

You — the person running the platform or wiring a project into it.

Nearly every page uses “the operator” to mean the reader. When instructions say “the operator sets LOOM_PROJECT_ID,” they are telling you to do it; the word is not pointing at some other role.

PROBE

The rule that the agent must actually read or grep the real files — and cite file:line — before claiming anything about your code, instead of guessing from memory or training.

It is not an acronym, despite the capitals. You will see it as “PROBE before asserting” or “the agent should be PROBE-ing the code”; if the agent cites a memory as current fact without checking the files, that is this rule being broken.

Self-host vs hosted

The two ways the platform can run. Self-host (the default) is run-it-yourself and single-tenant: everyone lands in one deterministic memory envelope, with no login token needed. Hosted (hosted-multitenant) is a shared deployment where each user’s data is walled off as its own tenant, keyed by a login token.

The mode is set by PLATFORM_MODE (self_host by default). For a first memory store you are almost certainly self-hosting — which is why the setup steps need no authorization header.

OTel / OTLP (OpenTelemetry)

OpenTelemetry is an industry-standard format for emitting logs and traces; OTLP is the wire protocol that ships them.

Tapestry sends its hook events over OTLP to Grafana Cloud (Loki stores the logs, Tempo the traces) so patterns can be seen across machines. This part is optional: the discipline plugin always writes a local log at ~/.claude/logs/hooks.jsonl, and OTel only adds the cross-machine view. Skip the OTel credentials and nothing else breaks.

Auto-recall block (additionalContext)

The block of remembered notes the SessionStart hook drops at the top of a new chat, before your first message — past decisions, prior corrections, current project state.

additionalContext is Claude Code’s name for that injected block; the docs call the memory part of it the auto-recall block. Watching it appear is how you confirm recall is wired. On a brand-new project it is empty, which is normal — nothing has been saved yet.

pgvector and embeddings

The database machinery behind meaning-based recall. An embedding is the fingerprint — the list of numbers standing for what a memory means. pgvector is the Postgres add-on that stores those fingerprints so recall can search by meaning (“semantic search”) instead of by exact words.

You install neither; the hosted memory store already runs Postgres with pgvector built in. If you have read fingerprint and recall above, you already understand what these do — these are just the underlying names for the same idea.

Why you’ll see both “loom” and “tapestry”

“Loom” is the platform’s legacy name; “Tapestry” is the current one, and the two overlap on purpose while the rename settles.

So during setup you will meet both. The memory server is loom-memory, your project’s identity tag is LOOM_PROJECT_ID, and the discipline plugin’s runtime messages are still tagged [loom-discipline] even though you install it as tapestry-discipline. The old loom- names are kept deliberately — a stable-identity contract, so existing wiring keeps working — and are not mistakes. You do not need to change them.

The memory — the concept, in brief, using these words.
Why the memory is built this way — the reasons behind the shape, using these words.
The memory MCP — what accumulates in a running store and how to keep it healthy.
The discipline stack — how the plugins, hooks, MCP, and observer fit together.
The observer — how recurring patterns become candidates and then durable structure.
The Observatory — the console where coordination trends are watched over time.