From a client brief to a branded pack, in eight moves
Each step has a purpose, something you do, something the system does, and an output you can inspect. Nothing happens off-screen.
- Technical Questionsdone
- Product Requirements Documentdone
- Statement of Workdone
- Solution Architecturerunning
- Milestones & Delivery Planqueued
- Effort & Cost Estimatequeued
The pipeline
- 01RequirementsThe brief, in the project
- 02KnowledgeClient documents, indexed
- 03DiscoveryClassified, questioned, checked
- 04AI analysisGrounded in all of it
- 05DeliverablesThe core eight, in order
- 06ReviewEdited by a person
- 07VersionsNothing overwritten
- 08ExportDOCX, PDF, Markdown
What each stage actually does
The distinction that matters throughout: what you decide, and what the system does with that decision.
Start with the requirements
Everything downstream is derived from the brief, so it is held as a record rather than pasted into a prompt.
- You
- Create the engagement and write or paste the brief.
- The system
- Stores it on the project and treats it as the first input to every run.
- Output
- A project with requirements, a client and an owner.
Add project knowledge
Client material is what separates a generic document from one about this engagement.
- You
- Upload the brief pack, audits, vendor notes and transcripts.
- The system
- Extracts text, splits it into overlapping windows, embeds each window and stores the vectors with the project and workspace.
- Output
- Sources marked indexed, with a chunk count — or marked failed, with the reason.
Let it understand the engagement
A model asked to write a SOW straight from a brief is guessing at everything the brief left out. This is the pass that finds those gaps first.
- You
- Open Discovery, or simply start a run — generation refreshes it either way.
- The system
- Classifies the engagement, extracts requirements, assumptions, open questions, risks and dependencies as records, checks the external capabilities the brief leans on, and runs the specialists the classification calls for.
- Output
- A discovery model you can read, answer and confirm — reused until the brief or the sources change.
Configure the run
A run is a production decision: what to write, from what, with which engine.
- You
- Choose one deliverable or the whole pack, pick the provider and model, add a focus note.
- The system
- States what the run will read and what is missing before anything is spent.
- Output
- A readiness verdict, and a run plan for the pack.
Generate
Documents that depend on each other have to be written in that order to agree.
- You
- Start the run, and watch it or leave it.
- The system
- Walks the dependency graph, feeding declared dependencies first under one shared context budget, scores each finished document against its own type's criteria, and records usage per step.
- Output
- A new version of each deliverable, with a quality score, and a run you can cancel or retry.
Review the output
The document that goes to a client is the one a person approved.
- You
- Read each deliverable, in reader view or as the exported page.
- The system
- Shows the material each document was derived from beside it, and a consistency pass reports where the finished set disagrees with itself.
- Output
- A judgement: accept, edit or regenerate with an instruction.
Refine and version
Revisions must not destroy the record of what was sent before.
- You
- Edit in place, or regenerate from a chosen base version.
- The system
- Appends a version, records what produced it, and can diff or restore any of them.
- Output
- A lineage: what changed, when, and by whose hand or which engine.
Export the pack
The client receives a document, not a screen.
- You
- Export one deliverable, one version, or the whole pack.
- The system
- Renders DOCX, PDF or Markdown from the workspace's document format — one set of measurements shared by Word, PDF and the on-screen page — and records the export in the audit log.
- Output
- A branded file, or a ZIP of the whole pack behind a cover and contents, each document its own file in reading order.
Why the order is not negotiable
Writing the estimate before the architecture produces a number nobody can defend. The generator enforces the order the documents genuinely have.
- 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.
A long run is a job, not a page you have to watch
A pack run outlives the request that started it. Progress is written to the run itself, so you can close the tab, come back, and see exactly which documents are done, which is being written and which failed.
- A cancelled run keeps the deliverables it already wrote.
- A failed step can be retried without redoing the successful ones.
- A run that stops reporting progress is marked failed rather than blocking the project forever.
- The spending ceiling is re-checked before every document, not only at the start.
| Source | Type | Chunks | State |
|---|---|---|---|
| Client brief.docx | DOCX | 38 | Indexed |
| Existing platform audit.pdf | 126 | Indexed | |
| API limits — vendor note.md | Markdown | 12 | Indexed |
| Kick-off transcript.txt | Text | — | Processing |
Revision is the normal case
Most documents are regenerated at least once — a scope change, a clarified answer, a different tone for a particular client. Every one of those is a version, and the previous one is still there.
- v4Regeneratedminimax · 10 min ago
- v3Hand-editedyou · 2 h ago
- v2Restored from v1you · 4 h ago
What actually reaches the client
A branded document with the workspace’s page furniture: logo where you put it, footer text, page numbers, confidentiality note, and sections starting on their own page if that is how your firm sends documents.
The engagement replaces the current storefront with a headless build. Success is measured against checkout conversion, not delivery dates.
- Lift checkout conversion by 15% within two quarters
- Cut publish time from days to minutes
| Item | Included | Notes |
| Catalogue migration | Yes | 4,200 SKUs |
| Payments | No | Existing gateway retained |
A brief you already have.
One step, fed by the project.
A file you can send today.
Run it once, end to end
Ten minutes with a real brief tells you more than any walkthrough. The free plan is enough to do exactly that.