Scope of This Task

Your task is to prepare an implementation plan, not to execute the implementation. The plan will be reviewed and refined before any implementation work begins in a separate thread.

You will produce one document: Working — Analytical Territories and Modes Implementation Plan.md. The document will lay out a complete, sequenced, dependency-aware implementation plan for migrating the Wisdom Nexus mode registry to the new architecture documented in the research report. The plan will be executed in a fresh thread (or threads) after review.

Do not begin migration work, do not modify existing mode specifications, do not create new mode files, and do not update the mode registry directly. Read, analyze, and produce the plan only.

Context You Need to Read First

Before producing the plan, read the following in the vault:

Foundational architecture documents:

  • Registry — Mode Registry.md — current registry with 25 modes
  • Reference — Ora Overview and Document Registry.md — system architecture
  • Framework — Decision Clarity Analysis.md (renamed from Framework — Wicked Problems.md 2026-05-01) — canonical molecular framework specification
  • Reference — Detecting Frame-Manipulation in Argumentative Artifacts.md — research source for Frame Audit
  • Reference — Fallacy Detection as an Analytical Mode.md — research source for Coherence Audit
  • The research report containing the territory inventory, gradation sets, disambiguation patterns, and source-tradition survey (provided as input to this task)

Existing mode specifications:

  • All files in Modes/ (or wherever existing mode specs live in the vault)
  • Note especially Steelman Construction Analysis, which the research report recommends re-homing from its current location to T15 (Artifact Evaluation by Stance) with T1 cross-reference

Existing operational frameworks (for pattern reference, not modification):

  • All files in Frameworks/ that document operational machinery patterns, particularly anything related to System File Drift Correction (the dual-maintenance pattern between vault and ora)

Mode clarification procedure (to be superseded):

  • The mode clarification procedure documented yesterday — locate this in the vault. The research report’s territory-based two-stage routing supersedes it. Your plan should specify how to retire the clarification procedure cleanly.

Architectural Decisions Already Made

The following architectural decisions have been made by the user and are not open for revision in the plan. The plan implements these; it does not evaluate alternatives to them.

Decision 1: Deep-Mode-Default Routing With Friction Reducers

The system defaults to deep-mode routing — full territory and within-territory disambiguation invoked when warranted — rather than auto-routing to atomic Tier-2 by default. The deep-mode default is mitigated by friction reducers that recognize when the user’s prompt has already supplied disambiguation signals and skip the corresponding questions.

Rationale: friction in disambiguation is informative; the user learns the system’s analytical distinctions through encountering them. The goal is not to minimize friction but to ensure every unit of friction earns its existence by producing user understanding or routing accuracy. Friction that does neither is eliminated; friction that does either is preserved.

The architecture has a four-stage pre-routing pipeline:

Stage 1 — Pre-analysis filter. Distinguishes prompts that need no analytical machinery from prompts that do. Pure data fetches, pure rendering tasks, conversational interaction, and casual factual review route to direct response and bypass the analytical router entirely. The filter is permissive — it lets ambiguous cases through to the router rather than gatekeeping.

The criterion: route to direct response when the prompt’s request is satisfiable without producing a structured analytical artifact (audit, mapping, ranked options set, scenario set, hypothesis evaluation, stakeholder analysis). Anything that would benefit from a structured analytical artifact goes through the router.

The filter is implemented as a signal-based classifier examining the prompt for analytical-artifact signals (“what’s wrong with,” “should I,” “evaluate this,” “compare these,” “who benefits,” “audit,” “analyze,” “examine,” “assess the risk,” “trace the cause,” “make a case for/against,” etc.). Prompts without any analytical-artifact signal route to direct response.

Stage 2 — Prompt sufficiency analyzer. For prompts that warrant analytical work, examines what disambiguation questions the standard deep-mode flow would ask and checks whether the prompt has already answered them. Skips questions that are answered; asks questions that aren’t.

For each question the standard disambiguation flow would ask, the analyzer checks whether the prompt contains explicit or strongly implicit signals that resolve it:

  • Territory disambiguation answered when: prompt names an artifact type that fixes the territory; prompt includes vocabulary that strongly maps to one territory; prompt explicitly references a method by name.
  • Within-territory disambiguation answered when: prompt specifies depth explicitly (“quick read,” “thorough,” “deep dive”); prompt specifies stance explicitly (“steelman,” “stress-test,” “neutrally”); prompt specifies complexity explicitly or via situational signals (“multiple stakeholders with conflicting values” → multi-stakeholder; “feedback loops” or “vicious cycle” → systemic).
  • Specificity disambiguation answered when: prompt names a specialized domain; prompt names a specific method.

Confidence thresholds matter — strong signals (explicit vocabulary, clear artifact-type) dispatch directly; weak signals (implication from context, tonal cues) trigger disambiguation despite the implicit signal.

Multiple signals compose — “give me a quick steelman of this op-ed” answers territory (T15), stance (constructive), and depth (light) and dispatches directly to a Tier-1 Steelman.

Conflicting signals trigger clarification — “thorough quick analysis” surfaces the conflict for user resolution.

The analyzer’s output is either a complete dispatch decision (which mode to run) or a residual question set (the disambiguation questions the prompt did not answer).

Stage 3 — Input completeness check. Once the route is determined, checks whether the dispatched mode has the inputs it needs. If yes, the mode runs. If not, the system requests missing inputs in plain language with enough specificity that the user can supply them efficiently.

The completeness check distinguishes:

  • Missing input — no input present; user must supply.
  • Underspecified input — partial input present; user must specify aspects.
  • Optional improvement — input present but additional context would deepen analysis.

The check is intelligent about what counts as input across formats (pasted text, attached documents, URLs, references to prior conversation), about what’s truly missing vs. underspecified, and about what the user can reasonably be expected to know given the prompt’s apparent expertise level.

The response when inputs are insufficient must:

  • Lead with what the system can do once inputs are supplied, not with what it can’t.
  • Make the request scannable (3–4 items max, each 1–2 lines), not exhaustive.
  • Explain why each missing item matters for the requested analysis.
  • Distinguish “must have” from “would help” so the user knows which gaps are blocking.
  • Offer to proceed with reduced inputs (and a lighter sibling mode if appropriate) rather than blocking absolutely.

Stage 4 — Mode execution. The dispatched mode runs against validated inputs. The mode’s own named failure modes and correction protocols handle execution-stage problems.

Decision 2: Educational Parenthetical Convention

When the prompt sufficiency analyzer dispatches without asking, the system surfaces the dispatched mode in plain language at the start of the response, with the mode name in parenthetical italics for educational signal:

“Running a steelman analysis (the strongest-case version of an argument) on this op-ed…”

This is the progressive-disclosure mechanism. Users learn the mode taxonomy through observation of what the system actually does, even when no question was asked. The convention applies to both auto-dispatched and disambiguated routes.

Decision 3: Dual Input Contract — Expert and Accessible Versions

Mode input contracts have two versions:

  • Expert mode contract — the formal specification a domain expert would supply (formal variables, hypothesized causal relationships, structured criteria sets, etc.).
  • Accessible mode contract — the plain-language equivalent an ordinary user would supply (informal description, conversational specification, examples).

The completeness checker uses signal detection to determine which contract version to apply (default: accessible) and validates against that version. The mode specification template includes both contract versions plus detection signals.

Decision 4: Signal Vocabulary Registry

The prompt sufficiency analyzer is supported by a signal vocabulary registry — a maintained artifact that maps prompt vocabulary to territories, modes, and disambiguation answers. The registry is updated as new modes are added in Wave 2, 3, and 4. It is a lightweight registry the analyzer consults, parallel to the Lenses library in being an artifact maintained alongside the modes themselves.

What the Implementation Plan Must Cover

The plan should be organized as a sequenced set of phases, each with explicit dependencies, deliverables, success criteria, and risk assessment. Use the build sequencing in §14 of the research report as the starting point, but extend it with the operational details the research report does not specify and integrate the four pre-routing pipeline stages from Decision 1.

Phase 1: Architecture Lock

Before any migration or new-mode work, the architecture itself must be locked. The plan should specify:

  1. Territory inventory document — a standalone reference document in the vault (Reference — Analytical Territories.md or similar) capturing the 21-territory inventory from §3 of the research report. This is the architectural source-of-truth for territory assignments. Specify the document’s structure, the metadata each territory entry carries, and how modes will reference it.

  2. Mode specification template — the template from §4 of the research report, locked as the standard for all new and migrated modes, extended with the dual input contract structure (Decision 3) and escalation_signals declarations (so escalation hooks are first-class even though the deep-mode default reduces their frequency of invocation). Specify where the template lives in the vault, how modes reference it, and what tooling (if any) validates conformance. The template includes territory and gradation_position fields as first-class.

    The dual input contract section of the template should look approximately:

    input_contract:
  expert_mode:
    required: [<formal fields>]
    optional: [<formal fields>]
  accessible_mode:
    required: [<plain-language equivalents>]
    optional: [<plain-language equivalents>]
  detection:
    expert_signals: [<vocabulary indicating expert use>]
    default: accessible_mode
  graceful_degradation:
    absolutely_required: [<inputs without which no analysis is possible>]
    defaultable: [<inputs with reasonable defaults if absent>]
    what_is_lost_with_defaults: "<description>"

  3. Disambiguation style guide — the style guide from §5 of the research report, locked as the standard for all routing questions. Specify where it lives, what governance applies to changes, and how it’s referenced by the registry. Extend the style guide with patterns for completeness-check responses (Stage 3 of the pre-routing pipeline) — these have a different shape than disambiguation questions and need their own pattern catalog.

  4. Lens library specification — §12.3 of the research report specifies that foundational lenses should be embedded as structured artifacts (e.g., the Walton scheme catalog as a structured table with scheme-name/premise-pattern/conclusion-pattern/critical-questions columns), not as prose summaries. The plan must specify the structured-artifact format for each foundational lens type, where they live in the vault, and how modes reference them. This is non-trivial and may warrant its own sub-phase.

  5. Pre-routing pipeline architecture — specify the implementation of the four-stage pipeline (filter, sufficiency analyzer, completeness check, execution). Each stage is its own component with its own input/output contract and its own failure-mode handling. The plan must specify:

    • The filter’s signal classifier (vocabulary list, detection logic, default behavior).
    • The sufficiency analyzer’s signal detection (how strong vs. weak signals are distinguished, how multiple signals compose, how conflicts trigger clarification).
    • The completeness checker’s contract validation (how prompts and attachments are matched against expert/accessible contracts, how missing-vs-underspecified is distinguished, how graceful-degradation paths are surfaced).
    • The flow between stages (what each stage passes to the next, how failures are handled, where the user can intervene).

  6. Signal vocabulary registry — the registry specified in Decision 4. The plan must specify:

    • The registry’s location and structure in the vault.
    • The format for vocabulary entries (signal text, mapped territory/mode/disambiguation answer, confidence weight).
    • How the registry is updated when new modes are added.
    • How the prompt sufficiency analyzer queries the registry.

  7. Educational parenthetical convention — Decision 2’s convention needs specification of:

    • The exact format of the parenthetical (placement, italicization, brevity).
    • When the convention applies (auto-dispatch only, or all dispatches).
    • How the parenthetical content is sourced (from mode specification’s description field, or a dedicated short_description field).

Phase 2: Existing Mode Migration

The plan should specify how to translate each of the 25 existing modes into the new template. For each existing mode, the plan should identify:

  • The mode’s home territory per the research report’s gradation tables in §6

  • Its position on the territory’s primary axis (depth/complexity/stance/specificity)

  • Its sibling modes within the territory (existing or gap)

  • Any specification updates required beyond template conformance:

    • Steelman Construction Analysis — re-home to T15 with T1 cross-reference; audit all references to Steelman from other modes (especially Wicked Problems’ composition spec) and update them
    • Wicked Problems Analysis — formalize the composition spec per §6.2 of the research report (which components run full vs. fragment, synthesis stages explicitly named, partial-composition handling specified)
    • Passion Exploration — confirm it does not take ”— Analysis” suffix (correct, since output is generative not analytical); confirm routing recognizes generative-not-analytical signal
    • Project Mode, Structured Output — confirm placement in T21 (Execution), out of analytical routing tree
    • Any other mode whose current specification is partial, inconsistent with the template, or needs re-homing

  • Dual input contract specification for each mode — both expert_mode and accessible_mode contracts must be defined per Decision 3. For modes where the user is unlikely to ever supply expert-mode inputs, the expert_mode contract may be omitted with explicit notation that accessibility-only is the design intent.

  • Signal vocabulary contributions — each mode should have its signal vocabulary entries identified for the registry (Decision 4). What words or phrases in a prompt should map to this mode’s territory, this mode specifically, or its disambiguation answers?

  • Educational short description — each mode should have a one-sentence educational description for the parenthetical convention (Decision 2).

  • Specific action items per mode (rename file? update frontmatter? rewrite section? cross-reference update? signal vocabulary entry?)

Migration order matters because some modes are referenced by others (notably Wicked Problems references six component modes). The plan should sequence migration to handle dependencies correctly.

Phase 3: Cross-Reference Audit

The Steelman re-homing implies that any mode currently referencing Steelman for argument-examination work needs review. The plan should specify a systematic cross-reference audit:

  • Every file in the vault that mentions any existing mode by name
  • Every framework specification that lists modes as components
  • Book outline files that reference the mode taxonomy
  • Any document that references the mode clarification procedure being superseded
  • The CLAUDE.md vault root file
  • Documentation in ~/ora/ directories that mirrors vault content

The audit produces a list of files needing updates and the specific updates needed. This work is mechanical but must be done before the new architecture is announced as live, because broken references would produce confusion.

Phase 4: New Mode Build (Wave-by-Wave)

The research report specifies four waves of new mode builds in §10.2. The plan should specify, for each wave:

Wave 1 (5 modes — atomic, builds on existing patterns):

  • Pre-Mortem Analysis (T6/T7 dual-citizen — note dual-spec format requirement)
  • Stakeholder Mapping Analysis (T8)
  • Differential Diagnosis Analysis (T5)
  • Quick Orientation Analysis (T14)
  • Balanced Critique Analysis (T15)

Wave 2 (7 modes — atomic, requires lens-library expansion):

  • Probabilistic Forecasting Analysis, Multi-Criteria Decision Analysis, Conceptual Engineering Analysis, Frame Comparison Analysis, Boundary Critique Analysis, Interest Mapping Analysis, Propaganda Audit Analysis

Wave 3 (7 modes — atomic with deep traditions):

  • Causal DAG Analysis, Process Tracing Analysis, Fragility/Antifragility Audit, Principled-Negotiation Analysis, Third-Side Analysis, Process Mapping Analysis, Mechanism Understanding Analysis

Wave 4 (5 molecular modes — built last because they depend on components):

  • Decision Architecture Analysis, Bayesian Hypothesis Network Analysis, Wicked-Future Analysis, Worldview Cartography Analysis, Domain Induction Analysis

For each wave, the plan should specify:

  • Process Formalization Framework input requirements per mode (what specification material the framework needs to generate the mode spec)
  • Lens-library entries that must exist before the mode can be built (precondition checks)
  • Dual input contract specification for each new mode (Decision 3) — both expert_mode and accessible_mode versions, plus graceful_degradation specification
  • Signal vocabulary contributions for the registry (Decision 4) — entries to add when this mode is registered
  • Educational short description for the parenthetical convention (Decision 2)
  • Estimated effort per mode
  • Quality gates that determine when the mode is ready for registry inclusion

The plan should explicitly note which modes have dual-citizenship (Pre-Mortem in T6/T7) and how dual-specs are written and maintained. The plan should also note the principle established by Pre-Mortem’s dual-citizenship: dual-citizens are no longer treated as exceptional, and the template should accommodate them as a first-class case.

Phase 5: Lens Library Build

The foundational lenses from §12.1 of the research report must be embedded as structured artifacts. The plan should specify:

  • The order in which foundational lenses are built (dependency-aware — Walton schemes are referenced by many modes and should be early)
  • The structured-artifact format for each lens type
  • Where in the vault each lens lives
  • How modes reference lenses (by ID? by file path? by RAG retrieval?)
  • The mode-specific lenses (§12.2) and which are needed for which Wave
  • The “do not build as a mode, build as a lens” items from §10.1 (SWOT, Pros and Cons, Decision Tree, Brainstorming, Porter’s Five Forces, etc.)

Phase 6: Pre-Routing Pipeline and Routing Implementation

This phase implements the four-stage pre-routing pipeline (Decision 1) and the within-territory and cross-territory disambiguation logic from the research report. Sub-phases:

6a. Pre-analysis filter. Implement the signal-based classifier that distinguishes analytical from non-analytical prompts. Build the analytical-artifact signal vocabulary list. Specify default behavior. Build test corpus of prompts that should and should not pass the filter.

6b. Signal vocabulary registry. Implement the registry per Decision 4. Populate with entries from existing modes (Phase 2 outputs) and Wave 1–4 modes (Phase 4 outputs). Specify update protocol for ongoing maintenance.

6c. Prompt sufficiency analyzer. Implement the analyzer that examines prompts against the disambiguation flow and identifies which questions are answered. Define confidence thresholds (strong vs. weak signal). Define signal composition logic (multiple signals combine to dispatch decisions). Define conflict detection (conflicting signals trigger clarification). Build test corpus.

6d. Within-territory disambiguation trees. Implement the trees per §7 of the research report for each multi-mode territory. The trees are queried only when the sufficiency analyzer determined the within-territory question is not answered.

6e. Cross-territory adjacency disambiguation. Implement the patterns per §8 for top-level routing. The patterns are queried only when the sufficiency analyzer determined the territory question is not answered.

6f. Input completeness check. Implement the checker that validates prompt content (and attachments) against the dispatched mode’s input contract (Decision 3). Specify the response format for missing/underspecified inputs (Phase 1’s extended disambiguation style guide). Specify the graceful-degradation flow (offer to proceed with reduced inputs and lighter sibling mode).

6g. Educational parenthetical convention. Implement the convention per Decision 2. Specify the format and when it applies. Source the parenthetical content from mode specifications.

6h. Routing accuracy testing. Build a routing-test corpus of ~200 prompts spanning all territories, including:

  • Prompts that should bypass the analytical router (filter test)
  • Prompts with strong signals that should auto-dispatch (sufficiency test)
  • Prompts with weak signals that should trigger disambiguation (sufficiency test)
  • Prompts with conflicting signals (sufficiency test)
  • Prompts that should pass routing but fail completeness (completeness test)
  • Prompts with cross-territory ambiguity (cross-territory disambiguation test)
  • Prompts with within-territory ambiguity (within-territory disambiguation test)

Score correctness at each stage. Iterate until >90% accuracy threshold is met at each stage.

Phase 7: Documentation Propagation

After the registry is live with the new architecture:

  • Update Registry — Mode Registry.md with the territory-organized structure and the four-stage pre-routing pipeline
  • Update book outlines (general-audience and technical) where they reference the mode system. The book outlines now need to address the deep-mode-default architecture and the friction-reducer concept; this is substantive content beyond mechanical relabeling
  • Update Reference — Ora Overview and Document Registry.md with the new architectural concepts
  • Update CLAUDE.md if it references modes or routing
  • Update any other working documents that describe the mode system
  • Retire the mode clarification procedure documented yesterday with a note pointing to the new system
  • Synchronize vault and ora copies via existing drift correction machinery

Phase 8: Open Debates Documentation

The research report surfaces eight open debates in §13 (fallacy as argument-property vs. dialogue-property, motte-and-bailey as fallacy vs. doctrine, wicked problems sui generis vs. extreme cases, etc.). The plan should specify how each debate is documented in the affected mode’s specification — not adjudicated, but surfaced as caveat with both sides represented.

Constraints and Discipline

Do not propose to build modes the research report explicitly says not to build. §10.1’s “Modes that should not be built” list (SWOT, Pros and Cons, Decision Tree, Brainstorming) is a discipline constraint. The plan should respect it and not propose to build these as modes. They become lenses if they’re useful.

Do not propose to merge modes the research report says are distinct. The gradation pattern means many modes are siblings within a territory; they’re not redundant just because they’re adjacent. Coherence Audit and Frame Audit are siblings, not duplicates.

Do not propose new modes beyond the Wave 1–4 list without strong justification. The research surfaced ~30 candidate gaps. The plan should respect the research’s prioritization. If you identify a candidate mode that the research missed, flag it as a deferred candidate for future research, not as a Wave 1–4 addition.

Preserve existing operational frameworks. Do not propose changes to operational frameworks (Agent Identity, API Key Acquisition, Browser Setup, MindSpec Library, System File Drift Correction, etc.). These are not analytical modes and are out of scope.

The mode clarification procedure documented yesterday is superseded but must be retired cleanly. Do not delete it; archive it with a clear pointer to the new system, following the existing archival pattern (Old AI Working Files/ style).

Do not revisit the architectural decisions in the “Architectural Decisions Already Made” section. Decisions 1–4 are locked. The plan implements them. If you find tensions between the decisions and the research report, surface the tensions in the “decisions required from the user” section but do not unilaterally resolve them by departing from Decisions 1–4.

Output Format

Produce one file: Working — Analytical Territories and Modes Implementation Plan.md, located at the vault root with the existing Working — prefix convention.

The document should be organized by phase (1 through 8 above), with each phase specifying:

  • Objective — what the phase accomplishes
  • Dependencies — what must be complete before this phase begins
  • Deliverables — concrete files, specifications, or artifacts produced
  • Sequence — ordered list of work items within the phase
  • Success criteria — how completion is verified
  • Risk assessment — what could go wrong and mitigation
  • Estimated effort — rough sizing (hours/days/weeks)
  • Execution style per work item — for each work item, specify whether it is suitable for automated execution by Claude Code, supervised execution with user review at checkpoints, or manual review required before proceeding. This helps the user allocate attention efficiently when execution begins.

Include a top-level summary table of phases, dependencies, and total effort estimate.

Include an explicit section on decisions required from the user before implementation begins — for any architectural questions the planning surfaces that are not covered by Decisions 1–4. Do not assume the user’s preferred answer to these questions; surface them for explicit confirmation.

Include a risks and unknowns section at the document level for cross-cutting concerns the phase-by-phase organization doesn’t capture.

Include a scope boundary section that explicitly notes what is out of scope for the implementation (e.g., the long-tail of analytical operations beyond Wave 1–4, the contextual-routing aspiration mentioned in earlier discussion as deferred future work, any features the user might want but are not part of this implementation).

Discipline on Scope

You may surface concerns, identify gaps in the research report, and recommend amendments to the build sequence. You may not unilaterally expand scope, propose to build modes not in the research report’s roadmap, or restructure the architecture documented in the research report or the architectural decisions in this prompt.

If you encounter ambiguity in the research report, document it in the “decisions required” section of the plan rather than resolving it yourself.

If you encounter a contradiction between the research report and an existing vault document, document the contradiction and propose a resolution for user confirmation.

If you encounter a tension between the architectural decisions (1–4) and the research report or existing vault content, document it clearly. Do not resolve by departing from Decisions 1–4.

If you discover that a piece of vault content the plan needs (e.g., the mode clarification procedure, a specific framework specification) cannot be located, document the search performed and the conclusion in the “risks and unknowns” section.

What “Done” Looks Like

The plan is complete when it specifies, in sufficient detail for another instance of Claude (or you in a fresh thread) to execute, every step required to migrate the mode registry from its current state to the architecture documented in the research report and Decisions 1–4. A reader of the plan should be able to start at Phase 1, execute through Phase 8, and arrive at a complete, working, registered analytical-mode system without needing to re-derive any architectural decisions.

The plan should make clear which work is mechanical (Claude Code can execute autonomously), which is supervised (Claude Code executes with user review at checkpoints), and which requires user judgment (user reviews and approves before proceeding). This per-work-item execution-style designation is required, not optional.

Begin by reading the listed source documents. Then produce the plan.