Epharmoge Protocol

Detect application-context mismatch after execution through AI-guided applicability verification, where correct results that may not fit the actual context are surfaced for user judgment. Type: (ApplicationDecontextualized, AI, CONTEXTUALIZE, ExecutionResult) → ContextualizedExecution.

Definition

Epharmoge (ἐφαρμογή): A dialogical act of verifying that AI-produced results fit the actual application context — from Aristotle's notion of practical application — resolving the gap between technical correctness and contextual appropriateness through structured mismatch surfacing and user-directed adaptation.

── FLOW ──
Epharmoge(R, X) → Eval(R, X) → Mᵢ? → Q → A → R' → (loop until contextualized)

── MORPHISM ──
(R, X)
  → evaluate(result, context)          -- detect applicability mismatch
  → surface(mismatch, as_inquiry)      -- present mismatch with evidence
  → adapt(result, direction)           -- adapt result to context
  → ContextualizedExecution
requires: mismatch_detected(R, X)       -- runtime gate (Phase 0)
deficit:  ApplicationDecontextualized    -- activation precondition (Layer 1/2)
preserves: X                             -- application context is fixed reference; morphism transforms R only
invariant: Applicability over Correctness

── TYPES ──
R     = Execution result (AI's completed work output)
X     = Application context (environment, constraints, user situation)
Eval  = Applicability evaluation: (R, X) → Set(Mismatch)
Mismatch = { aspect: String, description: String, evidence: String, severity: Severity }
Severity ∈ {Critical, Significant, Minor}
Mᵢ    = Identified mismatches from Eval(R, X)
Q     = Applicability inquiry (AskUserQuestion)
A     = User answer ∈ {Confirm(mismatch), Adapt(direction), Dismiss}
R'    = Adapted result (contextualized output)
ContextualizedExecution = R' where applicable(R', X) ∨ user_esc

── PHASE TRANSITIONS ──
Phase 0: R → Eval(R, X) → Mᵢ?                              -- applicability gate (silent)
Phase 1: Mᵢ → Q[AskUserQuestion](Mᵢ[0], evidence) → A      -- mismatch surfacing [Tool]
Phase 2: A → adapt(A, R) → R'                                -- result adaptation [Tool]

── LOOP ──
After Phase 2: re-evaluate R' against X for remaining mismatches.
If Mᵢ remains: return to Phase 1.
If applicable(R', X): execution complete.
User can exit at Phase 1 (early_exit).
Continue until: contextualized(R') OR user ESC.

── CONVERGENCE ──
applicable(R', X) = ∀ aspect(a, R', X) : warranted(a, R', X)
warranted(a, R, X) = correct(R) ∧ fits(R, X)                -- correctness AND contextual fit required (not material conditional)
contextualized(R') = applicable(R', X) ∨ user_esc
progress(Λ) = 1 - |remaining| / |mismatches|

── TOOL GROUNDING ──
Phase 0 Eval  (detect)  → Internal analysis (no external tool)
Phase 1 Q     (extern)  → AskUserQuestion (mandatory; Esc key → loop termination at LOOP level, not an Answer)
Phase 2 adapt (modify)  → Edit, Write (result adaptation based on user direction)
                           -- (modify): tool call that changes existing artifacts (distinct from (extern) user-facing, (detect) read-only, (state) internal)

── MODE STATE ──
Λ = { phase: Phase, R: Result, X: Context,
      mismatches: Set(Mismatch), confirmed: Set(Mismatch),
      adapted: Set(Mismatch), dismissed: Set(Mismatch),
      remaining: Set(Mismatch),
      history: List<(Mismatch, A)>, active: Bool,
      cause_tag: String }
-- Invariant: mismatches = confirmed ∪ adapted ∪ dismissed ∪ remaining (pairwise disjoint)

Core Principle

Applicability over Correctness: When AI detects that a technically correct result may not fit the actual application context, it surfaces the mismatch with evidence rather than assuming the result is adequate. Correctness is necessary but not sufficient — contextual fit determines whether the result serves its purpose.

Formal predicate: correct(R) ∧ ¬warranted(R, X) — the output is correct but not warranted in this context (Dewey's warranted assertibility; Ryle's knowing-how vs knowing-that).

Distinction from Other Protocols

Key differences:

• Aitesis infers context the AI lacks before execution (User→AI direction) — Epharmoge evaluates whether the completed result fits the context (AI→User direction). Same axis (context fitness), opposite timing and information flow.
• Katalepsis verifies the user's comprehension of correct results (P'≅R) — Epharmoge verifies the result's applicability to context (R≅X). Convergence conditions are structurally incompatible.
• Syneidesis surfaces gaps in the user's decision quality — Epharmoge surfaces gaps in the AI's execution quality. Different audit targets even when addressing the same domain.

Context fitness axis: Aitesis and Epharmoge form a pre/post pair on the context fitness axis. Aitesis asks "do I have enough context to execute well?" (factual uncertainties, User→AI). Epharmoge asks "does my execution actually fit the context?" (evaluative mismatches, AI→User). They are complementary, not redundant — Aitesis may gather sufficient context, yet the resulting execution may still not fit contextual constraints that only become visible post-execution.

Independence from Aitesis: Epharmoge's information source is the execution result itself (R) compared against observed context (X), not a re-scan of pre-execution context. This ensures non-circularity — even when Aitesis has fully resolved context uncertainties, Epharmoge can detect mismatches that emerge only from the actual output.

Mode Activation

Conditional Gate

This protocol is conditional. AI-guided activation (Layer 2) requires operational experience with Aitesis (④) to validate the pre/post context fitness axis. Until this gate is satisfied, Epharmoge exists as a formal specification only and must not auto-activate via Layer 2.

Activation criteria: Observed pattern of "context gathered but application mismatched" in Aitesis inference operational data.

User-invocable activation (Layer 1 / /contextualize) is always available regardless of this gate.

Activation

AI detects applicability mismatch after execution OR user calls /contextualize. Detection is silent (Phase 0); surfacing always requires user interaction via AskUserQuestion (Phase 1).

Application decontextualized = the execution result is technically correct but may not fit the actual application context.

Gate predicate:

decontextualized(R, X) ≡ correct(R) ∧ ∃ aspect(a, R, X) : ¬warranted(a, R, X)

Activation layers:

• Layer 1 (User-invocable): /contextualize slash command or description-matching input. Available regardless of conditional gate.
• Layer 2 (AI-guided): Post-execution heuristic detection within SKILL.md. Subject to conditional gate.

Priority

Supersedes: Default post-execution patterns (move to next task without applicability check)

Retained: Safety boundaries, tool restrictions, user explicit instructions

Action: At Phase 1, call AskUserQuestion tool to present mismatch evidence for user judgment. </system-reminder>

• Epharmoge completes before proceeding to next task
• Loaded instructions resume after applicability is verified or dismissed

Protocol precedence: Default ordering places Epharmoge after Prosoche (execution-time attention before post-execution applicability) and before Katalepsis (applicability before comprehension). Katalepsis is structurally last — it requires completed AI work (R), so it is not subject to ordering choices. The user can override this default by explicitly requesting a different protocol first.

Trigger Signals

Heuristic signals for applicability mismatch detection (not hard gates):

Skip:

• User provided explicit, detailed specification and result follows it exactly
• User explicitly says "looks good" or "proceed" after execution
• Trivial or mechanical execution (formatting, typo fixes, rename)
• Read-only / exploratory task — no execution result to evaluate
• Same (aspect, description) pair was dismissed in current session (session immunity)

Mode Deactivation

Mismatch Identification

Mismatches are identified dynamically per execution result — no fixed taxonomy. Each mismatch is characterized by:

• aspect: The dimension where result and context diverge (e.g., "deployment target", "API version", "team convention")
• description: What specifically doesn't fit
• evidence: Observable indicator from the execution result or context
• severity: Impact on applicability

Severity

When multiple mismatches are identified, surface in severity order (Critical → Significant → Minor). Only one mismatch surfaced per Phase 1 cycle.

Protocol

Phase 0: Applicability Gate (Silent)

Evaluate execution result against application context. This phase is silent — no user interaction.

1. Scan execution result R against context X: environment state, project conventions, use case scope, temporal validity, user constraints
2. Check applicability: For each aspect, assess whether correct(R) ∧ fits(R, X) (i.e., warranted(R, X))
3. If all aspects warranted: execution stands (Epharmoge not activated)
4. If mismatches identified: record Mᵢ with aspect, description, evidence, severity — proceed to Phase 1

Information source: The execution result R itself compared against observable context X. NOT a re-scan of pre-execution context (non-circularity with Aitesis).

Scan scope: Completed execution output, project structure, observed conventions, session context. Does NOT re-execute or modify files.

Phase 1: Mismatch Surfacing

Call the AskUserQuestion tool to present the highest-severity remaining mismatch.

Do NOT present mismatches as plain text. The tool call is mandatory — text presentation without tool = protocol violation.

Surfacing format (natural integration with execution completion):

Done. One thing to verify about applicability:

[Specific mismatch description]
[Evidence: what in the result and what in the context diverge]

Progress: [N addressed / M total mismatches]

Options:
1. **Confirm** — yes, this needs adaptation: [brief direction prompt]
2. **Dismiss** — acceptable as-is: [stated assumption about context fit]

If adaptation direction is evident, include:

3. **[Specific adaptation]** — [what would change and why]

Design principles:

• Evidence-grounded: Every surfaced mismatch must cite specific observable evidence from both R and X
• Post-execution natural: Integrates with task completion flow ("Done. One thing to verify:")
• Progress visible: Display resolution progress across all identified mismatches
• Actionable options: Each option leads to a concrete next step
• Dismiss with assumption: Always state what fitness assumption is accepted if dismissed

Phase 2: Result Adaptation

After user response:

1. Confirm(mismatch): Mark mismatch as confirmed, apply adaptation using Edit/Write tools
2. Adapt(direction): Apply user-directed adaptation to result R' using Edit/Write tools
3. Dismiss: Mark mismatch as dismissed, note fitness assumption accepted

After adaptation:

• Re-evaluate R' against X for remaining or newly emerged mismatches
• If mismatches remain: return to Phase 1 (surface next mismatch)
• If all resolved/dismissed: execution complete with contextualized result
• Log (Mismatch, A) to history

Intensity

UX Safeguards

Rules

1. AI-guided, user-judged: AI detects applicability mismatch; user judges whether adaptation is needed via AskUserQuestion (Phase 1)
2. Recognition over Recall: Always call AskUserQuestion tool to present mismatches with evidence — text presentation without tool = protocol violation
3. Applicability over Correctness: When result is correct but contextually mismatched, surface the mismatch — do not assume correctness implies fitness
4. Evidence-grounded: Every surfaced mismatch must cite specific observable evidence from both result R and context X, not speculation
5. One at a time: Surface one mismatch per Phase 1 cycle; do not bundle multiple mismatches
6. Dismiss respected: User dismissal is final for that mismatch aspect in the current session
7. Convergence persistence: Mode active until all identified mismatches are resolved or dismissed
8. Non-circularity: Information source is the execution result itself compared against context, not pre-execution context scans (independence from Aitesis)
9. Early exit honored: When user accepts result as-is, accept immediately regardless of remaining mismatches
10. Cross-protocol awareness: Suppress when Aitesis resolved overlapping domains in the same execution scope (within recommendation chains only)
11. Conditional gate: AI-guided activation (Layer 2) requires Aitesis operational experience confirmation. User-invocable activation (Layer 1 / /contextualize) is always available