Doc Types
Twenty-two flavours of markdown.
Most knowledge in a project is markdown — runbooks, ADRs, RFCs, postmortems, retros, release notes, PRDs, personas, glossaries. ContextStream stores them all under memory(action="create_doc") with the right doc_type so search, filtering, and per-type styling all light up correctly.
Quick reference
One action, twenty-two types.
Same memory(action="create_doc", ...) you already know — just pass the right doc_type. Structured per-type fields go in metadata (e.g. ADR status, postmortem incident_id, release_notes version).
memory(
action: "create_doc",
title: "Restore the Oregon read replica",
content: "# Steps\n1. ...",
doc_type: "runbook", // pick from the 22 below
metadata: { rotation: ["alex", "blake"] },
workspace_id: "<uuid>", // defaults to active workspace
project_id: "<uuid>", // defaults to active project
)General-purpose
General
doc_type="general"Default catch-all for any markdown content that doesn't fit a more specific type.
when: When the doc doesn't have an obvious shape — quick notes, mixed content, drafts.
Spec
doc_type="spec"Technical specification — typically for an API, schema, or component contract.
when: When defining a contract or interface that other code/teams depend on.
Roadmap
doc_type="roadmap"Plan of work over time — milestones, themes, sequencing.
when: When laying out 'what we're building when' across weeks/quarters.
Glossary
doc_type="glossary"Shared terminology / definition entry.
when: When a term has team-specific meaning (or is heavily overloaded) and needs a canonical definition.
Q&A
doc_type="q_and_a"Durable Q&A entry — promoted from chat / standup when the answer matters longer than the conversation.
when: When a question got asked and answered, and the next person to ask should find it.
Style Guide
doc_type="style_guide"Code / design / writing style rules.
when: When codifying conventions: naming, formatting, voice, color palette, etc.
Engineering
ADR
doc_type="adr"Architecture Decision Record — context, decision, consequences, status.
when: When recording a significant architectural choice you'll need to defend or revisit.
RFC
doc_type="rfc"Request for Comments — formal technical proposal with problem, proposal, alternatives.
when: When proposing a non-trivial design that needs review and asynchronous feedback.
Retrospective
doc_type="retro"Sprint or project retrospective — what went well, what didn't, action items.
when: End of sprint or end of project. Pair with the relevant sprint or experiment id.
Release Notes
doc_type="release_notes"Versioned release notes — user-facing changelog for one version.
when: When shipping a versioned release; link via release.changelog_doc_id.
Playbook
doc_type="playbook"Multi-step procedure for non-ops processes (onboarding, launch checklist, demo prep).
when: When the process is procedural but not ops-specific (use runbook for ops).
Changelog
doc_type="changelog"Multi-version changelog — distinct from release_notes (single version).
when: When tracking a rolling history across many versions for users / API consumers.
Ops / SRE
Runbook
doc_type="runbook"Operational procedure — deploy, rollback, restore, on-call response.
when: When the operator needs step-by-step instructions to fix or operate something.
Postmortem
doc_type="postmortem"Incident postmortem — timeline, contributing factors, action items, lessons.
when: After every sev1/sev2 incident, and after any sev3 worth learning from.
On-Call Schedule
doc_type="oncall_schedule"Rotation roster — who's on call, when.
when: When tracking on-call assignments. Pair structured rotation in metadata JSONB.
SLO
doc_type="slo"Service Level Objective — target metric, error budget, alert thresholds.
when: When formalising reliability targets that drive paging / capacity planning.
Product / design
PRD
doc_type="prd"Product Requirement Document — problem, solution, success metrics.
when: When defining what to build before engineering specs / design specs land.
User Story
doc_type="user_story"As-a / I-want / so-that with acceptance criteria.
when: When breaking PRDs into shippable atoms; tickets often link to a story.
Persona
doc_type="persona"User persona — goals, jobs-to-be-done, pains, gains.
when: When grounding feature work in a specific user archetype.
Interview
doc_type="interview"Customer / user research interview notes.
when: After every customer or user research session you want to surface in future context.
Design Spec
doc_type="design_spec"Design rationale, tokens, and interaction details for a feature.
when: When the design needs explanation beyond a Figma link — rationale, tradeoffs, edges.
Critique
doc_type="critique"Design or code review write-up.
when: When a critique session produces takeaways worth keeping (paired or instead of a review record).
In the dashboard
Filter by type without leaving the docs view.
The Docs umbrella stage in the dashboard has filter chips for Specs, Roadmaps, Runbooks, ADRs, RFCs, Postmortems, Retros, Releases, Playbooks, plus the legacy Decisions / Handoffs / Reviews / Archives tabs. Each chip filters by doc_type so finding a specific kind is one click away. Runbooks and handoffs also have their own dedicated nav stages.
Best practices
Pick the most specific type that fits.
Don't default to general
general is a fallback. If you can pick a more specific doc_type (runbook, adr, prd, persona, …), do — it makes search and filtering much sharper later.
Use metadata for structured fields
ADR status, postmortem incident_id, release_notes version, persona traits — all go in the metadata JSONB rather than free text in content. Future automation hooks (status checks, version diffs) read metadata directly.
Link, don't duplicate
An incident has a postmortem_doc_id; a release has a changelog_doc_id; an experiment has a result_doc_id. Use those FKs instead of pasting content twice.
Doc vs entity vs event
Markdown content goes in docs. Structured records with status enums go in entities (tickets/incidents/etc.). Moments-in-time go in events. When in doubt, ask: 'do I want to read this back as prose, query it by status, or surface it in a stream?'
Structured entities
Tickets, OKRs, sprints, incidents
for work that has structure beyond markdown
Memory events
Capture significant moments
decisions, lessons, achievements, feedback