The Prompt Braid
Split one prompt-batch into declared branches, run each under budget, fold the branches back under a stated merge policy — and prove the braid round-trips.
The ingredients 4 gifts
Pick your depth — take the quick way in, the full walk-through, or the deep build. Same recipe, your call today.
Quick you're new to this and want a real foothold, not the whole cliff
This is a hard one — a multi-hundred-line subsystem when built for real. But the CORE idea fits in your head, and you can run the smallest true version today. Don't let the double-black scare you off; start here.
The whole thing is one move done carefully: SPLIT one prompt into named branches, run each, then FOLD them back together — under a rule you decided BEFORE seeing the answers. Do it with just two branches first. If your two-branch split can be folded back and you can prove every branch you sent out came home, you understand the braid. Everything else is scale.
What you'll want to learn next, in order: what a 'merge policy' is (how you combine two answers — vote? pick the more confident? stitch both with labels?), then how to cap each branch so a runaway can't hang the batch (that's weir), then how to prove the split and fold match (the round-trip assertion). Take them one at a time.
# SPLIT: one question into two named branches you declared up front.
branches = fanout(question, into=["terse", "cited"]) # a closed, named set
# RUN each branch (your model call goes here).
answers = {name: run(prompt) for name, prompt in branches}
# FOLD: combine under a policy you decided BEFORE seeing the answers.
def merge(a): # <- this rule is the whole intellectual weight
return f"{a['terse']}\n\n(supporting: {a['cited']})"
result = junction(answers, policy=merge)
# PROVE the braid round-trips: every label sent out came home.
assert set(branches) == set(answers), "a branch got lost — the braid is broken"Working you want to understand the braid
The five parts below walk it: template expands one base prompt into variants, fanout splits into a closed named set, weir runs each under a hard budget, junction folds them back under a declared merge policy.
The load-bearing invariant is the round-trip: every label fanout emits is one junction is prepared to receive, and the merge policy is fixed BEFORE any branch runs — not chosen after seeing the answers. That's what makes the braid provable instead of hoped-for.
Deep you want the ⊗ structure and where it bites
The ⊗ (parallel-compose) here is real and it carries a coherence obligation — that's what earns the symbol: because branches run independently, re-ordering them must not change the result (trivial braiding), and a label collision at the fold is a genuine failure, not a warning. You can assert fanout's label set EQUALS junction's expected set as a test, before running a single prompt.
weir's budget is per-branch and hard, so the braid degrades gracefully: a branch that blows its wall-time is cut and MARKED cut, and the merge policy decides what a missing branch means (drop it, fail the batch, substitute a default) — declared, not improvised.
The honest edge is the one that bites: junction executes your merge rule faithfully; it does NOT know whether your rule is wise. A majority vote across three branches that share a blind spot produces a confident wrong answer, cleanly folded. A branch that finishes cheaply with garbage passes weir's budget and enters the fold. The braid's guarantee is structural — what split can be provably reassembled, every contribution labeled and auditable. Whether the combined answer is GOOD is a question about your merge policy and your branches; the braid makes that question legible, it doesn't answer it.
The idea
You want to run one question down several parallel tracks — different models, different framings, different budgets — and then combine the answers into one, without losing track of which branch said what. fanout splits one payload into a fixed, declared, closed set of named branches. junction folds those labeled branches back into one under a declared merge policy. weir runs each branch's prompt-pipeline under a hard budget — max rows, max wall-time, max bytes — so a runaway branch can't sink the batch. template fills each branch's {{slots}} from a record, so one base prompt becomes many concrete variants. The braid is the whole point: fanout and junction are one pair — the split is only correct if the fold can put it back together under a policy you named up front.
The parts + how they wire
One base prompt plus a data record enters template, which expands it into concrete variants → fanout splits the batch into a closed, named set of branches (one labeled JSONL record per branch: 'terse', 'adversarial', 'cited', whatever you declared) → each branch runs its pipeline under weir, which enforces the per-branch budget and weirs off anything that exceeds it, so every branch either finishes within bounds or is cleanly cut → junction folds the surviving labeled branches back into one output under the declared merge policy. The load-bearing invariant is the round-trip: every label fanout emitted is a label junction is prepared to receive, and the merge policy is declared before any branch runs — not chosen after seeing the answers.
The one piece you build
A substantial system: the branch declaration, the per-branch budgets, and — the hard part — the merge policy that makes junction's fold meaningful. Deciding HOW to combine N parallel answers is the whole intellectual weight: majority vote? highest-confidence? concatenate-with-attribution? a scoring rubric? You build the branch spec, wire template/fanout/weir/junction to it, and write the merge policy as declared code that junction executes. This is the project, not glue around it.
The technical breakdown
The ⊗ (parallel-compose) structure is real here, and it carries a coherence obligation, which is the only thing that earns the word: because the branches run independently, re-ordering or re-bracketing them must not change the result (the braiding must be trivial), and a label collision at the fold is a genuine failure, not a warning. fanout's set is closed and declared — it cannot emit a branch junction doesn't know about — which is what makes the round-trip provable rather than hoped-for: you can assert that fanout's label set equals junction's expected label set as a test, before running a single prompt. weir's budget is per-branch and hard, so the braid degrades gracefully: a branch that blows its wall-time budget is cut and marked cut, and junction's merge policy decides what a missing branch means (drop it, fail the batch, substitute a default) — that decision is declared, not improvised. template keeps the branches honest variants of one base rather than N unrelated prompts. This is easily a multi-hundred-line subsystem: the branch registry, the budget config, the merge-policy engine, and the round-trip assertion that gates the whole thing.
The honest edge
junction can only fold under the policy you declared — it executes your merge rule faithfully, it does not know whether your merge rule is wise. A majority vote across three branches that all share the same blind spot produces a confident wrong answer, cleanly folded. weir's budget cuts a runaway branch, but a branch that finishes cheaply with garbage passes the budget and enters the fold. The braid's guarantee is structural: what fanout split, junction can provably reassemble, under a policy fixed in advance, with every branch's contribution labeled and auditable. Whether the combined answer is good is a question about your merge policy and your branches — the braid makes that question legible and honest, it does not answer it for you.
These are ingredients, not instructions you have to follow. Take these parts and cook something — the recipe as written, a variation, or something we'd never have thought of.
Built it, got stuck, or found a mistake? Shea wants to hear it — success stories, questions, and bug reports all land in the same inbox: