ProposalGen

A traditional engineering proposal hides most of its work. By the time the customer sees a number, dozens of judgement calls have already been baked in: which standards to honour, how to translate an ambiguous scope, what cable lengths to assume, which brand to pick, where to set the contingency. The reader sees a price, not the reasoning.

ProposalGen inverts that. It runs the proposal as a series of discrete, named phases — intake, classification, document inventory, work-breakdown, working documents, modules, BOQ, assumptions, RFI, proposal — and writes down every decision it makes as it goes. The output is the proposal pack the customer expects. The byproduct is a complete audit trail of how each number was reached.

1. 01

   Read the customer's documents

   Cover letter, terms of reference, points lists, drawings, customer-supplied BOQ. ProposalGen tiers each by extraction strategy and captures what each document actually tells it.

2. 02

   Decide the project's shape

   Stage, contract model, scope shape, customer recognition. The classification activates the right downstream pathways — supply-only proposals don't run installation manhour calculations; greenfield doesn't run rehab inventory.

3. 03

   Produce the working documents

   A1 I/O list, A2 equipment takeoff, A3 cable schedule, A4 panel schedule, A5 network architecture, B-series programming and commissioning, D-series schedule and risk. Each row carries a citation back to the customer document it came from, or to the playbook fallback that authorised the default.

4. 04

   Price, assume, ask

   The BOQ rolls up from the working docs; assumptions are stated rather than buried; questions for the customer are framed with what the answer would change. Cable lengths and field counts are typically the highest-risk rows — those get the most scrutiny.

5. 05

   Write the proposal

   A customer-facing narrative assembled from the upstream artifacts. Every section traces back to a working doc, an assumption, or a citation. The polished pack ships as PDF, DOCX, XLSX, and PPTX.

This site — ProposalGen Review — is the transparency layer. Every proposal in the project list is something ProposalGen produced. The walkthrough takes you step by step through the same phases ProposalGen ran. On the left, the customer's source documents. On the right, the data ProposalGen produced from them. Below, ProposalGen's own reasoning for the non-trivial calls it made.

The intent: a reviewer who has never seen the project should be able to open a step, audit one number, and trace it back to the page in the customer document that supports it.

ProposalGen is built on Claude, Anthropic's frontier AI agent. CMRP configures it with a multi-phase playbook — operating principles, working-document schemas, equipment-class defaults, customer-specific brand preferences, and a customer-facing writing style — that tells the agent how a CMRP-quality proposal is built. The output is not generic AI prose; it follows CMRP's engineering conventions and defensible-pricing discipline.

The playbook evolves with every project. A pattern that surfaces during one bid lands as a permanent rule before the next one runs.

• Every quantity has a source. If a row in the BOQ doesn't trace back to a customer document or a named fallback, that's a bug — not a feature.
• Assumptions are stated, not buried. The assumption ledger lives next to the BOQ. Each row carries the cost-impact-if-wrong.
• Open questions are visible. The clarification list is part of the deliverable, not a private worry. Customers see the same uncertainty the bid team does.
• The framework is auditable. Each phase has its own checklist. Each working document has its own schema. The full playbook is open to the proposal team, and the review UI surfaces every decision the agent recorded.