Frameworks Deep Dive
Detailed reference for all framework fields, six structure types, and advanced configuration.
Complete reference for every field in the framework wizard. If you haven't created a framework yet, start with Getting Started with Frameworks, which walks through the wizard end-to-end in five minutes.
This guide uses the Build vs. Buy Software Decision framework as an example.
Before you start
You need a Course before you can create a Framework. Navigate to your course → Frameworks tab → Add Framework. The wizard has seven sections: Basics → Relationships → Inputs & Outputs → Logic Structure → Advanced → Summary & Save → Sync.
Basics
Name
A clear, specific name. The framework is referenced by this name in Thinking Path steps, assistant responses, and the framework library.
Good names:
- "Build vs. Buy Software Decision"
- "Porter's Five Forces Industry Analysis"
- "NPV Break-Even Calculation"
Avoid generic names like "Decision Framework". They don't tell the assistant what the framework does.
In our example: Build vs. Buy Software Decision
Purpose
One sentence that completes: "Use this framework when you need to…"
Assistants scan the Purpose of every synced framework to decide which one to apply when a learner asks a question. Vague purposes lead to wrong routing.
Strong: Decide whether to build a custom software solution internally or purchase an existing product, based on strategic fit, cost, and internal capability.
Weak: For software decisions.
Quantitative Nature
| Option | Meaning |
|---|---|
| Quantitative | The framework works with numbers: ratios, scores, dollar figures, calculations |
| Qualitative | The framework works with judgment, categories, and text only |
| Mixed | Some inputs are numbers, some are judgment-based |
This changes how the assistant interprets learner responses and what it asks for.
In our example: Mixed. We ask for a numeric cost estimate and a yes/no capability judgment.
Requirements Type
How central this framework is to your course.
| Option | Meaning |
|---|---|
| Core | Taught explicitly and assessed. Learners must master it. |
| Required | Important and used frequently, but not the central exam topic. |
| Optional | Supplemental. Learners who go deeper will benefit from it. |
In our example: Core
Sections
Optionally link this framework to one or more sections of your course. Used for filtering and organisation in the framework library.
Relationships
Link this framework to others in your library.
| Relationship | Meaning |
|---|---|
| Child framework | A smaller framework this one uses as a component |
| Parent framework | A larger framework that uses this one as a component |
| Alternative framework | A framework that could be used instead in similar situations |
In our example:
- Child: "Cost-Benefit Analysis", used inside Build vs. Buy to evaluate the financial case
- Alternative: "Lease vs. Buy", used when the comparison involves physical assets rather than software
Inputs & Outputs
Inputs
Inputs are the pieces of information the framework needs to function. Click Add Input for each one.
Each input has four fields:
| Field | Description |
|---|---|
| Name | What this input is called. Be specific: "Net Income" not "Income". |
| Type | The data type (see below) |
| Ask Strategy | How the assistant handles this input (see below) |
| Description | What this input means in context. The assistant reads this to know what it is asking for. Be precise. |
Input types:
| Type | Use when | Example |
|---|---|---|
| Boolean | The input is yes or no | "Does the team have internal build capability?" |
| Numeric | The input is a number | "What is the estimated build cost?" |
| Categorical | The input is one of several defined options | "What is the primary driver: cost, speed, or control?" |
| Text | The input is a free-form description | "Describe the problem this software must solve." |
Ask strategies:
| Strategy | What the assistant does | Use when |
|---|---|---|
| Required | Always asks the learner before proceeding | The input is essential and cannot be assumed |
| Optional | Asks only if clearly relevant from context | Useful but not always needed |
| Infer | Tries to derive it from what the learner has already said. Only asks if inference fails. | Can usually be picked up from prior context |
In our example:
| Name | Type | Ask Strategy | Description |
|---|---|---|---|
| Internal Build Capability | Boolean | Required | Does the team have the technical skills and bandwidth to build and maintain this solution internally? Answer Yes or No. |
| Estimated Build Cost | Numeric | Required | Total projected cost to build, including development, testing, and first-year maintenance. Expressed in the team's reporting currency. |
Outputs
Outputs describe what the framework produces. Click Add Output for each one.
Each output has two fields: Name and Description.
Be specific. The assistant checks completed work against this description. A vague output means the assistant cannot tell when the analysis is done.
Strong description: A recommendation (Build or Buy) with a one-paragraph justification covering internal capability, estimated cost, and strategic fit.
Weak description: A software decision.
In our example:
| Name | Description |
|---|---|
| Software Decision | A recommendation (Build or Buy) with a one-paragraph justification covering internal capability, estimated cost, and strategic fit. |
Logic Structure
Structure Type
Choose the shape of your logic. This tells SLAN how to interpret the logic you build and how the assistant guides the learner through it.
| Structure Type | When to use it | Example |
|---|---|---|
| Linear Steps | The analysis follows a fixed sequence. Each step must be completed before the next. Skipping a step would produce an invalid result. | Calculating a financial ratio step by step |
| Decision Tree | The path changes based on the learner's answers. Different situations lead to different branches. | Choosing a market entry mode based on risk and control |
| Causal Chain | You're tracing causes and effects: why something is happening, or what consequences will follow. | Diagnosing why gross margin declined |
| Formula / Numerical Evaluation | Multiple options are scored across weighted criteria. Produces a ranked recommendation. | Vendor selection across price, quality, and delivery |
| Evaluation Matrix | A grid comparison of options across dimensions. No numeric weights required; useful when qualitative differences matter as much as numbers. | Comparing strategic alternatives side by side |
| Diagnosis Checklist | A set of conditions to verify before proceeding. Pass/fail logic. Used as a gate, not a decision. | Pre-launch readiness check |
In our example: Decision Tree. The right recommendation depends on whether the team has internal build capability and whether the cost fits the budget.
Click Load Example to see a pre-filled example for your chosen structure type. Adapt it, or delete it and build from scratch. Switch between Edit, Visual, and XML views as you work.
Logic Structure by structure type
Linear Steps
A fixed, ordered sequence. The learner completes each step before moving to the next.
The builder shows numbered steps. Each step has a name and an optional description. Click Add Step to add more.
In our example (as Linear Steps):
| Step | Name | Description |
|---|---|---|
| 1 | Define the problem | Articulate the specific problem the software needs to solve and the success criteria for a good solution. |
| 2 | Assess internal capability | Determine whether the team has the technical skills and bandwidth to build and maintain this internally. |
| 3 | Estimate the build cost | Calculate the total projected cost to build: development, testing, and first-year maintenance. |
| 4 | Research available products | Identify existing products that solve the problem and compare their cost, fit, and limitations. |
| 5 | Compare build vs. buy | Evaluate both options across cost, strategic fit, time to value, and long-term flexibility. |
| 6 | Make a recommendation | State clearly: Build or Buy. Justify the choice with reference to capability, cost, and strategic fit. |
Decision Tree
An if/then/else structure. The path changes based on the learner's answers at each decision point.
The builder shows a root question with branches. Each branch has a condition, action, and optional explanation. Click Add Branch to extend the tree. Use the Visual tab to see the full diagram.
In our example:
Causal Chain
A chain of cause-and-effect relationships. Used to trace why something is happening or project downstream consequences.
The builder shows cause → effect links. Each link has a cause, effect, and optional description. Click Add Link to extend the chain.
Example:
| Cause | Effect |
|---|---|
| Underinvestment in sales training | Lower conversion rates |
| Lower conversion rates | Declining revenue |
| Declining revenue | Pressure to cut costs |
| Cost cuts | Further underinvestment in training |
Formula / Numerical Evaluation
Multiple options are scored across weighted criteria. The framework produces a ranked recommendation.
The builder shows criteria with weights. Click Add Step to add each criterion.
Example (vendor selection):
| Criterion | Weight |
|---|---|
| Cost | 40% |
| Implementation speed | 30% |
| Long-term support quality | 30% |
Each option is scored 1–5 per criterion. Weighted scores are summed to produce a ranking.
Evaluation Matrix
A grid comparison of options across dimensions. No numeric weights; qualitative differences are visible in each cell.
The builder shows an editable table. Click Add Row to add an option. Click Add Column to add a dimension.
In our example:
| Build | Buy (Off-the-shelf) | Buy (SaaS) | |
|---|---|---|---|
| Strategic fit | High, fully customisable | Medium, may require workarounds | Low, limited customisation |
| Upfront cost | High | Medium | Low |
| Time to deploy | 12–18 months | 3–6 months | 2–4 weeks |
| Long-term flexibility | High | Low | Medium |
| Maintenance burden | High (internal team) | Low | Low |
Diagnosis Checklist
A set of conditions to verify before proceeding. Each item is either required or optional.
The builder shows checklist items. Click Add Step to add each one.
Example (pre-build readiness):
| Item | Required? |
|---|---|
| Problem statement is clearly defined | Required |
| Internal build capability confirmed | Required |
| Budget approved and allocated | Required |
| Success criteria agreed by stakeholders | Required |
| Security and compliance requirements documented | Required |
| Maintenance plan in place | Optional |
Advanced
Optional fields that improve how reliably the assistant routes to and applies the framework. Fill them in once your core fields work.
When to Use
The conditions under which this framework is the right choice. The assistant uses this when routing between multiple frameworks.
In our example: Use when a team is deciding whether to build a custom software tool internally or purchase an existing product, before committing budget or development resources.
Invalid When
When this framework should NOT be used. Prevents the assistant from misapplying it.
In our example: Do not use when the decision has already been made and the team is looking for implementation guidance. Do not use for hardware or infrastructure procurement decisions.
Prerequisites and Assumptions
What must be true before this framework can be applied correctly.
In our example: Requires a defined budget range. Requires a clear statement of the problem the software must solve. Assumes the decision-maker has authority to commit resources.
Introductory Hook
A single sentence the assistant says to engage the learner before applying the framework. Connects the abstract logic to their concrete situation.
In our example: Before we work through this decision, what's your instinct, and what's making you uncertain?
Allowed Adaptations
Which parts of the framework the assistant can legitimately adjust to context, and which are fixed.
In our example: The criteria used in the comparison can be adjusted for the specific decision context. The recommendation must still be clearly Build or Buy. No "it depends" without a final recommendation.
Next Steps
What the learner should do after completing this framework.
In our example: If Build: proceed to project scoping and resource planning. If Buy: proceed to vendor evaluation and procurement.
Tags
Free-form labels for search and filtering in the framework library.
In our example: software, technology, decision-making, procurement
Summary
Review your framework before saving. Check that:
- Name and Purpose are correct
- Inputs and Outputs are listed as expected
- Logic Structure shows the right number of steps, branches, or rows
Click Save. Your framework is saved to the course.
Sync
After saving, you must sync before assistants can use the framework. See Getting Started → Sync for the steps.
Next steps
- Connect to a Thinking Path or create a Nudge: Use a Framework
- Edit or delete: Update a Framework