There is a difference between a clever thing you can do with a model and a process your team can rely on. The clever thing depends on a particular person being present, in the right mood, remembering the prompt that worked last time. The process does not. It has documented steps, named inputs and outputs, a place where the work lives, and a way to hand it off without a half-hour of tribal knowledge transfer. Turning idea generation with models into that kind of process is the subject of this article.
Hypothesis generation is especially prone to staying trapped as a personal trick. It feels improvisational. One person riffs with the model, produces a few interesting claims, and the value is real but invisible—no one else can reproduce it. The moment that person is on leave or moves teams, the capability vanishes. A workflow exists to make the capability survive its originator.
What follows is a structure you can adapt: the stages, the artifacts each stage produces, the handoff points, and the maintenance routine that keeps the workflow from rotting. If you want the strategic version with named plays and owners, pair this with the operating playbook. This article is about the plumbing.
Why A Workflow Beats A Knack
A knack is fast for the person who has it and useless to everyone else. A workflow trades a little of that speed for reproducibility, and reproducibility is what lets a capability compound across a team rather than evaporating.
The cost of the knack
- Output quality swings wildly depending on who is at the keyboard.
- There is no way to improve the practice because there is nothing written down to improve.
- Onboarding a new person means shadowing, which does not scale.
What documentation buys you
- Anyone can run the process at a baseline level of quality.
- The process itself becomes an object you can critique and refine.
- You can audit why a particular hypothesis was produced, which matters when decisions trace back to it.
Mapping The Stages
A workflow is a sequence of stages, each with a clear entry and exit condition. For hypothesis generation, four stages cover most cases.
Stage one: framing
- Define the question precisely: what surprised you, what decision hangs on the answer.
- Gather the context the model needs—data summaries, prior attempts, known constraints.
- Write the framing down so the model and the next human both work from the same brief.
Stage two: generation
- Prompt the model to produce a wide field of candidate hypotheses.
- Capture the raw output verbatim, including the weak ideas, so the record is honest.
- Note which prompt phrasing produced the most usable variety.
Stage three: pruning
- Cluster near-duplicates and cut anything unfalsifiable.
- Apply an adversarial pass to the survivors to test their durability.
- Record why each survivor stayed; that reasoning is part of the artifact.
Stage four: test design
- For each survivor, name the cheapest observation that would prove it wrong.
- Hand the test to whoever will run it, with the hypothesis attached.
Defining Inputs And Outputs
A stage is hand-off-able only when its inputs and outputs are explicit. Vague boundaries are where workflows leak.
The artifacts that move between stages
- Framing brief: the question, context, and constraints, produced in stage one.
- Raw candidate list: the unedited model output, produced in stage two.
- Pruned shortlist with rationale: the survivors and the reasoning, produced in stage three.
- Test specifications: falsification plans, produced in stage four.
Where the work lives
- A single document or ticket per cycle, not scattered chat logs.
- Prompts stored in a shared library so they can be reused and improved—see managing a prompt library.
- Outputs versioned so you can see how a hypothesis evolved.
Building In Verification
A workflow that produces confident, unverified claims is worse than no workflow, because it manufactures false certainty at scale. Verification has to be a stage gate, not an afterthought.
The gates between stages
- Nothing leaves generation labeled as fact; everything is a candidate.
- Nothing leaves pruning unless it is falsifiable.
- Any hypothesis that cites data is checked against the source before test design.
Catching the model's failure modes
- Watch for fabricated mechanisms presented with unwarranted confidence.
- Require traceable evidence for any claim that will reach a decision-maker, a discipline shared with grounding outputs in sources.
- Treat fluency as a hazard, not a signal of correctness.
Handing The Workflow Off
The real test of a workflow is whether a new person can run it from the documentation alone. If they need you in the room, you have a draft, not a workflow.
Writing for the next person
- Document each stage as a checklist with entry and exit conditions.
- Include one fully worked example from a real cycle.
- Note the common pitfalls so the next person does not rediscover them painfully.
Reducing dependence on you
- Have someone unfamiliar run the workflow while you watch silently.
- Fix whatever they got stuck on by improving the docs, not by explaining verbally.
- Repeat until the docs carry the load.
Maintaining The Workflow
A workflow is not a monument; it is a living asset that decays as models, data, and questions change. Maintenance keeps it useful.
The maintenance routine
- Review the workflow quarterly against what actually happened in real cycles.
- Retire prompts that have stopped producing variety and add ones that work.
- Fold lessons from failed hypotheses back into the framing stage.
Signs the workflow needs work
- Output quality has crept back to depending on who runs it.
- People are skipping stages, which usually means a stage adds no value or is too costly.
- The artifacts have drifted from the documented format, a hint the format no longer fits the work. Pair this review with broader prompt review standards so the workflow stays aligned with team norms.
Frequently Asked Questions
How detailed should the documentation be?
Detailed enough that a competent new colleague can run a full cycle without asking you a question, and no more. Over-documentation is its own failure—nobody reads a forty-page manual. The sweet spot is a checklist per stage with explicit entry and exit conditions plus one worked example. The example does more teaching than paragraphs of explanation, because it shows the artifacts in their real form.
What if the workflow slows down a fast analyst?
It will, slightly, and that is the trade you are making on purpose. The fast analyst loses a little speed; the team gains reproducibility, the ability to improve the process, and resilience when that analyst is unavailable. If the slowdown is severe, the workflow is too heavy—strip stages until running it is barely more effort than the knack it replaced.
How do we keep the prompts from going stale?
Store them in a shared library, tag which ones produced usable variety, and review them on the same cadence as the rest of the workflow. Prompts that stop generating genuine variety get retired; new ones that work get added. The library is part of the workflow, not a separate concern, and it should be versioned so you can see what changed and why.
Where should the work actually live—chat or a document?
Not in scattered chat logs. Each cycle should produce a single document or ticket that holds the framing brief, the raw candidate list, the pruned shortlist with rationale, and the test specifications. Chat is fine for the interaction with the model, but the artifacts that the next person needs must be consolidated somewhere durable and searchable.
How do I prove the workflow is working?
Track a small number of honest metrics: how often a generated hypothesis changed a decision, how often a new person could run a cycle unaided, and how often a fabricated claim was caught at a gate rather than after it reached someone. These tell you whether the workflow is producing value, transferring, and protecting you from confident nonsense respectively.
Can this workflow run without a dedicated facilitator?
Once it is documented and the gates are clear, yes. The facilitator role matters most during installation, when someone has to keep the stages honest and the handoffs clean. After that, the documentation carries the structure, and the role can rotate or dissolve entirely, with the verification gates doing the work that a facilitator's vigilance used to.
Key Takeaways
- A knack lives in one person's head; a workflow has documented stages, explicit artifacts, and handoffs that survive a personnel change.
- Four stages—framing, generation, pruning, and test design—cover most hypothesis generation work, each with clear entry and exit conditions.
- Verification is a stage gate: nothing advances unless it is falsifiable and any cited evidence is traceable to a source.
- The workflow is hand-off-able only when a new person can run it from the documentation alone, without you in the room.
- Treat the workflow as a living asset—review it quarterly, retire stale prompts, and fold lessons from failed hypotheses back in.