STEP 1: Generate the BRAID
→ The model creates a Mermaid diagram with the logical steps of the solution

STEP 2: Solve using the diagram  
→ The model (the same one or another) uses the diagram as an instruction
→ Generates the final answer, following the graph structure

In the study: two separate API requests (generator + solver)
Manually in a chat: can be done in one prompt or in two messages

Task: You're launching an online school and want to build a one-year financial model. You need to account for student acquisition cost, lead-to-purchase conversion, average order value, instructor costs (a percentage of revenue), marketing spend (a fixed monthly amount), and overhead. It's a multi-step task where it's easy to get confused or leave something out.

Prompt:

Create a Mermaid diagram for calculating an online school's profit for the year.

Inputs:
- Ad budget: $15,000/month
- Cost per lead: $25
- Lead → purchase conversion: 5%
- Average course price: $500
- Instructor pay: 40% of revenue
- Overhead: $2,000/month

The diagram should show the sequence of steps: 
how many leads we get → how many buy → revenue → 
instructor costs → net profit.

After the diagram, solve the task by following the graph structure.

Result:

The model will generate a graph like:

Ad budget → Number of leads → Number of students → 
Revenue → Instructor costs → Operating expenses → Profit

Then it will walk through each node of the graph, plug in the numbers, and output: leads per month (600), students (30), revenue ($15,000), instructor costs ($6,000), and the final profit after all deductions.

The graph structure ensures the model doesn't skip a step (for example, forgetting to subtract overhead) and doesn't get the order of calculations mixed up. All calculations follow the diagram's nodes strictly, with no reasoning drift.

The weakness: Text reasoning (CoT) generates lots of low-density tokens. The model describes every step: "First, let's take the $15,000 budget, then divide it by the $25 cost per lead to get the number of leads..." and those extra words cost money. On top of that comes reasoning drift: the model veers into explanations, repetition, and irrelevant details. This is especially true of expensive models with high reasoning effort: they produce detailed traces, but accuracy doesn't grow in proportion to length.

The strength: LLMs are excellent at following structured instructions, especially when they're encoded formally. Models were trained on code, diagrams, and formulas, so they parse graphs, pseudocode, and diagrams well. Symbolic notation removes the ambiguity of natural language.

How BRAID works: It replaces text reasoning with a compact graph of logical steps. Instead of 500 tokens of description, the model sees a 10-node diagram. Each node is an action or calculation, each edge a connection. The model moves through the graph deterministically, without wandering. The structure bounds the reasoning path and eliminates drift. The result: high semantic density per token, lower costs, higher accuracy.

Control levers:

• Graph detail: Few nodes (3-5) for simple tasks → token savings. Many nodes (10-20) for complex ones → every step is transparent.

• Diagram format: A Mermaid flowchart (as in the study), a mindmap, or just a list of steps with arrows. What matters is that the structure is visible.

• Generated vs hand-made diagram: You can ask the LLM to create the diagram (flexibility), or write it yourself once and reuse it (control for recurring tasks).

• One request vs two: You can generate the diagram and solve in one prompt ("first draw the graph, then solve"), or split it into two messages for more clarity.

Option 1: One request (generation + solution)

Task: {task description}

Step 1: Create a Mermaid diagram (flowchart) with the logical steps of the solution. 
Each node is one action or calculation. Show the connections between steps.

Step 2: Solve the task by following the structure of the diagram. 
For each node in the graph, perform the calculation or logical step.

Inputs:
{list the input data for the task}

What to fill in: - {task description} — what needs to be calculated or solved - {inputs} — numbers, conditions, parameters

Option 2: Two requests (diagram first, then solution)

Request 1 — generate the diagram:

Create a Mermaid diagram (flowchart) for solving this task:

{task description}

The diagram should show the sequence of logical steps 
from the input data to the final answer. Each node is one action.

Request 2 — solve using the diagram:

Here is a diagram of the solution logic:

{paste the diagram from the previous answer}

Solve the task by following this structure. For each node of the diagram, 
perform the corresponding step.

Inputs:
{input data}

🚀 Quick start — paste into the chat:

Here is a BRAID template for structured reasoning. 
Adapt it to my task: {describe your task}. 
Ask me questions to figure out which steps the diagram needs.

[paste Option 1 or Option 2 above]

The LLM will ask: what the inputs are, what final result you need, which intermediate calculations matter. It will take the Mermaid diagram pattern and build a graph for your task. Then it will solve it by following the graph's nodes.

The study used two separate API calls: the generator creates the diagram, the solver works from it. That's not a bug, it's a feature.

Splitting gives you: 1. Reusable diagrams: Create the diagram once → apply it to different data. For example, the online school's financial model: build the diagram once, swap in new numbers every month. 2. Control over structure: You can hand-edit the generated diagram before solving if the model missed something. 3. Caching in production: If you're a developer or work through the API, store the diagrams and reuse them over and over, paying only for the solver.

For a one-off task, use one request. For recurring or critical ones, use two.

⚠️ Learning curve for beginners: You need to understand Mermaid diagram syntax (flowchart, nodes, edges). If you don't, you'll have to trust the LLM to generate the right structure. The model may skip steps or make the graph too abstract.

⚠️ Not for every task: BRAID is good for logical chains, calculations, step-by-step processes. For creative tasks (write a story, brainstorm ideas) or subjective ones (judge the tone of a text), a structured graph is overkill; free-form reasoning works better there.

⚠️ Amortization in production vs one-off use: BRAID's main economic payoff comes when a diagram is created once and reused millions of times (via the API with caching). If you generate a new diagram for every unique task in a chat, you pay for two requests instead of one, and the token savings may not cover the double call.

⚠️ Math with masking: For the GSM-Hard benchmark, the study used a trick: all numbers in the diagram were replaced with ~~ placeholders so the solver couldn't just copy the answer and had to actually calculate. Real tasks don't need this, but it shows that if a graph contains ready-made numbers, the model may "cheat" and skip the logic.

The team used three benchmarks: GSM-Hard (math problems), SCALE MultiChallenge (complex multi-step reasoning), and AdvancedIF (following instructions in text). They tested 272 SCALE questions and 100 questions each from GSM-Hard and AdvancedIF. Every task was run through combinations of GPT models: one model generated the Mermaid diagram (generator), another (or the same one) solved the task from the diagram (solver). This produced a matrix of configurations, for example an expensive model generates the diagram and a cheap one solves, or vice versa.

What they measured: accuracy (%), cost in cents per request (input/output tokens × price), and most importantly Performance-per-Dollar (PPD), i.e. how much accuracy you get per dollar. PPD was normalized against the baseline model gpt-5-medium: if PPD > 1, the configuration is more efficient; if < 1, it's more expensive or worse. This allowed a fair comparison of small and large models: not just "who's more accurate" but "who's the better deal".

Control group: Classic zero-shot prompting: models without BRAID and without explicit Chain-of-Thought triggers (like "think step by step"). For models with intrinsic reasoning (GPT-5 thinking models) this is fair: they already "think" internally, and adding CoT on top would be cheating. They compared plain work vs a structured diagram.

A neat trick: For math (GSM-Hard) they used Numerical Masking, replacing all numbers in the diagram with ~~ so the solver couldn't copy intermediate results from the graph and had to actually compute each step. This showed that BRAID provides not "a hint with the answer" but a reasoning structure.

The results were surprising: Small, cheap models with BRAID beat large, expensive models without it. gpt-5-nano-minimal (the cheapest) with a diagram reached 45.2% on SCALE, beating the heavier gpt-5-minimal without a diagram (40.4%). On math, almost every model rose from 93-95% to 97-99% accuracy. The key insight: structure matters more than model size. A compact graph for a small model is more effective than text reasoning for a big one.

The economics: The researchers calculated two cost scenarios: 1. Solving-Only Cost — if the diagram is created once and reused (in production via caching). Then you pay only for the solver. 2. Amortized Cost — if you generate the diagram each time but use it N times. Then the generation cost is spread out.

In production (N → large), BRAID makes inference dramatically cheaper. For one-off tasks the gain is smaller, but it's still there thanks to the compact tokens.

The study doesn't provide a verbatim prompt template: the authors describe the architecture (generator + solver) but don't publish the exact prompt text. Instead they show a conceptual example of a Mermaid diagram:

flowchart TD
    Start[Input data] --> Step1[Step 1: calculate A]
    Step1 --> Step2[Step 2: calculate B]
    Step2 --> Step3[Step 3: combine A and B]
    Step3 --> End[Final answer]

Context from the paper: The generator model receives the question and creates a diagram like this. The solver model uses the diagram as a system message (via the API) and generates the final answer by following the graph's nodes. The paper notes: "BRAID introduces a bounded reasoning framework using Mermaid-based instruction graphs that enable models to reason structurally rather than through unbounded natural-language token expansion."

For math problems (GSM-Hard) they used masking:

flowchart TD
    Start[Budget: ~~] --> Leads[Leads: ~~]
    Leads --> Students[Students: ~~]
    Students --> Revenue[Revenue: ~~]
    Revenue --> Profit[Profit: ~~]

The solver sees the structure but not the numbers, so it has to compute them itself.

💡 Adaptation for text tasks without calculations

The original study focused on logical chains and math, but the principle works for any step-by-step process. For example, writing an analytical article:

Create a Mermaid diagram for writing a breakdown of a marketing campaign.

Structure:
Target audience analysis → Creative assessment → 
Performance metrics analysis → Conclusions → Recommendations

After the diagram, write the article following this logic.

Campaign data:
- Product: an online Python course
- Platforms: Instagram, YouTube Ads
- Budget: $15,000
- Result: 120 purchases, CPA $125

The diagram locks in the order of sections. The model won't jump between topics; it will go strictly node by node: audience first, then creative, then metrics, then conclusions. The text comes out structured without extra instructions like "first talk about..., then about...".

🔧 Technique: A graph of questions instead of a graph of actions

The original BRAID uses a graph of solution steps. But you can adapt it into a graph of clarifying questions for complex, open-ended tasks.

Example: You need to pick a niche for a new business, but there are lots of criteria and it's unclear where to start.

Create a Mermaid diagram of questions for choosing a business niche.

Start with the question "What experience do I have?" → 
branch into "Do I have an audience?" and "How much am I willing to invest?" → 
for each branch, ask clarifying questions → 
the final nodes are niche types for each profile.

After the diagram, ask me these questions in order and help me choose.

The model will create a decision tree as a graph. You move along the branches, answering questions. This gives the choice process structure: not a chaotic "let's think about it" but a clear path from the root to the leaves.

💡 Combo: BRAID + Self-Consistency

The original study compares BRAID with Self-Consistency (SC), a technique where you generate several CoT traces and pick the answer by majority vote. SC is more accurate but more expensive (several requests).

Hybrid approach: Create one BRAID diagram, but ask the model to solve the task from the diagram in three different ways (for example, by changing numeric priorities or how nodes are interpreted). Then compare the three solutions.

Here is a Mermaid diagram of the solution logic:

{diagram}

Solve the task using this structure **in three ways**:
1. Optimistic scenario (maximum values at the forks)
2. Pessimistic scenario (minimum values)
3. Realistic scenario (average values)

For each scenario, go through all the nodes of the diagram and give the final answer.
Then compare the three answers and show the range of possible outcomes.

You get bounded multi-path reasoning: one structure (the graph), but different interpretations. It's cheaper than three full CoT runs (where each trace generates its own logic), but more flexible than a single BRAID (you see the spread of answers).

BRAID: Bounded Reasoning for Autonomous Inference and Decisions — Armağan Amcalar (OpenServ Labs), Eyup Cinar (Eskisehir Osmangazi University). All datasets and detailed result logs are available at https://benchmark.openserv.ai.

The study cites key prompting papers: - Chain-of-Thought Prompting (Wei et al., 2022) — the basic step-by-step reasoning technique - Zero-Shot CoT (Kojima et al., 2022) — "Let's think step by step" - Self-Consistency (Wang et al., 2022) — voting across multiple CoT runs - Least-to-Most Prompting (Zhou et al., 2022) — decomposition into subtasks - Plan-and-Solve (Wang et al., 2023) — a planning phase + an execution phase - Tree of Thoughts (Yao et al., 2023) — tree-shaped exploration of reasoning paths - Program-of-Thought (Chen et al., 2023) — replacing text with code