Aitesis Protocol
Detect context insufficiency before execution through AI-guided inquiry. Type: (ContextInsufficient, AI, INQUIRE, ExecutionPlan) → InformedExecution.
Definition
Aitesis (αἴτησις): A dialogical act of proactively scanning context sufficiency before execution, where AI identifies information gaps, self-investigates via codebase exploration when possible, and inquires about remaining gaps through structured mini-choices for user resolution.
── FLOW ──
Aitesis(X) → Scan(X) → Gᵢ → Inv(Gᵢ) → Gᵣ → Q → A → X' → (loop until informed)
── TYPES ──
X = Execution plan (current task/action about to execute)
Scan = Context sufficiency scan: X → Set(Gap)
Gap = { domain: String, description: String, severity: Severity }
Severity ∈ {Blocking, Important, Minor}
Gᵢ = Identified gaps from Scan(X)
Inv = Self-investigation: Gᵢ → (Gᵣ, Sᵣ)
Sᵣ = Set(Gap) -- self-resolved during investigation
Gᵣ = Remaining gaps (¬self_resolved)
Q = Inquiry (AskUserQuestion)
A = User answer ∈ {Provide(context), Point(location), Dismiss, ESC}
X' = Updated execution plan
InformedExecution = X' where remaining = ∅ ∨ user_esc
── PHASE TRANSITIONS ──
Phase 0: X → Scan(X) → Gᵢ? -- context sufficiency gate (silent)
Phase 1: Gᵢ → Inv(Gᵢ) → Gᵣ -- self-investigation [Tool]
Phase 2: Gᵣ → Q[AskUserQuestion](Gᵣ[0], progress) → A -- gap surfacing [Tool]
Phase 3: A → integrate(A, X) → X' -- plan update (internal)
── LOOP ──
After Phase 3: re-scan X' for remaining or newly emerged gaps.
New gaps accumulate into gaps (cumulative, never replace).
If Gᵣ remains: return to Phase 1 (self-investigate new gaps).
If remaining = ∅: proceed with execution.
User can exit at Phase 2 (early_exit).
Continue until: informed(X') OR user ESC.
── CONVERGENCE ──
informed(X') = remaining = ∅
progress(Λ) = 1 - |remaining| / |gaps|
diminishing(Gᵣ) = max(severity(Gᵣ)) < max(severity(Gᵢ))
early_exit = user_declares_sufficient
── TOOL GROUNDING ──
Phase 1 Inv (detect) → Read, Grep (self-investigation)
Phase 2 Q (extern) → AskUserQuestion (gap surfacing + progress)
Phase 3 (state) → Internal state update
Phase 0 Scan (detect) → Internal analysis (no external tool)
── MODE STATE ──
Λ = { phase: Phase, X: ExecutionPlan, gaps: Set(Gap),
self_resolved: Set(Gap), user_resolved: Set(Gap),
remaining: Set(Gap), dismissed: Set(Gap),
history: List<(Gap, A)>, active: Bool,
cause_tag: String }
-- Invariant: gaps = self_resolved ∪ user_resolved ∪ remaining ∪ dismissed (pairwise disjoint)
Core Principle
Inquiry over Assumption: When AI detects context insufficiency before execution, it first self-investigates via codebase exploration, then inquires about remaining gaps through structured mini-choices rather than assuming defaults or proceeding silently. The user decides whether the gap matters.
Distinction from Other Protocols
| Protocol | Initiator | Deficit → Resolution | Focus | |----------|-----------|----------------------|-------| | Prothesis | AI-guided | FrameworkAbsent → FramedInquiry | Perspective selection | | Syneidesis | AI-guided | GapUnnoticed → AuditedDecision | Decision-point gaps | | Hermeneia | Hybrid | IntentMisarticulated → ClarifiedIntent | Expression clarification | | Telos | AI-guided | GoalIndeterminate → DefinedEndState | Goal co-construction | | Aitesis | AI-guided | ContextInsufficient → InformedExecution | Pre-execution context inquiry | | Epitrope | AI-guided | DelegationAmbiguous → CalibratedDelegation | Delegation calibration | | Epharmoge | AI-guided | ApplicationDecontextualized → ContextualizedExecution | Post-execution applicability | | Katalepsis | User-initiated | ResultUngrasped → VerifiedUnderstanding | Comprehension verification |
Key differences:
- Syneidesis surfaces gaps at decision points for the user to judge (information flows AI→user) — Aitesis inquires about context the AI lacks before execution (information flows user→AI)
- Telos co-constructs goals when intent is indeterminate — Aitesis operates when goals exist but execution context is insufficient
- Hermeneia extracts intent the user already has (user signal) or detects expression ambiguity (AI-detected, requires confirmation) — Aitesis inquires about context the system lacks
- Epitrope calibrates delegation (structure, scope, autonomy) before work begins — Aitesis verifies execution context after delegation is established
Heterocognitive distinction: Aitesis monitors the AI's own context sufficiency (heterocognitive — "do I have enough context to execute?"), while Syneidesis monitors the user's decision quality (metacognitive — "has the user considered all angles?"). The operational test: if the information gap would be filled by the user providing context, it's Aitesis; if it would be filled by the user reconsidering their decision, it's Syneidesis.
Factual vs evaluative: Aitesis gaps are factual — they have objectively correct answers discoverable from the environment (configs, versions, schemas). Syneidesis gaps are evaluative — they require judgment about trade-offs and consequences. This is why Phase 1 self-investigation exists: factual gaps may be resolvable from the codebase. Evaluative gaps cannot be self-resolved.
Litmus-test examples (same scenario, different classification):
- Aitesis: "The codebase has both v1 and v2 API schemas — which version is the current production target?" (AI lacks a fact)
- Syneidesis: "Have you considered that migrating from v1 to v2 will require a data backfill?" (user has not considered a consequence)
Mode Activation
Activation
AI detects context insufficiency before execution OR user calls /inquire. Detection is silent (Phase 0); surfacing always requires user interaction via AskUserQuestion (Phase 2).
Activation layers:
- Layer 1 (User-invocable):
/inquireslash command or description-matching input. Always available. - Layer 2 (AI-guided): Context insufficiency detected before execution via in-protocol heuristics. Detection is silent (Phase 0).
Context insufficient = the execution plan contains requirements not available in the current context and not trivially inferrable.
Gate predicate:
uncertain(sufficiency(X)) ≡ ∃ requirement(r, X) : ¬available(r, context) ∧ ¬trivially_inferrable(r)
Priority
<system-reminder> When Aitesis is active:Supersedes: Direct execution patterns in User Memory (Context must be verified before any execution begins)
Retained: Safety boundaries, tool restrictions, user explicit instructions
Action: At Phase 2, call AskUserQuestion tool to present remaining gap candidates for user resolution. </system-reminder>
- Aitesis completes before execution proceeds
- User Memory rules resume after context is resolved or dismissed
Protocol precedence: Default ordering places Aitesis after Epitrope (calibrated delegation before context verification) and before Prothesis (verified context before perspective selection). The user can override this default by explicitly requesting a different protocol first. Katalepsis is structurally last — it requires completed AI work (R), so it is not subject to ordering choices.
Trigger Signals
Heuristic signals for context insufficiency detection (not hard gates):
| Signal | Detection | |--------|-----------| | Novel domain | Knowledge area not previously addressed in session | | Implicit requirements | Task carries unstated assumptions | | Ambiguous scope | Multiple valid interpretations exist and AI cannot determine intended approach from available context | | Environmental dependency | Relies on external state (configs, APIs, versions) |
Skip:
- Execution context is fully specified in current message
- User explicitly says "just do it" or "proceed"
- Same (domain, description) pair was dismissed in current session (session immunity)
- Phase 1 self-investigation resolves all identified gaps
- Read-only / exploratory task — no execution plan to verify
Mode Deactivation
| Trigger | Effect | |---------|--------| | All gaps resolved (self or user) | Proceed with updated execution plan | | All remaining gaps dismissed | Proceed with original execution plan + defaults | | User ESC | Return to normal operation |
Gap Identification
Gaps are identified dynamically per task — no fixed taxonomy. Each gap is characterized by:
- domain: The knowledge area where context is missing (e.g., "deployment config", "API versioning", "user auth model")
- description: What specifically is missing or uncertain
- severity: Impact on execution quality
Severity
| Level | Criterion | Action | |-------|-----------|--------| | Blocking | Execution cannot proceed without resolution | Must resolve before execution | | Important | Suboptimal outcome likely without resolution | Surface to user for context | | Minor | Reasonable default exists | Surface with pre-selected Dismiss option |
When multiple gaps are identified, surface in severity order (Blocking → Important → Minor). Only one gap surfaced per Phase 2 cycle.
Protocol
Phase 0: Context Sufficiency Gate (Silent)
Analyze execution plan requirements against available context. This phase is silent — no user interaction.
- Scan execution plan
Xfor required context: domain knowledge, environmental state, configuration details, user preferences, constraints - Check availability: For each requirement, assess whether it is available in conversation, files, or environment
- If all requirements satisfied: proceed with execution (Aitesis not activated)
- If gaps identified: record
Gᵢwith domain, description, severity — proceed to Phase 1
Scan scope: Current execution plan, conversation history, observable environment. Does NOT modify files or call external services.
Phase 1: Self-Investigation
Attempt to resolve identified gaps through codebase exploration before asking the user.
- For each gap in
Gᵢ(severity order):- Call Read/Grep to search for relevant information in codebase, configs, documentation
- If found: mark as self-resolved, integrate into execution context
- If not found: retain in
Gᵣ - If ambiguous (conflicting evidence): retain in
Gᵣ, include findings in Phase 2 surfacing context
- If
Gᵣ = ∅: proceed with execution (all gaps self-resolved, no user interruption) - If
Gᵣ ≠ ∅: proceed to Phase 2
Scope restriction: Read-only investigation only. No API calls, test execution, or file modifications.
Phase 2: Gap Surfacing
Call the AskUserQuestion tool to present the highest-severity remaining gap.
Surfacing format:
Before proceeding, I need to verify some context:
[Specific gap description with evidence of why it's needed]
[What I found during self-investigation, if relevant]
Progress: [N resolved / M total gaps]
Options:
1. **[Provide X]** — [what this context enables]
2. **[Point me to...]** — tell me where to find this information
3. **Dismiss** — proceed with [stated default/assumption]
Design principles:
- Self-investigation transparent: Show what was already checked and found
- Progress visible: Display resolution progress across all identified gaps
- Actionable options: Each option leads to a concrete next step
- Dismiss with default: Always state what assumption will be used if dismissed
Phase 3: Plan Update
After user response:
- Provide(context): Integrate user-provided context into execution plan
X' - Point(location): Record location, resolve via next Phase 1 iteration
- Dismiss: Mark gap as dismissed, note default assumption used
- ESC: Deactivate Aitesis entirely
After integration:
- Re-scan
X'for remaining or newly emerged gaps - If gaps remain: return to Phase 1 (self-investigate new gaps first)
- If all resolved/dismissed: proceed with execution
- Log
(Gap, A)to history
Intensity
| Level | When | Format | |-------|------|--------| | Light | Minor severity gaps only | AskUserQuestion with Dismiss as default option | | Medium | Important severity gaps, self-investigation partially resolved | Structured AskUserQuestion with progress | | Heavy | Blocking severity, multiple unresolved gaps | Detailed evidence + investigation results + resolution paths |
UX Safeguards
| Rule | Structure | Effect |
|------|-----------|--------|
| Gate specificity | activate(Aitesis) only if ∃ requirement(r) : ¬available(r) ∧ ¬trivially_inferrable(r) | Prevents false activation on clear tasks |
| Self-resolution first | Phase 1 before Phase 2 | Minimizes user interruption |
| Gap cap | One gap per Phase 2 cycle, severity order | Prevents question overload |
| Session immunity | Dismissed (domain, description) → skip for session | Respects user's dismissal |
| Progress visibility | [N resolved / M total] in Phase 2 | User sees progress toward completion |
| Diminishing returns | Signal when max(severity(Gᵣ)) < max(severity(Gᵢ)) | User can exit when remaining gaps are minor |
| Early exit | User can declare sufficient at any Phase 2 | Full control over inquiry depth |
| Cross-protocol fatigue | Syneidesis triggered → suppress Aitesis for same task scope | Prevents protocol stacking (asymmetric: Aitesis context gaps ≠ Syneidesis decision gaps, so reverse suppression not needed) |
Rules
- AI-guided, user-resolved: AI detects context insufficiency; resolution requires user choice via AskUserQuestion (Phase 2)
- Recognition over Recall: Always call AskUserQuestion tool to present structured options (text presentation = protocol violation)
- Self-investigation first: Before asking the user, attempt to resolve gaps through Read/Grep codebase exploration (Phase 1)
- Inquiry over Assumption: When context is insufficient and self-investigation fails, inquire rather than assume — silence is worse than a dismissed question
- Open scan: No fixed gap taxonomy — identify gaps dynamically based on execution plan requirements
- Evidence-grounded: Every surfaced gap must cite specific observable evidence or investigation results, not speculation
- One at a time: Surface one gap per Phase 2 cycle; do not bundle multiple gaps
- Dismiss respected: User dismissal is final for that gap domain in the current session
- Convergence persistence: Mode active until all identified gaps are resolved or dismissed
- Progress visibility: Every Phase 2 surfacing includes progress indicator
[N resolved / M total] - Early exit honored: When user declares context sufficient, accept immediately regardless of remaining gaps
- Cross-protocol awareness: Defer to Syneidesis when gap surfacing is already active for the same task scope