The core CONTINUITY system — hierarchy, mesh, Git provenance, hooks — works without any specialized infrastructure. For teams operating at scale, two optional extensions unlock capabilities that plain file reads cannot provide: vector retrieval for semantic search across large state histories, and schema validation for machine-readable mesh edges. Neither is required. Both become valuable at specific thresholds. This page describes how each extension works, when to add it, and how theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/bitwikiorg/continuity/llms.txt
Use this file to discover all available pages before exploring further.
memory/ directory underpins both.
Vector stores
When state history grows beyond what an agent can load in a single context window, semantic search becomes the practical alternative to exhaustive file reads. Vector stores let agents query meaning rather than filenames. State files are embedded with an embedding model and stored in a vector database. The agent queries by intent — “what did we learn about rate limiting?” — rather than by path. The vector store returns the most relevant entries from across all sessions, projects, and snapshots.| Capability | How it works |
|---|---|
| Semantic search | State files are embedded and stored in a vector DB; queries return matches by meaning, not filename |
| History recall | Search across snapshots/, audits/, and completed/ entries by content — find what the agent knew on a specific date without scanning every file |
| Auto re-embed | Hooks fire on STATE.md, TODO.md, or SNAPSHOT.md changes and trigger re-embedding of updated files, keeping the vector index current |
| Cross-project retrieval | Multiple agents sharing a state directory can find relevant context without reading every file in the directory |
When to add vector retrieval
State history exceeds context
When the combined size of your
snapshots/, audits/, and completed/ directories exceeds what an agent can load in a single context window, semantic search becomes necessary. Without it, the agent either loads too much (context overflow) or loads too little (stale planning).Semantic recall is needed
When an agent needs to answer questions like “what have we learned about this subsystem?” across many sessions, keyword search over filenames is not sufficient. Embedding-based retrieval surfaces relevant context by meaning.
Schema-validated mesh
The mesh is explicit by design: every edge is declared in a## Mesh index section. For small meshes, human review is sufficient. For meshes with many edges — multiple agents writing shared directories, CI pipelines that must catch regressions — a three-layer validation pattern makes the mesh machine-readable.
| Layer | File | Role |
|---|---|---|
| Canonical graph | SCHEMA.lua | Machine-readable mesh graph — all edges, dependencies, and ownership declarations in one queryable file |
| Per-file metadata | YAML frontmatter | Owner, scope, parent, index declarations, and write rules embedded directly in each .md file |
| Validator | schema_validate.py | Bridge that checks both layers agree — detects drift between declared edges and actual directory structure, flags dangling edges and ownerless files |
## Mesh index sections) and machine-readable (schema graph + YAML frontmatter + validator). Relationships, dependencies, and reconciliation triggers become queryable in CI.
When to add schema validation
Mesh has many edges
When your mesh has enough declared edges that manual tracking is error-prone — a rough threshold is more than a dozen distinct indexer-to-directory relationships — the validator catches drift that humans miss.
Multiple agents write shared directories
When more than one agent can write to
memory/, artifacts/, or audits/, ownership boundaries need enforcement. YAML frontmatter in each entry declares its owner; the validator confirms every entry has a declared owner that matches the schema graph.Memory store structure
Thememory/ directory is the Library-class store that underpins both vector retrieval and schema validation. It is structured for both human navigation and machine querying:
entries/ carries YAML frontmatter that makes it queryable by namespace, topic, confidence, retention policy, and update date:
INDEX.md organizes all entries into four namespace tables — semantic, procedural, episodic, and working — each row carrying the UID, topic, path, confidence score, and last update date. SCHEMA.md defines the full frontmatter specification and the four namespaces, and documents the trust tiers used to qualify confidence scores.
Memory namespaces
| Namespace | Purpose | Example |
|---|---|---|
semantic | Durable facts that do not change frequently | ”Production server IP is 192.0.2.1” |
procedural | Reusable methods and runbooks | ”How to deploy a service via Caddy” |
episodic | Important events and milestones | ”Auth transfer completed 2026-06-16” |
working | Temporary context for the current task | ”Current task: fix webhook rate limiting” |
Two memory delivery types
Memory entries are delivered to the agent in one of two modes. The mode is declared per-entry and determines when the content reaches the agent’s context window:Latent (auto-inject on boot)
Entries marked
latent are injected automatically when the agent boots. They load without an explicit query — the agent wakes up already knowing them. Use for high-confidence, high-frequency facts: identity, hard limits, durable infrastructure state. Keep the latent set small enough to fit inside the auto-load budget defined in CONTEXT_BUDGET.md.Working (search on demand)
Entries marked
working are retrieved only when the agent issues a search query against the vector store or the INDEX.md manifest. They never auto-load. Use for the long tail of episodic events, procedural runbooks, and project-specific facts that are needed occasionally but not every session.These are optional extensions
Vector retrieval and schema-validated mesh are optional. The core system — nesting, mesh declarations, Git provenance, and hooks — operates entirely on plain markdown files without any database or validator. Add these extensions when your state history exceeds context capacity, when semantic recall becomes necessary, or when CI enforcement of mesh edges is worth the setup cost. Most agents running at Standard or Full tier will never need them.
Mesh
The mesh model that schema validation formalizes — how edges are declared and why they matter.
Runtime Contracts
BINDING.schema.json and how it machine-validates the mesh for recursive agents.
Hooks
How to wire auto-re-embed triggers to fire when state files change.
Ontology
State, History, and Library classes — the taxonomy that governs what can be embedded and how.