Eight documents in the core pack, twenty-four in the library
A full run produces the eight a scoped engagement always needs, in the order they depend on each other. The other sixteen — requirements layers, technical specifications, test and acceptance, cutover, change control — are generated on demand from the same graph, so they inherit the scope the pack already agreed instead of restating it.
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.
Immediately after a brief lands, and before any estimate is given.
The requirements and the project's indexed knowledge.
- Open questions grouped by area: integration, data, access, environments
- Assumptions made explicit, with the risk of each being wrong
- Third-party and API limitations that need confirming
- What cannot be estimated until each answer arrives
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
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.
Once the brief is understood well enough to describe the product.
The requirements, the indexed knowledge, and Technical Questions.
- Business outcomes and the measures that prove them
- User journeys and lifecycles, not screen inventories
- Functional and non-functional requirements
- Explicit exclusions, given equal weight to inclusions
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
Statement of Work
The commercial spine of the engagement: scope, deliverables, acceptance and the boundaries the client is signing against.
When the engagement is being agreed and priced.
The requirements, the indexed knowledge, and Technical Questions, Product Requirements Document.
- Scope in and scope out, stated with the same rigour
- Deliverables with measurable acceptance criteria
- Dependencies, assumptions and client obligations
- Change-control terms
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
Solution Architecture
How the thing is actually built: components, data, integrations and the decisions that constrain delivery.
Before technical planning and once scope is stable.
The requirements, the indexed knowledge, and Product Requirements Document, Statement of Work.
- Component and integration model
- Data model outline and storage decisions
- Environments, deployment shape and operational needs
- Technical risks that follow from the chosen approach
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
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.
Once scope is agreed and the plan has to become a schedule.
The requirements, the indexed knowledge, and Statement of Work.
- Milestones in delivery order, each with its own scope
- Weighting per milestone, stated as given rather than inferred
- Entry and exit criteria
- Client checkpoints and review gates
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
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.
Alongside the SOW, when a number has to be committed to.
The requirements, the indexed knowledge, and Statement of Work, Solution Architecture.
- Effort per workstream and per milestone
- Role mix and rate assumptions
- Contingency, and what it is covering
- What would change the number, and by roughly how much
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
Risk Register
The risks that could move scope, cost or date, each with an owner and a response — surfaced before they become escalations.
Before sign-off, and maintained through delivery.
The requirements, the indexed knowledge, and Statement of Work, Solution Architecture.
- Risks with likelihood, impact and exposure
- Mitigation and contingency per risk
- Dependencies on the client and on third parties
- Assumptions that become risks if they fail
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
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.
At the point of pitching or confirming the engagement.
The requirements, the indexed knowledge, and Statement of Work, Solution Architecture, Effort & Cost Estimate, Risk Register, Milestones & Delivery Plan.
- The business case in the client's language
- Approach, team and delivery plan
- Commercials drawn from the estimate
- Next steps and what happens on acceptance
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 |
Exported as DOCX, PDF or Markdown, branded by the workspace.
Sixteen more, generated one at a time
A data migration plan belongs to some engagements and not others, so these are not in the automatic run. Each is still derived from the documents it depends on — an API specification from the architecture, a UAT pack from the user stories and the test strategy.
The layer between a brief and a build, for engagements where the PRD alone is not the contract.
- Business Requirements Document
Business objective, stakeholders, success metrics and constraints, independent of any solution.
- Functional Requirements Document
Every feature and workflow spelled out as a testable functional requirement.
- Non-Functional Requirements
Performance, availability, scalability, accessibility and observability, each with a number attached.
- User Stories
As-a/I-want/so-that stories with acceptance criteria, grouped by persona and epic.
- Use Cases
Actor and goal, with the main flow, the alternate flows and the preconditions.
What a development team needs before it can start, derived from the architecture the pack already agreed.
- API Specification
Endpoints, request and response shapes, auth and the error contract.
- Database / Data Model Specification
Entities, relationships, ownership and retention, with an entity diagram.
- Roles & Permission Matrix
Every role, what it can see and do, and where a permission boundary actually sits.
- Security Requirements
Authentication, authorisation, tenant isolation, encryption and audit requirements.
How the work is proved, and what the client signs to close it out.
- QA / Test Strategy
Test levels, coverage targets, environments and tooling for the whole engagement.
- UAT Specification & Acceptance Criteria
Client-executable acceptance scenarios and the sign-off criteria that close the engagement.
Getting it live, for engagements that replace something already running.
- Deployment / DevOps Plan
Environments, CI/CD, infrastructure and monitoring for getting this into production.
- Data Migration Plan
Source-to-target mapping, cutover approach and rollback plan for existing data.
The documents that decide, later, whether something is a change or was always in scope.
- Scope & Exclusions
What is included, what is explicitly not, and the change-control boundary between them.
- Assumptions & Dependencies Register
Every assumption and external dependency in one place, with its confirmation status and owner.
- Change Request / Control Baseline
The baseline a future change is measured against, and the template for raising one.
24 types ship with the platform. Which of them a workspace offers, in what order, and which belong to the automatic run are all administered — a firm that never writes a migration plan can turn it off.
How the core pack relates
Read left to right: understand, agree, plan, present. A document is never written before the ones it quotes.
- 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.
Generate the pack for an engagement you know
The fastest way to judge the output is against a project you have already scoped by hand.