Built around the documents, not around the model
BA SOW Maker started from a narrow observation: consulting teams write the same documents for every engagement, each derived from the last, and almost all of that derivation is done by retyping.
A general writing tool cannot do this job
A Statement of Work is not a document about scope; it is the document a client signs against. An estimate written without the architecture is a number nobody can defend. Those relationships are the product.
So the pipeline enforces them. Each deliverable declares what it depends on, and a run walks that graph — feeding the documents a deliverable derives from before anything else competes for the context budget.
- Nothing is overwritten
- Every generation, edit and restore appends a version. The record of what was sent survives whatever happens next.
- Degrade, never lose
- When retrieval or a provider fails, the enhancement is dropped and the reason is recorded where a person can reach it.
- Membership, not ownership
- Access is decided by role in a workspace, never by who created a row.
- Say what was cut
- A truncated brief announces itself, because a model given one silently answers as though it had the whole thing.
Three decisions we would defend in a review
Not features — decisions, and what each one cost.
Dependency order over speed
Generating the pack in parallel would be faster and would produce documents that disagree with each other.
Ceilings that refuse
A spending limit that only warns is a reporting feature. Ours stops the work, which is occasionally inconvenient and always honest.
Values out of the audit
The audit log records field names, never content. It is less useful for debugging and correct for a system holding client-confidential material.
What the product is, in one diagram
- 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.
Tell us where it is wrong
The most useful thing you can send us is a deliverable it produced badly for an engagement you know well.