Docs · Browse sections

Structured Entities

Tickets, OKRs, sprints, releases — first-class.

Eleven structured entity kinds for the work that doesn't fit a markdown doc — bugs, incidents, OKRs, sprints, releases, experiments, reviews, risks, backlogs, and the handoff workflow. All managed via one unified MCP tool.

Quick reference

One tool, eleven kinds.

All structured entities use the unified entity(...) tool. Pass kind to pick the entity and action to pick the operation.

mcp · entity(action, kind, ...)
entity(
  action: "list" | "get" | "create" | "update" | "delete",
  kind:   "ticket" | "handoff" | "backlog_view" | "incident" |
          "release" | "experiment" | "goal" | "key_result" |
          "sprint" | "review" | "risk",
  id?:    "<uuid>",          // for get / update / delete
  body?:  { ... },           // for create / update — free-form JSON
  query?: { ... },           // for list — flattened to URL params
  workspace_id?: "<uuid>",   // defaults to active workspace
  project_id?:   "<uuid>",   // defaults to active project
)

The eleven kinds

Pick the right shape for the work.

Ticket

kind="ticket"

Structured work item — bug, feature, task, chore, incident, or epic. Heavier than a todo (status enum, kind, assignee, parent/sprint, labels, story points, external_ref for jira/linear sync) but lighter than a full plan.

When to use

When work needs more structure than a checkbox: assignment, status timeline, parent/child links to epics, sprint placement, or external-tracker sync.

kind

bugfeaturetaskchoreincidentepic

status

openin_progressblockedin_reviewresolvedclosedcancelled

priority

lowmediumhighurgent
mcp · entity(kind="ticket")
entity(action="create", kind="ticket", body={
  "title": "Fix replication lag on Oregon read replica",
  "kind": "bug",
  "priority": "high",
  "labels": ["postgres", "infra"],
  "external_ref": "JIRA-1234"
})

Handoff

kind="handoff"

Session/agent/team handoff workflow record. Wraps a ContextCapsule (purpose=handoff) which holds the artifact bundle; this row holds the workflow shell — sender, recipient, scope, status, open questions, next steps, linked artifacts.

When to use

When packaging context for another session, agent, or teammate. Pair with capsule(...) to materialize the bundle.

status

draftpendingacceptedcompletedcancelled
mcp · entity(kind="handoff")
entity(action="create", kind="handoff", body={
  "title": "Auth middleware refactor — finish the rotation tests",
  "scope": "tests/auth/*, src/middleware/auth.rs",
  "to_agent": "claude",
  "summary": "Refactor done; 3 of 5 rotation tests pass; the failing 2 hit a clock-skew edge case.",
  "open_questions": ["Should we mock Utc::now() or use tokio::time::pause?"],
  "next_steps": ["Replace Utc::now() in rotate_token with the SystemClock trait"],
  "capsule_id": "<paired ContextCapsule uuid>"
})

Backlog View

kind="backlog_view"

Saved ordered slice over tickets. Not a separate entity — a named view + ordering on the tickets table (now/next/later/icebox or any custom bucket) with optional explicit ticket_id ordering.

When to use

When you want a reusable prioritized list view on top of tickets — team backlog, personal queue, sprint candidates, etc.

mcp · entity(kind="backlog_view")
entity(action="create", kind="backlog_view", body={
  "name": "Now / Next / Later",
  "bucket": "now",
  "filters": { "status": "open", "kind": "bug" },
  "ticket_order": ["<uuid-a>", "<uuid-b>", "<uuid-c>"]
})

Incident

kind="incident"

Operational incident with severity (sev1-4), status timeline, services-affected, incident commander, reporter, and explicit links to the associated ticket and postmortem doc.

When to use

When something is on fire — outage, degraded service, security event. Status transitions auto-set timestamps (detected_at, mitigated_at, resolved_at, closed_at).

severity

sev1sev2sev3sev4

status

detectedinvestigatingmitigatedresolvedpostmortem_pendingclosed
mcp · entity(kind="incident")
entity(action="create", kind="incident", body={
  "title": "API 500s on /v1/search across all regions",
  "severity": "sev1",
  "status": "investigating",
  "services_affected": ["api", "search"],
  "summary": "Search returning 500 since 14:02 UTC; smoke tests failing."
})

Release

kind="release"

Versioned release record. Tracks version, status (planned/released/rolled_back), git_ref, environments, and links to a release_notes doc via changelog_doc_id.

When to use

When tracking deployments — planned releases, in-progress rollouts, and rollbacks. Distinct from an ad-hoc release_notes doc, which captures the human-readable changelog.

status

plannedin_progressreleasedrolled_backcancelled
mcp · entity(kind="release")
entity(action="create", kind="release", body={
  "version": "1.4.0",
  "status": "released",
  "environments": ["prod", "eu-west"],
  "git_ref": "abc1234",
  "changelog_doc_id": "<release_notes doc uuid>"
})

Experiment

kind="experiment"

A/B test or product experiment with hypothesis, control, treatment, primary_metric, secondary_metrics, status timeline, and a link to a result writeup doc.

When to use

When running structured tests on product changes — feature flags, growth experiments, A/B tests. Pair the result_doc_id with a doc_type='postmortem'-style writeup when shipped or discarded.

status

draftrunningpausedcompletedshippeddiscarded
mcp · entity(kind="experiment")
entity(action="create", kind="experiment", body={
  "name": "Onboarding checklist redesign",
  "hypothesis": "Adding inline progress reduces drop-off in step 3",
  "control": "Current sequential checklist",
  "treatment": "Inline progress bar + collapsed steps",
  "primary_metric": "step_3_completion_rate",
  "secondary_metrics": ["d1_retention", "session_length"]
})

Goal (OKR Objective)

kind="goal"

OKR objective. Goals nest via parent_goal_id (company → team → personal). Each goal has N measurable key_results.

When to use

When tracking quarterly/annual objectives. Goals are the qualitative 'what we want to achieve'; key_results are the quantitative 'how we'll know'.

status

draftactiveon_trackat_riskoff_trackachievedmissedcancelled
mcp · entity(kind="goal")
entity(action="create", kind="goal", body={
  "objective": "Ship the platform to 100 paying customers",
  "period": "2026-Q2",
  "owner_user_id": "<uuid>",
  "starts_at": "2026-04-01T00:00:00Z",
  "ends_at": "2026-06-30T23:59:59Z"
})

Key Result

kind="key_result"

Measurable key result owned by a parent goal. Has unit (number/percent/currency/boolean), target_value, start_value, current_value, and status. Created nested under its goal.

When to use

Always paired with a goal. Express the measurable outcome that proves the objective was achieved.

unit

numberpercentcurrencyboolean
mcp · entity(kind="key_result")
entity(action="create", kind="key_result", body={
  "goal_id": "<parent goal uuid>",
  "title": "MAU > 10,000",
  "unit": "number",
  "start_value": 6500,
  "current_value": 7200,
  "target_value": 10000
})

Sprint

kind="sprint"

Time-boxed iteration with name, goal, status, and start/end window. Tickets join via tickets.sprint_id.

When to use

When organising work into iterations. Filter tickets by sprint to plan/run/review.

status

plannedactivecompletedcancelled
mcp · entity(kind="sprint")
entity(action="create", kind="sprint", body={
  "name": "Sprint 42",
  "goal": "Ship taxonomy v1 to GA",
  "starts_at": "2026-04-28T00:00:00Z",
  "ends_at": "2026-05-12T23:59:59Z"
})

Review

kind="review"

Structured review record — PR / code / design / security / architecture / product. Tracks requester, reviewers, decisions array, and a free-form subject_ref pointing at the artifact.

When to use

When formal review records matter: security audits, architecture reviews, design critiques, or PR reviews you want to surface in context later.

kind

prcodedesignsecurityarchitectureproductother

status

requestedin_progresschanges_requestedapprovedrejectedcancelled
mcp · entity(kind="review")
entity(action="create", kind="review", body={
  "title": "Security review — new entity tool surface",
  "kind": "security",
  "subject_ref": "github:contextstream/contextstream#1234",
  "reviewer_ids": ["<security-eng uuid>"]
})

Risk

kind="risk"

Active risk register entry with likelihood × impact, mitigation, contingency, owner, and links to a related ticket / incident. Distinct from the distilled node_type='risk' summary node — that's a short-form pointer, this is the system-of-record.

When to use

When tracking project / launch / compliance / security risks that need active management.

likelihood

rareunlikelypossiblelikelyalmost_certain

impact

negligibleminormoderatemajorsevere

status

openmitigatingacceptedtransferredavoidedclosed
mcp · entity(kind="risk")
entity(action="create", kind="risk", body={
  "title": "Third-party billing API may rate-limit during launch peak",
  "likelihood": "likely",
  "impact": "major",
  "category": "external-dependency",
  "mitigation": "Pre-warm 2x normal capacity; backoff queue with 60s retry"
})

Related taxonomy

Structured entities vs. docs vs. events vs. nodes.

  • Structured entities (this page) — when work has fixed shape: status enum, assignee, parent/child links, time-boxes.
  • Docs — when content is markdown-shaped: runbooks, ADRs, RFCs, postmortems, retros, release notes, playbooks, PRDs, personas, glossaries, etc.
  • Events — when capturing a moment in time: decisions, lessons, preferences, standups, achievements, customer feedback, approvals.
  • Knowledge nodes — short-form distilled summaries: facts, decisions, preferences, constraints, habits, lessons, plus the new goal / risk / term variants. Promoted from raw events by the distillation pipeline (LLM + heuristic rules).

Best practices

A few things that pay off later.

  • Use external_ref for jira/linear sync

    Tickets accept external_ref so you can correlate to your system of record. Format is free-form (e.g. 'JIRA-1234' or 'linear:TKT-99').

  • Pair handoffs with a ContextCapsule

    Handoffs hold the workflow shell; capsules hold the artifact bundle (export, search results, notes). Set capsule_id when creating a handoff so the recipient gets the bundle.

  • Link incidents to tickets and postmortems

    ticket_id and postmortem_doc_id let you walk the chain — from the page event to the bug, to the postmortem doc. Future context() calls surface the chain together.

  • Status transitions auto-set timestamps

    Marking a release 'released' fills in deployed_at, marking it 'rolled_back' fills in rolled_back_at. Same for incidents (mitigated_at / resolved_at) and tickets (resolved_at / closed_at).

  • Backlogs are saved views, not entities

    A backlog_view is a named ordering + filter spec on tickets. Multiple backlogs (team / personal / now-next-later) coexist freely — tickets are the source of truth.

Memory events

Capture significant moments

decisions, lessons, achievements, feedback

MCP tools

Full tool reference

entity, memory, search, graph, reminder, …