Telos Protocol

Co-construct defined end states from vague goals through AI-proposed, user-shaped dialogue. Type: (GoalIndeterminate, AI, CO-CONSTRUCT, VagueGoal) → DefinedEndState.

Definition

Telos (τέλος): A dialogical act of co-constructing a defined end state from a vague goal, where AI proposes concrete candidates and the user shapes them through structured accept, modify, or reject responses.

── FLOW ──
G → Gᵥ → Dₛ → P → A → C' → (loop until sufficient)

── TYPES ──
G   = User's vague goal (the goal to define)
Gᵥ  = Verified vague goal (user-confirmed)
Dₛ  = Selected dimension ∈ {Outcome, Metric, Boundary, Priority}
Dₐ  = Applicable dimensions (user-selected subset, |Dₐ| ≥ 1)
P   = Proposal (AI-generated concrete candidate)
A   = User's response ∈ {Accept, Modify(aspect, direction), Reject, Extend(aspect)}
C   = GoalContract { outcome: ?, metric: ?, boundary: ?, priority: ? }
C'  = Updated GoalContract after integration

── G-BINDING ──
bind(G) = explicit_arg ∪ colocated_expr ∪ prev_user_turn
Priority: explicit_arg > colocated_expr > prev_user_turn

/goal "text"                → G = "text"
"define goal... goal"       → G = text before trigger
/goal (alone)               → G = previous user message

Edge cases:
- Interrupt: G = original request of interrupted task
- Queued:    G = previous message at queue time (fixed)
- Re-invoke: Show prior GoalContract, confirm or restart

── PHASE TRANSITIONS ──
Phase 0:  G → recognize(G) → Q[AskUserQuestion](confirm) → Gᵥ  -- trigger + confirm [Tool]
Phase 1:  Gᵥ → Q[AskUserQuestion](dimensions) → Dₐ, Dₛ         -- dimension selection [Tool]
Phase 2:  Dₛ → propose(Dₛ, context) → P                        -- AI proposal (internal)
        → Q[AskUserQuestion](P) → await → A                     -- co-construction [Tool]
Phase 3:  A → integrate(A, C) → C'                             -- contract update (internal)
Phase 4:  C' → Q[AskUserQuestion](C', progress) → approve       -- sufficiency check [Tool]

── LOOP ──
After Phase 3: compute progress(C', Dₐ).
If undefined dimensions remain in Dₐ: return to Phase 1 (next dimension).
If all Dₐ defined: proceed to Phase 4.
User can trigger Phase 4 early at any Phase 1 (early_exit).
Continue until: user approves GoalContract OR user ESC.

── CONVERGENCE ──
sufficient(C, Dₐ) = user_approves(C)
progress(C, Dₐ) = |{f ∈ Dₐ | defined(f)}| / |Dₐ|
early_exit = user_declares_sufficient (any progress level)

── TOOL GROUNDING ──
Phase 0 Q  (extern)  → AskUserQuestion (goal confirmation + activation approval)
Phase 1 Q  (extern)  → AskUserQuestion (dimension selection + progress display)
Phase 2 P  (detect)  → Read, Grep (context for proposal generation; fallback: template)
Phase 2 Q  (extern)  → AskUserQuestion (proposal with structured response options)
Phase 3    (state)   → Internal GoalContract update (no external tool)
Phase 4 Q  (extern)  → AskUserQuestion (GoalContract review + approval)

── MODE STATE ──
Λ = { phase: Phase, G: Goal, Gᵥ: Goal, applicable: Set(Dim),
      contract: GoalContract, history: List<(Dₛ, P, A)>, active: Bool }

Core Principle

Construction over Extraction: AI proposes concrete candidates; user shapes through structured response options. Neither party holds the complete answer alone.

Epistemic Distinction from Requirements Engineering

Telos is not simplified requirements gathering. Three differentiators:

Selection over Detection: User selects which dimensions are indeterminate (not elicited by checklist)
Morphism firing: Activates only when GoalIndeterminate precondition is recognized — not a mandatory pipeline stage
Falsifiable proposals: AI proposes specific candidates that can be directly accepted or rejected, surfacing value conflicts and trade-offs (epistemic function) rather than collecting specifications (engineering function)

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 | | Prosoche | AI-guided | ExecutionBlind → SituatedExecution | Execution-time risk evaluation | | Epharmoge | AI-guided | ApplicationDecontextualized → ContextualizedExecution | Post-execution applicability | | Katalepsis | User-initiated | ResultUngrasped → VerifiedUnderstanding | Comprehension verification |

Key difference: Hermeneia EXTRACTS (assumes intent exists inside user). Telos CO-CONSTRUCTS (assumes neither party has the complete answer). The precondition witness differs: Hermeneia requires ∃ intent I, Telos starts from ¬∃ intent I.

Mode Activation

Activation

AI detects goal indeterminacy OR user invokes /goal. Activation always requires user confirmation via AskUserQuestion (Phase 0).

Activation layers:

Layer 1 (User-invocable): /goal slash command or description-matching input. Always available.
Layer 2 (AI-guided): Goal indeterminacy detected (2+ dimensions unspecified) via in-protocol heuristics. Activation requires user confirmation.

Goal indeterminate = 2+ of {outcome, metric, boundary, priority} are unspecified in the user's request.

Priority

<system-reminder> When Telos is active:

Supersedes: Direct execution patterns in User Memory (Goal must be defined before any implementation begins)

Retained: Safety boundaries, tool restrictions, user explicit instructions

Action: At Phase 2, call AskUserQuestion tool to present concrete proposals for goal construction. </system-reminder>

Telos completes before implementation workflows begin
User Memory rules resume after GoalContract is approved

Protocol precedence: Default ordering places Telos after Hermeneia and before Epitrope (Hermeneia → Telos → Epitrope → Aitesis → Prothesis → Syneidesis → Prosoche → Epharmoge; clarified intent before goal construction, defined goals before delegation calibration). 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.

Approved GoalContract becomes input to subsequent protocols.

Triggers

| Signal | Strength | Examples | |--------|----------|----------| | Acknowledged uncertainty | Strong | "not sure what I want", "something like", "kind of" | | Scope absence | Strong | "the whole thing", "everything", "wherever needed" | | Exploratory framing | Strong | "what could we do about", "ideas for", "how might we" | | Vague qualitative | Soft (suggest only) | "improve", "better", "optimize" |

Soft triggers: AI may suggest Telos activation via AskUserQuestion but must NOT auto-activate. Only strong triggers or explicit /goal invocation activate directly.

Skip:

User's goal is already verifiable (concrete deliverable + criteria specified)
User explicitly declines goal definition
Goal already defined in current session

Mode Deactivation

| Trigger | Effect | |---------|--------| | GoalContract approved | Proceed with defined goal | | User accepts current state | GoalContract as-is deemed sufficient | | User explicitly cancels | Return to normal operation |

Gap Taxonomy

| Type | Detection | Question Form | GoalContract Field | |------|-----------|---------------|--------------------| | Outcome | No concrete end state described | "What exists/changes when this is done?" | desired_result | | Metric | No success criteria mentioned | "How will you judge success vs failure?" | success_criteria | | Boundary | Scope unbounded or implicit | "What's included? What's explicitly excluded?" | scope, non_goals | | Priority | Trade-off values unstated | "When X conflicts with Y, which wins?" | value_weights |

Dimension Priority

When multiple dimensions are undefined:

Outcome (highest): End state anchors all other dimensions
Boundary: Scope constrains feasibility
Priority: Trade-off values guide choices
Metric (lowest): Success criteria refine after core is clear

Outcome is always included in applicable dimensions (minimum |Dₐ| ≥ 1).

Protocol

Phase 0: Trigger Recognition + Confirmation

Recognize goal indeterminacy and confirm activation:

Strong trigger: User uses uncertainty/exploratory language → activate with confirmation
Soft trigger: User uses vague qualitative ("improve") → suggest only, do not activate
Explicit invocation: /goal → skip confirmation, proceed to Phase 1

Call the AskUserQuestion tool to confirm activation:

I notice your goal may need definition before we proceed.

Options:
1. **Define goal together** — co-construct what "done" looks like
2. **Proceed as-is** — the current description is sufficient

Skip condition: If G was explicitly provided via /goal "text", proceed directly to Phase 1.

Phase 1: Dimension Selection

Call the AskUserQuestion tool with multiSelect: true to let user select applicable dimensions.

Present dimensions with current GoalContract progress:

Which aspects of the goal need definition? (select all that apply)

Options:
1. **Outcome** — what the end state looks like [required]
2. **Boundary** — what's included and excluded
3. **Priority** — what matters most in trade-offs
4. **Metric** — how to judge success

On loop re-entry: show progress ([defined] / [undefined]) and present only remaining undefined dimensions. Include "Sufficient — approve current GoalContract" option for early exit.

Phase 2: Co-Construction

Call the AskUserQuestion tool to present a concrete proposal.

Do NOT present proposals as plain text. The tool call is mandatory — text-only presentation is a protocol violation.

High-context (codebase/conversation context available via Read/Grep):

Based on [context analysis], here's a concrete [dimension]:

  "[specific proposal grounded in codebase/conversation]"

Options:
1. Accept — proceed with this definition
2. Modify: [aspect A] / [aspect B] / [aspect C] — select what to change
3. Reject — start from different angle

Low-context fallback (no file/codebase context):

For [dimension], here are common patterns for this type of goal:

Options:
1. "[Template A]" — [brief description]
2. "[Template B]" — [brief description]
3. "[Template C]" — [brief description]
4. Describe directly — provide your own definition

Proposal design principles:

Concrete and falsifiable: Specific enough to accept or reject immediately
Context-grounded: Based on Read/Grep analysis when available, template fallback when not
Structured modification: Modify options present specific aspects to change, not free text
Trade-off visible: Show implications of accepting this proposal

Phase 3: Integration

After user response:

Accept: Set GoalContract field to proposal value
Modify(aspect, direction): Adjust proposal per user direction, re-propose if needed
Reject: Discard proposal, generate alternative approach
Extend(aspect): Add user's aspect to existing proposal

After integration:

Compute progress(C', Dₐ)
If undefined dimensions remain: return to Phase 1
If all defined: proceed to Phase 4
Log (Dₛ, P, A) to history for cycle detection

Phase 4: Sufficiency Check

Call the AskUserQuestion tool to present the assembled GoalContract for approval.

## GoalContract (progress/total)

- **Outcome**: [defined value or "—"]
- **Metric**: [defined value or "—" or "N/A"]
- **Boundary**: [defined value or "—" or "N/A"]
- **Priority**: [defined value or "—" or "N/A"]

Options:
1. **Approve** — proceed with this GoalContract
2. **Revise [dimension]** — return to refine a specific field
3. **Add dimension** — define an additional field

Intensity

| Level | When | Format | |-------|------|--------| | Light | Minor scope vagueness, single dimension | "Quick check: the goal is [X]?" | | Medium | Multiple undefined dimensions | "[Dimension]. Proposal: [X]. Accept/Modify?" | | Heavy | Core outcome undefined, high stakes | "Before proceeding: [detailed proposal with trade-offs]" |

Rules

AI-guided, user-confirmed: AI recognizes goal indeterminacy; activation requires user approval via AskUserQuestion (Phase 0)
Recognition over Recall: Always call AskUserQuestion tool to present options (text presentation = protocol violation). Modify options use structured sub-choices, not free text
Selection over Detection: User selects applicable dimensions in Phase 1; AI does not auto-sequence or force all 4
Construction over Extraction: AI proposes falsifiable candidates, not abstract questions
Concrete proposals: Every proposal must be specific enough to accept or reject
User authority: User shapes, accepts, or rejects; AI does not override
Progress visibility: Show GoalContract completion status (defined/total selected) at each Phase 1
Convergence persistence: Mode active until GoalContract approved or user ESC
Early exit: User can declare sufficient at any point (any progress level permitted)
Context grounding: Proposals based on Read/Grep when available; template fallback when not
Small phases: One dimension per cycle; no bundling unless user requests
Escape hatch: User can provide own definition for any field directly