Goal

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:

1. Selection over Detection: User selects which dimensions are indeterminate (not elicited by checklist)
2. Morphism firing: Activates only when GoalIndeterminate precondition is recognized — not a mandatory pipeline stage
3. 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

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

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.

• 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

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

Gap Taxonomy

Dimension Priority

When multiple dimensions are undefined:

1. Outcome (highest): End state anchors all other dimensions
2. Boundary: Scope constrains feasibility
3. Priority: Trade-off values guide choices
4. 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:

1. Strong trigger: User uses uncertainty/exploratory language → activate with confirmation
2. Soft trigger: User uses vague qualitative ("improve") → suggest only, do not activate
3. 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:

1. Accept: Set GoalContract field to proposal value
2. Modify(aspect, direction): Adjust proposal per user direction, re-propose if needed
3. Reject: Discard proposal, generate alternative approach
4. 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

Rules

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