Five-Slot Model

Every decision in Context Chain is indexed through five "slots", each corresponding to a different retrieval mechanism. The slots themselves are hardcoded infrastructure; the values within them are dynamically extracted by AI.

Overview

Slot 1: Code Anchor      → Graph traversal
Slot 2: Keywords          → Inverted index
Slot 3: Decision Links    → Graph edges
Slot 4: Metadata          → Structured filtering
Slot 5: Semantic Embedding → Vector search

Slot 1: Code Anchor

What it stores: Where this decision lives in the code.

Precision range:

• Exact: Function name, file + line range, API endpoint (POST /api/v1/orders)
• Approximate: Directory-level (order-service/src/auth/*), repo-level, or natural language ("related to the auth flow")

How it's retrieved: When a coding AI is editing a function, the system starts from that function's node and walks outward: Does this node have decisions? Do its callers/callees? What about the file level? Directory level? Service level? Near to far, with count limits at each layer.

Multi-anchor support: One decision can anchor to multiple code locations — a decision that spans two functions or two services gets an edge to each.

Slot 2: Keywords

What it stores: Explicit concept terms extracted from the decision conversation. No distinction between business and technical terms — "refund timeout" is both a business concept and a technical concern.

Examples: ["refund", "partial refund", "rate limiting", "Redis", "cache penetration", "TTL strategy"]

How it's retrieved:

• Passive: When a coding AI writes code, the system extracts keywords from the current code and comments to find matching decisions
• Active: A human searches "refund-related decisions" and hits the keyword index directly

Why this matters: Business keywords like "refund", "membership tier", "risk control" don't exist in code. They're the most natural entry point when humans think about problems — and the one dimension that grep and AST can never capture.

Slot 3: Decision Links

What it stores: Relationships between this decision and other decisions in the graph.

Relationship types:

Type	Meaning
CAUSED_BY / LEADS_TO	Causal chain
CONFLICTS_WITH	Tension — both reasonable but trade-offs when combined
SUPERSEDES	New decision replaces old
DEPENDS_ON	A's validity assumes B holds
CO_DECIDED	Made together in the same session

How it's retrieved: After finding a decision via Slot 1 or 2, the system follows these edges to pull in related decisions along the causal chain. Expansion depth is controllable.

Key distinction from Slot 1: Slot 1 edges are code structure relationships (function calls function). Slot 3 edges are decision structure relationships (decision caused decision). Both coexist in the same graph with different semantics.

Slot 4: Metadata

What it stores: Production information about the decision.

Fields:

Field	Description
created_at	Timestamp
owner	Who produced this decision
session_id	AI chat session identifier
commit_hash	Code version at time of decision
source	Origin type: ai_chat, meeting, manual
confidence	Internal only: owner_confirmed, ai_inferred, auto_generated
staleness	active, stale, archived

How it's retrieved: Never used alone to discover decisions. Always applied as a filter on top of other slots' results — e.g., filter out stale decisions, sort by recency, prioritize recent over old.

INFO

The confidence field is internal only — used by the refinement pipeline to decide what needs another pass. The consumer (your coding AI) never sees it and treats all decisions equally.

Slot 5: Semantic Embedding

What it stores: Vector representation of the full natural language description of the decision.

How it's retrieved: When the first four slots don't find enough relevant decisions, the system falls back to semantic similarity search using the current code snippet or user query as input.

Why it's the fallback: Semantic matching is too fuzzy on its own ("user authentication" and "user registration" are close in vector space but often unrelated in context). The first four slots provide precise signals — use them first.

Where it shines: When the way a decision was described differs completely from how it's being searched. Discussing "how to prevent duplicate charges" → searching "idempotency design" — keywords don't match but semantics do.

Retrieval Priority

The five slots are not queried in parallel. They have a strict priority order:

Priority 1: Slot 1 (exact code anchor match) + graph neighbor expansion
Priority 2: Slot 2 (keyword hits)
Priority 3: Slot 3 (decision link expansion) — triggered on top of P1/P2 hits
Priority 4: Slot 5 (semantic fallback)
Always:     Slot 4 (metadata filtering and sorting)

Higher priority = more precise = gets first claim on context window space. Each level has a count cap to avoid overwhelming the coding AI.

Progressive Disclosure

By default, only summary-level decisions are returned. If the coding AI determines a decision is relevant, it can request the full content in a follow-up call. This two-step pattern is naturally supported by MCP: first call returns summaries, second call returns details.