Retrieval model

Tracebook vs vector database memory

Vector search answers “what looks similar?” Tracebook answers “which governed project facts are current, and what evidence supports them?”

Short answer: choose vector memory for large, fuzzy corpora where semantic recall matters. Choose Tracebook for a smaller set of durable engineering conclusions that require inspectable evidence, lifecycle state, bounded scope, and no supporting service.

Retrieval and authority are different problems

Embeddings can find passages that share meaning even when they use different words. That is valuable for broad documentation, transcripts, tickets, and code search. But similarity does not establish that a statement is current, verified, or authoritative.

Tracebook starts from the opposite direction. It stores fewer items. Each current item has a stable identity, governed scope, lifecycle, history, and evidence. Retrieval is lexical and deterministic by design; the agent can explain why an item matched and which source should be checked.

DimensionVector / embedding memoryTracebook
Best atFuzzy semantic recall over large corporaFocused recall of governed project facts
InfrastructureOften embeddings, index, service, or local databasePython runner and Markdown files
RankingSimilarity plus metadata and rerankingLiteral tokens, evidence-path priority, deterministic bounds
AuthorityDepends on application designExplicit evidence and lifecycle contract
StalenessReindexing and application-specific policyStatus transitions and health review candidates
Operational costRanges from embedded local DB to hosted serviceNo server, daemon, API key, or vector store

Choose vector memory when

  • You need semantic search across thousands of documents or conversations.
  • Users will ask with vocabulary that rarely matches the stored text.
  • Approximate ranking is acceptable and you can operate the indexing pipeline.
  • The memory product needs automatic capture at high volume.

Choose Tracebook when

  • A wrong or stale engineering fact is more costly than a missed fuzzy match.
  • People need to inspect the fact, its source, its status, and its history as Markdown.
  • Project isolation and explicit cross-project scope matter.
  • You want the memory layer to work without a database, service, API key, or background process.

What about MCP?

MCP is an integration protocol, not a storage or authority model. A vector memory service may expose MCP tools; so may a deterministic store. Tracebook is currently distributed as an Agent Skill and intentionally does not run an MCP server. That removes a service boundary, while making invocation dependent on the host's Skill support.

Can they work together?

Yes, if authority remains clear. Use semantic search to discover candidate source material, then verify a durable conclusion and capture it in Tracebook with evidence. Do not treat an embedding match itself as proof.

Semantic retrieval can find the evidence. Governance decides whether the conclusion deserves to survive.

Known boundary

Tracebook retrieval uses literal English tokens and CJK bigrams. It does not stem terms, infer synonyms, or promise semantic recall. Queries work best when they use vocabulary present in the knowledge pages or an exact evidence path. This limitation is part of the published contract.

No black box required

Inspect the exact memory artifact.

Run the real workflow locally, then open the generated authority page and its evidence with any text editor.