Understanding CortexDB episode types and when to use each one.

Memory Types

CortexDB organizes information as episodes -- discrete units of information that represent something that happened or was observed. Each episode has a type that determines how it is indexed, extracted, and retrieved.

Episode Types

message

When to use: Chat messages, conversation turns, user interactions, support tickets.

Messages are the most common episode type. They represent a single utterance or communication from a person or system. CortexDB extracts entities, sentiment, intent, and relationships from messages.

{
  "type": "message",
  "content": "Can we schedule the design review for the payments page on Thursday? I want to make sure the Stripe integration is covered.",
  "source": "slack",
  "channel": "#design",
  "author": "alice",
  "timestamp": "2026-03-15T10:30:00Z"
}

Extracted entities: alice (person), payments page (feature), Stripe (technology), design review (event), Thursday (temporal)

document

When to use: Wiki pages, documentation, reports, long-form content, PDFs, specifications.

Documents are longer-form content. CortexDB automatically chunks documents for vector indexing while preserving the full document in the event log.

{
  "type": "document",
  "content": "# API Rate Limiting Policy\n\nAll API endpoints are rate-limited per tenant...",
  "source": "confluence",
  "metadata": {
    "title": "API Rate Limiting Policy",
    "page_id": "12345",
    "space": "Engineering",
    "last_edited_by": "bob"
  }
}
code

When to use: Code changes, pull requests, commits, code reviews, deployment events.

Code episodes capture software development activity. CortexDB extracts file paths, function names, languages, and relates code changes to the entities they affect.

{
  "type": "code",
  "content": "Refactored the payment processing pipeline to support multi-currency. Added EUR, GBP, JPY support. Updated the Stripe webhook handler.",
  "source": "github",
  "metadata": {
    "repo": "acme/payments",
    "pr_number": 456,
    "files_changed": ["src/payments/processor.rs", "src/payments/currency.rs"],
    "diff_summary": "+234 -89 across 5 files"
  }
}
event

When to use: System events, alerts, incidents, deployments, infrastructure changes.

Events represent things that happened in your systems. They are timestamped occurrences that CortexDB can correlate with other memories.

{
  "type": "event",
  "content": "Production deployment v2.3.1 completed. 3 new features, 2 bug fixes. Rollback plan: revert to v2.3.0 tag.",
  "source": "ci-cd",
  "metadata": {
    "version": "2.3.1",
    "environment": "production",
    "duration_seconds": 180,
    "triggered_by": "charlie"
  }
}
decision

When to use: Architecture decisions, team agreements, policy changes, trade-off analyses.

Decisions are high-value episodes that capture why something was chosen. CortexDB gives decisions higher weight in retrieval and tracks their relationships to affected entities.

{
  "type": "decision",
  "content": "Chose RocksDB over SQLite for the embedded storage engine. Rationale: better write throughput for append-heavy workloads, built-in compression, column family support for logical separation.",
  "source": "adr",
  "metadata": {
    "decision_id": "ADR-042",
    "status": "accepted",
    "alternatives_considered": ["SQLite", "LMDB", "Sled"],
    "decided_by": ["prashant", "alice"]
  }
}
task

When to use: Tickets, to-dos, action items, work items, sprint tasks.

Tasks track work items and their lifecycle. CortexDB monitors task state changes and can answer questions like "what is the team working on" or "what blockers exist."

{
  "type": "task",
  "content": "Implement tenant-level rate limiting for the REST API. Must support configurable limits per endpoint.",
  "source": "jira",
  "metadata": {
    "ticket_id": "CORTEX-789",
    "status": "in_progress",
    "assignee": "bob",
    "priority": "high",
    "sprint": "Sprint 14"
  }
}
observation

When to use: Insights, patterns, learned facts, user preferences, system behaviors.

Observations are inferred or synthesized knowledge. Use them when the information does not come from a specific source event but is a conclusion drawn from multiple inputs.

{
  "type": "observation",
  "content": "User tends to ask about deployment status every Monday morning. Proactively surfacing weekend deployment summaries would improve their experience.",
  "source": "system",
  "metadata": {
    "confidence": 0.85,
    "based_on_episodes": ["ep_123", "ep_456", "ep_789"]
  }
}

Episode Structure

Every episode shares a common structure:

| Field | Type | Required | Description | |---|---|---|---| | type | string | Yes | One of: message, document, code, event, decision, task, observation | | content | string | Yes | The main text content of the episode | | source | string | No | Where the episode originated (e.g., slack, github, jira) | | author | string | No | Who created this episode | | channel | string | No | Channel or context within the source | | timestamp | ISO 8601 | No | When the episode occurred (defaults to ingestion time) | | metadata | object | No | Arbitrary key-value pairs for source-specific data |

Choosing the Right Type

Tip

When in doubt, use message. It is the most general type and works well for most conversational content. Use specialized types when you want CortexDB to apply type-specific extraction and ranking logic.

| Scenario | Recommended Type | |---|---| | Chat conversation turns | message | | Slack/Teams messages | message | | Wiki or doc page | document | | PR description or commit | code | | Deployment or alert | event | | Architecture decision record | decision | | Jira ticket | task | | Learned user preference | observation |

Type-Specific Behavior

CortexDB applies different processing based on episode type:

  • document episodes are automatically chunked for better vector search on long content.
  • decision episodes receive a retrieval boost -- they are prioritized when the query implies a "why" question.
  • code episodes have file paths and identifiers extracted as entities.
  • task episodes track state transitions and can be queried by status.
  • observation episodes are flagged as synthetic and include confidence scoring in results.

Next Steps