Turn project requirements into client-ready BA deliverables.
A business-analysis platform for consulting and delivery teams. Give it the brief, the client's documents and the project context; it reads them with a BA engine before it writes anything, then produces the documents a scoped engagement needs — a core pack of eight in dependency order, and sixteen more on demand — with every version kept and every export branded.
- 24
- document types, 8 in the core pack
- 5
- specialist passes before it writes
- 0
- versions overwritten, ever
- Technical Questionsdone
- Product Requirements Documentdone
- Statement of Workdone
- Solution Architecturerunning
- Milestones & Delivery Planqueued
- Effort & Cost Estimatequeued
The documents are the job, and they are written from scratch every time
A scoped engagement needs the same core documents, each derived from the last. In practice they are assembled by hand from an old file, with the same context retyped into every one — and a single scope change means editing all of them.
- 1Client brief arrives
- 2Requirements analysed by hand
- 3Documents started from an old file
- 4The same context retyped into each one
- 5Formatting drifts between authors
- 6A scope change means editing six documents
- 7Exports assembled and rebranded manually
- 1Brief and client documents go into the project
- 2Sources are indexed and retrievable
- 3Deliverables generated in dependency order
- 4Each one grounded in the ones it derives from
- 5Formatting comes from the workspace, not the author
- 6A change is regenerated and diffed against the last version
- 7One export produces the branded pack
One pipeline, from the brief to the branded pack
Nothing here is a prompt box with a document template attached. Each stage feeds the next, and the output of every stage is inspectable.
- 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
A pack that agrees with itself
Because each document is generated from the ones it depends on, the estimate matches the scope and the proposal matches both — and a consistency pass reads the finished set looking for the places they still drift. That is the point of the dependency graph.
- 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.
Everything an engagement needs around the writing
Generation is one part of it. The rest is what makes the output usable by a team with a client waiting.
Analysis
Where an engagement's material is captured and kept current.
- Requirements workspace
- Project and client record
- Document-type registry
BA intelligence
The engine reads the engagement before it writes a word of it.
- Project classification
- Discovery model
- Specialist passes
AI generation
Generation that reads the project rather than a prompt box.
- Single-deliverable generation
- Full-pack generation
- Workspace prompt overlays
Knowledge
The client's own material, made retrievable and kept inside its workspace.
- Uploads
- Chunking and embeddings
- Grounded retrieval
Documents
What happens after the model stops writing.
- In-place editing
- Immutable versioning
- Compare
Exports
Client-ready files, branded by the workspace rather than the exporter.
- DOCX
- Markdown
Collaboration
Organisations, workspaces and the people inside them.
- Organisations
- Workspaces
- Invitations
Governance
What a delivery lead needs to see without asking anyone.
- Usage analytics
- Spend ceilings
- Activity ledger
Administration
Platform-level control for whoever operates the deployment.
- Provider configuration
- Prompt administration
- Model pricing
The model is a step in the pipeline, not the product
A generation is assembled from the engagement's own material and its declared dependencies. What arrives at the model is not a prompt somebody typed — it is the project.
- 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 client’s own documents, made usable
Upload the brief, the audit, the vendor’s API note and the kick-off transcript. Each one is extracted, split, embedded and stored beside the project — and retrieved when a deliverable is written, so the output quotes the engagement rather than the internet.
Retrieval is scoped to a workspace inside the query itself, so one client’s material can never surface in another’s document.
| 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 |
- 01Upload
PDF, DOCX, text, markdown
- 02Extract
Text pulled from the file
- 03Chunk
Split into overlapping windows
- 04Embed
Each window becomes a vector
- 05Store
Kept with its workspace and project
- 06Retrieve
Nearest passages for this run
- 07Ground
Fed to the model under a budget
- RESULTAnswers with sources
The assistant cites the documents it drew on, so a claim can be checked rather than trusted.
Generated is a starting point, not a verdict
Every deliverable is editable in place, and a hand edit is a version like any other. Nothing is ever overwritten: each generation, edit and restore appends.
- EditChange anything the model wrote, in the document itself.
- CompareA line-level diff between any version and the one before it.
- RestoreAn earlier version is copied forward, so restoring is itself undoable.
- AttributeEvery version records what wrote it: which engine, or which person.
- v4Regeneratedminimax · 10 min ago
- v3Hand-editedyou · 2 h ago
- v2Restored from v1you · 4 h ago
A file the client can be sent, not a copy-paste
DOCX, PDF or Markdown, rendered from one document format that belongs to the workspace rather than to whoever pressed export. Page size, margins, fonts, logo placement, footer and confidentiality note are set once and carried by every file.
The on-screen paper view is driven by the same format the exporters use, so what you approve on screen is what leaves the building.
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 |
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 |
Built for a firm, not a single author
An organisation holds people and billing. A workspace holds the work. A project belongs to exactly one workspace, and so does everything inside it — documents, chats, runs and costs.
Roles decide what someone can do: five at organisation level, four inside a workspace, resolved from a single capability matrix. An organisation can define its own roles on top of those when the built-in ones do not fit.
Access is membership, never row ownership: a colleague in the same workspace reaches its projects, and a resource in another workspace answers 404 rather than 403 — a 403 would confirm it exists.
Operational visibility, without asking anyone
Every run records its provider, model, tokens, duration and cost. A monthly ceiling is a control rather than a warning: once it is reached, generation is refused instead of quietly billing past it.
- Usage analytics
- Runs, tokens and cost by provider, model and workspace.
- Spending ceiling
- Set per organisation; refuses work rather than exceeding it.
- Activity ledger
- Who did what, to which object, and when.
- Audit log
- Field names only — requirements and client content never enter it.
Generation is refused once the ceiling is reached.
- Delivery$104.1062%
- Presales$61.2031%
- Internal$17.107%
An engagement, from brief to pack
What a delivery team actually does with it on the first afternoon.
Put the engagement in
The brief is a first-class record, not an attachment: it is what the pipeline reads.
- You
- Create the project and paste the brief.
- The system
- Holds it as the requirements every deliverable is derived from.
Add what the client sent
PDFs, Word files, notes and transcripts become retrievable material rather than reading homework.
- You
- Upload the documents that came with it.
- The system
- Extracts, chunks, embeds and indexes each one against the project.
Run the pack
A run can be cancelled, and failed steps retried without redoing the ones that worked.
- You
- Choose the engine and press run.
- The system
- Generates the core eight in dependency order, streaming progress per document.
Read, edit, regenerate
The document you send is the one you approved, not the one the model happened to produce.
- You
- Work through the output and change what is wrong.
- The system
- Saves every change as a version and can diff or restore any of them.
Export
The same document format drives the preview and the file, so there is no surprise on the client’s screen.
- You
- Pick a format and send it.
- The system
- Renders the branded file — or the whole pack, with cover and contents.
Every document, and what it is for
Technical Questions
The questions a developer must have answered before anyone can commit to a build. It is written first because everything after it inherits the assumptions it exposes.
Product Requirements Document
What is being built and why, in outcomes rather than features. The PRD is the document the rest of the pack is derived from.
Statement of Work
The commercial spine of the engagement: scope, deliverables, acceptance and the boundaries the client is signing against.
Solution Architecture
How the thing is actually built: components, data, integrations and the decisions that constrain delivery.
Milestones & Delivery Plan
How the scope is sequenced into deliverable stages, and what each stage is worth. Weightings can be set explicitly so the payment schedule matches the signed SOW.
Effort & Cost Estimate
What the work costs, broken down so a client can see what they are paying for and a delivery lead can defend it.
Risk Register
The risks that could move scope, cost or date, each with an owner and a response — surfaced before they become escalations.
Client Proposal
The document the client actually reads: the case for the work, drawn from everything above it so the numbers and the narrative cannot disagree.
Put one real engagement through it
Create an account, paste a brief you already have, and read the pack it produces. That is a more useful evaluation than any demo we could give you.