Namespace: memory-steward • Owner: architecture-team
← Prev: Document 01 (Architecture) | Next: Document 03 (Reference) →
- 0. Status, Scope, and Authority
- 1. What a “Mode” Is (and Is Not)
- 2. Minimal Mode Set (Deliberately Small)
- 3. Authority: Who Decides the Mode
- 4. Mode Decision Signals
- 5. Mode Transitions
- 6. Routing Effects of Mode
- 7. Prompt Assembly Contract (Mode-Aware)
- 7.1 Mode Effects on Builder Prompt
- 7.2 Mode Effects on Steward Prompt
- 7.3 Mode Isolation Invariant
- 8. Failure Modes and Safe Defaults
- 9. Implementation Guidance (Non-Code)
- 10. Hard Invariants (Mode System)
- 11. Relationship to Other Documents
- 12. Closing Statement
Status: FOUNDATIONAL / CANONICAL Audience: Control-plane architects, Router/Steward implementers Depends on: Document 1 (Canonical Memory Architecture) Change policy:
- Append-only
- No silent edits
- Mode additions require explicit justification
[cite_start]This document defines operational modes, who decides them, and how they affect routing, memory gating, and prompt assembly. [cite: 282, 283]
[cite_start]An operational mode is a classification of the user’s cognitive / problem-solving posture, not subject matter. [cite: 284] A mode answers:
“How should the system behave right now?”
It does not answer:
- What product is being discussed
- What technology is involved
- What data should be retrieved
Modes are not:
- Topics (e.g., Terraform, AWS, Chemistry)
- Tags for retrieval ranking
- User personas
[cite_start]Modes influence rules, not facts. [cite: 285]
[cite_start]The system must start with a minimal, stable set. [cite: 286]
The recommended initial set:
- engineering
- implementation
- brainstorming
- formal_spec
- casual
[cite_start]No additional modes may be introduced without evidence they cannot be expressed via these. [cite: 287]
| Mode | Primary Traits |
|---|---|
| engineering | rigor, correctness, constraints, tradeoffs |
| implementation | code, diffs, APIs, production-grade patterns |
| brainstorming | hypothesis allowed, alternatives, exploration |
| formal_spec | definitions, invariants, precise language |
| casual | lightweight, no heavy contracts |
| [cite_start][cite: 288, 289, 290, 291, 292] |
[cite_start]Only Memory Steward may decide or change the active mode. [cite: 293] The Router:
- consumes the mode
- never infers the mode
The Model:
- has no awareness of mode logic
- cannot request or change modes
Mode decision is:
- deterministic
- stateless (per request, with context)
- based on signals
[cite_start]It does not use vector similarity. [cite: 294]
The Steward may use the following signals, weighted but deterministic:
- verbs: implement, wire, refactor, design
- nouns: contract, invariant, architecture
- prohibitions: no silent changes, production-grade
- presence of code blocks
- diffs or file trees
- schemas or configs
- explicit system references
- exploratory vs executional language
- request for options vs correctness
- explicit constraints
[cite_start]If the user explicitly states a mode, it wins. [cite: 295]
[cite_start]Each request may re-evaluate mode. [cite: 296] Modes persist only if:
- reinforced by subsequent signals
- explicitly locked by user instruction
Allowed transitions (examples):
- brainstorming → engineering
- engineering → implementation
- implementation → engineering
Forbidden transitions:
- casual → implementation without reclassification
- brainstorming → implementation without confirmation
Transitions are subject to temporal coherence and dampening to prevent "mode jitter."
[cite_start]See Document 5 (Stability) for the specific hysteresis model, decay functions, and state variables. [cite: 297]
[cite_start]Modes affect routing and gating, not content. [cite: 298]
| Memory Type | engineering | implementation | brainstorming | formal_spec | casual |
|---|---|---|---|---|---|
| static_global | Yes | Yes | Yes | Yes | Yes |
| static_mode_conditioned | Yes | Yes | Yes* | Yes | No |
| reference_memory | Gated | Gated | Rare | Gated | No |
| dynamic_memory | Gated | Gated | Gated | Gated | Minimal |
[cite_start]* brainstorming uses lighter rule sets. [cite: 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314]
- engineering / implementation:
- no guessing
- production-grade patterns
- interface stability
- brainstorming:
- hypotheses allowed
- alternatives encouraged
- casual:
- no heavy constraints
Router must:
- always inject static_global
- inject static_mode_conditioned only if mode allows
- gate reference memory by mode + intent
- enforce token budgets
- preserve layer precedence
Router must never:
- change rule text
- reorder precedence
- omit required layers
Operational mode influences behavioral shaping but MUST NOT alter canonical memory precedence.
Mode may affect:
- Strictness of reasoning.
- Hypothesis allowance.
- Degree of constraint emphasis.
- Whether
static_mode_conditionedis injected.
Mode MUST NOT:
- Reorder memory layers.
- Inject new memory categories.
- Override
static_global. - Alter injection position defined in Document 01.
Mode influences instruction tone and behavioral constraints only.
Operational mode influences memory governance behavior.
Mode may affect:
- Extraction aggressiveness.
- Admission confidence thresholds.
- Whether classification-only or classification+extraction is performed.
Mode MUST NOT:
- Introduce conversational shaping rules into the Steward prompt.
- Override canonical memory semantics.
- Affect reference memory mutability rules defined in Document 03.
The Steward remains a control-plane component independent of conversational tone.
Mode classification logic belongs to the Control Plane.
Hard Invariant: Builder MUST NOT receive internal mode classification metadata. Hard Invariant: Builder MUST NOT be aware of the reasoning process that selected the mode.
The Builder sees only the behavioral shaping derived from the active mode.
The Steward may see mode explicitly as part of its classification objective.
This preserves separation between decision authority and inference execution.
If mode cannot be determined confidently:
- default to engineering
- [cite_start]never default to implementation [cite: 315]
Resolve by priority:
- explicit user instruction
- artifact presence
- linguistic intent
- previous mode
~~text mode: engineering confidence: high signals_used:
- code_blocks
- engineering_verbs lock: false ~~
[cite_start]Schema is implementation-defined but must be explicit. [cite: 316]
Router treats mode as:
- read-only
- authoritative
- required for gating
[cite_start]Router must emit telemetry for mode decisions. [cite: 317]
- Modes are orthogonal to topics
- Modes never select facts
- Modes never write memory
- Router never infers modes
- Model never sees mode logic
[cite_start]Violation is a control-plane breach. [cite: 318]
- Builds on Document 1 (Architecture)
- Enables Document 3 (Reference)
- Stabilized by Document 5 (Stability)
[cite_start]Modes control how the system thinks, not what it knows. [cite: 319] [cite_start]A small, explicit mode set is a stability mechanism, not a limitation. [cite: 320]
END OF DOCUMENT 02