Thinking Paths Reference

This guide covers every path-level field, the graph view, and runtime behavior. For step-level fields (instructions, checklists, frameworks), see Steps Reference.

All examples use the Software Decision Walkthrough, a guided workflow that takes a learner from defining a technology problem to a documented Build vs. Buy recommendation.

How a Thinking Path runs

When a learner opens a Nudge powered by a Thinking Path, the assistant follows this sequence:

At each step, the assistant presents instructions, coaches the learner, and checks the step's checklist before advancing. At the final step, it also checks the learner's work against the Final Output definition.

Throughout the workflow, the assistant enforces Rules from the Guardrails tab and runs through Reasoning Questions before each response.

The relationship between Path, Step, and Framework

A Framework encodes reusable decision logic ("how to evaluate a build vs. buy decision"). A Step invokes that framework in a specific context ("at this point, apply Build vs. Buy to the learner's situation"). A Thinking Path sequences steps into a complete workflow ("from problem definition to recommendation").

Overview tab

Name

A clear name that communicates the analytical goal, not the topic.

Good: "Software Decision Walkthrough", "Market Entry Decision Analysis", "Root Cause Diagnosis"

Avoid: "Strategy", "Analysis 1", or anything that doesn't tell a colleague what the workflow produces.

Example: Software Decision Walkthrough

Purpose

A precise statement of what the learner will have produced by completing the path. The assistant returns to this whenever the learner goes off-track. It also drives routing: when a learner says "I want to analyse my options," the assistant matches their goal against path purposes.

Strong: Guide a learner through the full Build vs. Buy analysis, from defining the problem to producing a documented recommendation with justification.

Weak: Help learners analyse software decisions.

The strong version names the starting point, ending point, and deliverable. The weak version describes a topic.

Examples

Optional. One or two example interactions showing how the assistant should handle realistic learner messages, especially edge cases: a learner trying to skip ahead, giving vague input, or asking for the answer outright.

These function as few-shot examples. Even one or two shape the assistant's tone, pacing, and decision-making in measurable ways.

Entry Step

The first step the assistant starts with. Set this after creating your steps. It appears as a dropdown once steps exist.

The entry step has no parent steps. Every other step in the graph flows from it. A path with no entry step set will not run.

Guardrails tab

Rules

Rules are constraints the assistant enforces throughout the entire path, regardless of which step the learner is on. Click Add Rule to add each one. Click Load Example to see a pre-filled set.

Put these in Rules:

• Things the assistant must always or never do
• Scope boundaries
• Sequencing constraints ("do not advance to the recommendation until...")
• Input quality requirements ("do not accept vague inputs")

Do not put these in Rules:

• Step-specific guidance (belongs in the step's Instructions)
• Tutoring style preferences (belongs in Tutoring Approach)
• Output format requirements (belongs in Final Output)

Example:

• Rule 1: Do not move to the recommendation step until the learner has evaluated both the build cost and the buy cost.
• Rule 2: Do not accept vague problem definitions. If the learner says "we need better software," ask them to specify what problem the software must solve and what success looks like.
• Rule 3: End every message with one question that moves the learner forward. Do not ask multiple questions at once.

Reasoning Questions

Internal prompts the assistant processes before each response. These are not asked to the learner. They function as a pre-response checklist.

Click Add Question to add each one.

When you add Has the learner addressed all three cost categories?, the assistant verifies coverage before giving feedback, rather than accepting a partial answer. When you add Am I about to give the answer, or am I guiding the learner to reason toward it?, the assistant catches itself before doing the learner's thinking.

Example:

• What step is the learner currently on, and what are they being asked to produce?
• Has the learner provided enough input to move forward, or is something missing?
• Am I about to give the answer, or am I guiding the learner to reason toward it?
• Am I about to ask more than one question? If so, reduce to one.

Final Output tab

The definition of "done" at the path level. Describe what a complete, high-quality deliverable looks like.

The assistant uses this in two ways: it orients the learner throughout the path (every step builds toward this), and it checks whether the work is complete at the end.

Include:

• The structure of the final output (sections, headings)
• Content expectations for each section
• Quality markers
• Which steps produce which sections

Strong: a concrete description with named sections and quality expectations.

Weak: A software decision.

Example:

A Build vs. Buy recommendation document containing:

1. Problem Statement: a clear description of the problem the software must solve, with success criteria and constraints.
2. Evaluation: an assessment of internal build capability, an estimated build cost (including development, testing, and first-year maintenance), and at least one buy option with a cost estimate.
3. Recommendation: a clear statement (Build or Buy) with a one-paragraph justification covering internal capability, estimated cost, and strategic fit.

Every section of the Final Output should trace back to at least one step. If a section has no corresponding step, learners will produce incomplete work for that section.

Tutoring Approach tab

Your teaching philosophy encoded into the assistant's behavior. A path without a tutoring approach produces an assistant that lectures in one message, interrogates in the next, and gives away the answer in a third. Defining the approach creates consistency.

Click Load Example to see a pre-filled set.

Define these areas:

Voice and tone: How does the assistant sound?

Clear, calm, and direct. Professional without being stiff. Aim for guide energy over lecturer energy.

Motivation style: How does the assistant handle progress and setbacks?

Reinforce progress in one sentence ("Good, we have enough to move to evaluation."). Normalize iteration ("We'll refine this after the first draft."). Skip pep-talk energy.

Interaction principles: Behavioral rules for the coaching style.

1. Progress over perfection: move the learner one step forward.
2. One thread at a time: handle the most important thing first.
3. Teach while doing: explain reasoning in one or two sentences, tied to the learner's goal. Skip long theory dumps.

Handling ambiguity: What does the assistant do with unclear input?

If ambiguous: offer two plausible interpretations and ask the learner to choose. If uncertain about a fact: name the uncertainty, then ask for the missing input.

Click Create Path to save.

Path-level design patterns

Map before you build. Sketch the stages on paper first. Identify decision points, common blockers, and branching logic before opening the editor.

Invest in Tutoring Approach. Paths with a defined tutoring approach produce assistants that coach. Paths without one produce assistants that check boxes.

Test your path. Walk through the workflow as a learner after deploying. You'll spot missing instructions, unclear transitions, and steps that need more framework support within the first run.

Path-level common mistakes

Final Output that doesn't match the steps. If the Final Output has a "Decision" section but no step covers the decision, learners produce incomplete outputs.

Everything in Rules instead of step Instructions. Rules are global constraints. If a rule applies at only one step, move it to that step's instructions.

Tutoring Approach left blank. The assistant defaults to generic behavior. Professors report the biggest quality difference between paths with and without a defined tutoring approach.

Too many steps. Paths with 15+ steps are exhausting to build and to use. Break complex analyses into multiple paths, or combine steps that are sequential.

The graph view

After creating steps, each appears as a node on the canvas and in the sidebar.

Connecting steps

Drag from one step's connection handle to another to create a connection. Click a connection line to delete it. Use Auto-layout in the toolbar to reposition nodes.

Setting the Entry Step

Open the path's Overview tab and select the first step from the Entry Step dropdown. The entry step displays a green ENTRY badge.

Path shapes

Linear: each step has one parent and one child.

Branching: a step routes to different children based on conditions.

Converging: multiple steps feed into one.

Orphan steps

The toolbar's Only reachable toggle highlights steps not connected to the graph. The assistant will never reach an orphan step, so any disconnected node is dead weight.

Deploy

To make the path available to learners, attach it to a Nudge assistant. See Use a Thinking Path for the full walkthrough.

Next

For step-level fields (instructions, checklists, frameworks), see Steps Reference.