It analyses the engagement before it writes a word of it
The interesting part of applying a model to business analysis is not the model. It is deciding what it is allowed to read, in what order, and what happens to what it writes.
- RequirementsThe engagement's brief
- Project contextClient, scope, prior decisions
- KnowledgeRetrieved passages from uploads
- DependenciesThe deliverables this one derives from
- InstructionThe focus note for this run
Written to the document type’s own format and system prompt, saved as a new version, and costed against the organisation’s spending ceiling. The model is one step in the pipeline, not the product.
The brief is analysed, not reformatted
A generation does not paraphrase the brief into a template. Each document type carries its own instructions about what to look for, what to exclude and what to make explicit.
Assumptions surfaced
Where the brief is silent, the gap is stated as an open question rather than filled with a guess.
Scope in both directions
Exclusions are given the same weight as inclusions, because that is where scope disputes come from.
Measurable acceptance
Criteria are written with thresholds and timings, not adjectives.
A discovery pass runs before any document is generated
Asking a model to write a Statement of Work from a brief is one prompt. What happens here is an understanding pass whose output is structured records — and every document is then written from those records rather than from the raw brief again.
Classify
What kind of engagement this is, which decides which specialists are worth running on it.
Discover
Requirements, assumptions, open questions, risks and dependencies, extracted as records you can read, answer and confirm.
Research
External capabilities the brief leans on, checked rather than assumed.
Specialists
BA, Technical Architect, Security, Estimation and Risk, each scrutinising what a first pass leaves shallow.
Write
The document, from the model above plus its declared dependencies and the retrieved knowledge.
Check
A quality score on the document, and a consistency pass across the set.
The analysis is fingerprinted against the requirements and the indexed documents, so it is paid for once per change rather than once per document. Change the brief and it runs again; generate a fifth document from an unchanged brief and it does not.
Two passes you did not have to ask for
A document that reads well and disagrees with the one beside it is worse than an obviously rough draft, because nobody catches it until the client does.
Quality gate
Every generated document is scored before you see it — against its own type's criteria, never by inventing detail to raise the score. A weak score is information on the document, not a silent rejection of work you already paid for.
Cross-document consistency
The pass that reads the finished set looking for the SOW and the estimate disagreeing on feature count, or the PRD and the roles matrix naming the same role differently.
Each document type has its own instructions
A Statement of Work and a Risk Register are not the same task with a different heading. Each type carries a system prompt and a format, administered centrally and versioned when changed, so output is consistent across a firm rather than across one person’s prompting habits.
- System prompt
- The mindset the document is written from, per type.
- Format template
- The structure it must produce, per type.
- Run instruction
- A focus note for this run only — a tone, a constraint, a client's preference.
- Explicit controls
- Milestone counts and weightings are stated as given, so a payment schedule matches the signed SOW.
- Workspace overlay
- A firm's house rules layered onto every type, without forking a template per team.
- Technical Questionsdone
- Product Requirements Documentdone
- Statement of Workdone
- Solution Architecturerunning
- Milestones & Delivery Planqueued
- Effort & Cost Estimatequeued
What the model is allowed to read
Context is a budget, not a bucket. Everything competes for the same allowance, and the order is decided by what the document is derived from.
- 1RequirementsThe brief, first, always.
- 2Declared dependenciesThe deliverables this one derives from, in dependency order.
- 3Retrieved knowledgeThe passages from uploaded sources nearest to this document's subject.
- 4Other deliverablesWhatever else exists, if there is budget left.
- 5Run instructionThe focus note, last, so it modifies rather than competes.
Sharing one budget is deliberate. Giving each source its own allowance means the prompt grows with the number of documents in the project — six deliverables later, nobody has budgeted for what is being sent, and the provider is billing for all of it.
Spending it in dependency order is equally deliberate: the document a deliverable is derived from must not be pushed out by whatever happened to be edited most recently.
When something is cut, it is cut on a line boundary and says so, because a model given a silently truncated brief answers confidently as though it had the whole thing.
Order is what makes the pack coherent
Documents that quote each other have to be written in the order they quote.
- 01Technical Questions
no dependencies
- 02Product Requirements Document
after Technical Questions
- 03Statement of Work
after Technical Questions, Product Requirements Document
- 04Solution Architecture
after Product Requirements Document, Statement of Work
- 05Milestones & Delivery Plan
after Statement of Work
- 06Effort & Cost Estimate
after Statement of Work, Solution Architecture
- 07Risk Register
after Statement of Work, Solution Architecture
- 08Client Proposal
after Statement of Work, Solution Architecture, Effort & Cost Estimate, Risk Register, Milestones & Delivery Plan
A run walks this graph rather than a list. Each document is generated with its declared dependencies fed first, under one shared context budget, so the document a deliverable is derived from cannot be squeezed out by whatever was edited most recently.
Regeneration is a revision, not a replacement
A regeneration can be based on the current text or on any earlier version, with an instruction describing what should change. The result is a new version; the one you were comparing against is still there.
- Every version records the engine and model that produced it.
- A hand edit is a version too, attributed to a person.
- A restore copies forward, so it can itself be undone.
- v4Regeneratedminimax · 10 min ago
- v3Hand-editedyou · 2 h ago
- v2Restored from v1you · 4 h ago
Seven engines, chosen per run
No single model is best at every document, and provider availability changes. The engine is a setting, not an architecture decision.
Per run
Provider and model are chosen when a run is configured, and remembered per project.
Recorded
Every version and every usage row names the engine that actually ran.
Costed
Rates are configured per model; cost and the spending ceiling are computed from them.
What the system will not do
Being clear about the boundary is more useful than claiming there isn't one.
It will not invent a brief
A run with no requirements is refused rather than producing a plausible document about nothing.
It will not hide a gap
Missing answers become questions and stated assumptions, not confident prose.
It will not decide commercially
Rates, weightings and contingency are yours; where you state them, they are used as given.
It will not lock you in
Every document is editable, every version is kept, and exports are ordinary files.
Judge it on a document you would have written anyway
Generate one deliverable for an engagement you know well, and read it as though a colleague had drafted it.