Problem Statement
New developers repeatedly hit the same fork in the road and there is no single page that resolves it end to end:
- Is a piece of context a Memory or Knowledge?
- Should
infer be true or false?
- Which ingest field and which query
type belong together?
- How do shared org knowledge and per-user memories combine?
Today the answers are spread across memories.mdx, knowledge.mdx, query.mdx, and core-concepts.mdx. Each page covers its own half well, but a developer with a concrete piece of data (a Slack thread, a PDF, a raw chat log, a stated preference) has to stitch the full journey together themselves. infer: true vs false in particular is defined in one line and easy to get wrong (it defaults to false and silently stores raw text).
Proposed Solution
Add one decision-guide page, essentials/v2/choosing-memory-vs-knowledge, registered first in the v2 Usage nav, containing:
- The single deciding question (shared vs per-user) as a two-card split.
- A decision tree (Mermaid) from 'new piece of context' to an exact ingest shape + query
type.
- A routing table mapping each kind of data to store, ingest
type, ingest field, infer, and query type.
infer: true vs infer: false side by side, with the same raw signal producing two different stored memories, plus the default-false gotcha.
- Two full end-to-end paths (ingest then query) showing which endpoints pair up.
- The
type: "all" merge for personalized-yet-grounded answers.
- A v1-to-v2 endpoint name map (Upload Knowledge / Add Memory / Full Recall / tenant_id ...).
Alternatives Considered
- Expanding
core-concepts.mdx instead: it is a tour of five primitives and would lose focus; the decision workflow deserves its own destination page.
- A standalone
infer page only: narrower, and does not fix the endpoint-pairing or store-choice confusion.
Additional Context
Submitted as part of the Mintlify x HydraDB documentation hackathon (Jul 17-24). PR to follow, referencing this issue.
Problem Statement
New developers repeatedly hit the same fork in the road and there is no single page that resolves it end to end:
inferbetrueorfalse?typebelong together?Today the answers are spread across
memories.mdx,knowledge.mdx,query.mdx, andcore-concepts.mdx. Each page covers its own half well, but a developer with a concrete piece of data (a Slack thread, a PDF, a raw chat log, a stated preference) has to stitch the full journey together themselves.infer: truevsfalsein particular is defined in one line and easy to get wrong (it defaults tofalseand silently stores raw text).Proposed Solution
Add one decision-guide page,
essentials/v2/choosing-memory-vs-knowledge, registered first in the v2 Usage nav, containing:type.type, ingest field,infer, and querytype.infer: truevsinfer: falseside by side, with the same raw signal producing two different stored memories, plus the default-falsegotcha.type: "all"merge for personalized-yet-grounded answers.Alternatives Considered
core-concepts.mdxinstead: it is a tour of five primitives and would lose focus; the decision workflow deserves its own destination page.inferpage only: narrower, and does not fix the endpoint-pairing or store-choice confusion.Additional Context
Submitted as part of the Mintlify x HydraDB documentation hackathon (Jul 17-24). PR to follow, referencing this issue.