The AI proposal builder is not the product

The demonstration takes about four minutes. A 100-page request for proposals is dropped into a window, a progress bar runs, and an 80-page response appears with an executive summary, a methodology, a team, a project plan and a pricing narrative. It reads well. The room is impressed, and someone asks how soon it can be used on the live bid.

Matroosberg Digital Consulting, a fictional South African digital consultancy of about 140 people, saw that demonstration in March. Two weeks later it received exactly the kind of document the tool was built for: RFP BDPI 07/2026 from the Bontebok Department of Permits and Inspections, a fictional provincial department, for a cloud-hosted permit and inspections platform with a three-year managed service. The bid manager ran the RFP through the tool as an experiment, then asked the commercial director, the delivery lead and a security architect to read the result as if they were the evaluation committee. They found a certificate that had lapsed, a support model that the price did not cover, a team that included two people who had left the company, and a go-live date nobody had tested against capacity.

None of that was bad writing. It was the tool doing exactly what it was designed to do. This series argues that the proposal builder is not the product. The product is a governed system that understands an opportunity, retrieves trusted evidence, coordinates specialist work, keeps commercial boundaries intact and produces a submission the organisation can defend. This first part describes that system as a whole. The later parts take its hardest pieces in turn.

What the builder optimises for

A proposal builder is optimised for one measure: how quickly a plausible document appears. That measure is real, and earlier CloudNala articles have covered where speed genuinely helps, in requirement extraction, clarification questions and first drafts from approved material and in reading a tender down to a bid or no-bid recommendation.

The trouble is that the document is the cheapest part of a bid to produce and the most expensive part to get wrong. As AI can read the tender; it cannot own the bid puts it, a response is a commitment made by a legal entity. Every claim in it may be checked by an evaluator, every price may be held to, and every service level becomes a contractual obligation if the bid wins. A tool that produces the document without producing the evidence behind it has moved the work from writing to checking, and checking a fluent document is slower than checking a rough one, because nothing looks wrong.

So the useful question is not "can AI write our proposals?" It is "what system would let us prove, before the bid closes, that everything in this document is complete, supported, consistent and authorised?"

The pursuit record, not the document

Matroosberg's answer was to change the unit of work. In its new design, the thing the team builds is not a document. It is a pursuit record: a structured record of the opportunity that holds every requirement with its identifier, every claim with the evidence behind it, every shared fact the response depends on, every commitment, every assumption and every approval. The document is generated from the record, and can be regenerated from it at any time.

That sounds like a technical detail. It changes three things.

First, the requirement becomes the spine. The Bontebok RFP contained 312 numbered requirements (an illustrative count) across the technical specification, the special conditions of contract and three annexures. Each one became a row with an owner, an answer, the evidence for the answer and a compliance status. This is the traceability matrix from the Architecture and Proposal Writing 101 series, but held as data that machines can check rather than a spreadsheet maintained by hand on the last night.

Second, facts stop being copied. The go-live date, the hosting region, the size of the team, the availability target and the basis of the price appear in a dozen sections of a large proposal. In a document they are typed a dozen times and drift apart. In the record each is held once, with an owner, and every section refers to it.

Third, approval attaches to content, not to files. "The commercial director approved version 9" says little about which commitments she actually read. "The commercial director approved the 36-month support price, the 99.5% availability target and the exclusion of data migration from the legacy system" can be checked.

Eight stages, each with its own owner

The system Matroosberg designed has eight stages. None of them is new to an experienced bid team. What is new is that each stage reads from and writes to the same record, so the work of one stage is visible to the checks of the next.

1. Intake. The RFP pack, its annexures, briefing notes and every clarification the department issues are converted to text, versioned and linked. Scanned annexures are converted with OCR and checked, because a requirement buried in a scanned table is still mandatory. Part 3 of this series covers why this pipeline decides retrieval quality long before any model runs.
2. Qualification. The bid or no-bid decision, with its reasons, is the first entry in the record. The discipline is the one in Win before you write; the difference is that the reasons stay attached to the pursuit, so a later decision to change scope can be tested against why the team chose to bid.
3. Requirement model. Requirements are extracted with citations to clause and page, classified as mandatory, scored or informational, and linked to the evaluation criteria and their weights.
4. Evidence library. References, CVs, certificates, case studies and approved method statements are retrieved from a governed library, not from old proposals. Each item has an owner and an expiry date. Part 3 is about this library.
5. Specialist drafting. Sections are drafted against typed briefs, by people, agents or both, each limited to the evidence it may use. Part 2 covers when this needs several agents and when it does not.
6. Delivery plan and price. The plan and the price are built from the same work breakdown, so that the architecture and the price describe the same solution.
7. Review gates. Every build of the response passes automated checks before human reviewers spend time on it.
8. Approval and submission. People with the authority to commit the organisation approve specific content, an authorised signatory signs the returnable forms the RFP requires, and one named person submits and keeps the receipt. Part 4 covers who may do what.

The proposal builder from the demonstration sits inside stage 5. It is a useful component. It was never the system.

Five properties a submission must prove

If the document is a rendering of the record, the record can be tested. Matroosberg settled on five properties, each with a test that runs before closing.

Complete means every mandatory requirement and every returnable has an answer, and the test is mechanical: no requirement row without a response, no required form missing from the package. Supported means every factual claim points to a current item of evidence. Consistent means scope, delivery plan and price describe the same solution. Authorised means every commitment has a named approver who had the authority to make it. Reproducible means the exact package that was submitted, and the receipt, can be produced later.

The builder in the demonstration could not satisfy any of the five on its own, and not because the model was weak. It had no requirement model to check completeness against, no evidence library with expiry dates, no shared facts to compare sections with, no approval record and no submission archive. Those are not features of a writing tool. They are features of a system.

The public-sector context

Public-sector bids in South Africa make these properties more than good practice. This section is general information, not legal advice, and the position below was checked on 7 November 2026.

Section 217 of the Constitution requires organs of state to contract for goods and services under a system that is fair, equitable, transparent, competitive and cost-effective, and the Public Finance Management Act places the duty to run such a system on accounting officers and accounting authorities. Evaluation under the Preferential Procurement Regulations, 2022 uses an 80/20 preference point system for tenders with a Rand value up to and including R50 million and 90/10 above that. Price earns the larger share, and the smaller share is awarded for specific goals that each organ of state stipulates in its tender documents. Bidders are commonly asked to return standard bidding documents such as SBD 1 (the invitation), SBD 4 (the bidder's disclosure, which asks whether the bidder's directors or controlling persons are employed by the state and whether anyone connected with the bidder has a relationship with an employee of the procuring institution) and SBD 6.1 (the preference points claim), and to be registered on National Treasury's Central Supplier Database. The exact forms and versions vary by organ of state, so the RFP's own list of returnables is the one that counts.

The Public Procurement Act 28 of 2024 was meant to replace much of this framework, but it never came into operation, and on 17 September 2026 the Constitutional Court declared it invalid because Parliament had not facilitated adequate public participation (SAnews). The Minister of Finance has said Treasury will prepare new legislation. Until then the existing framework applies, and the rules will change again when a new law arrives. A proposal system should therefore hold the returnables and their rules as configuration that can change, not as logic baked into prompts.

The practical consequence is simple. A missing returnable or an unsupported preference claim can cost a bid before its quality is ever scored, so completeness and support are not polish. They are the first gate.

What to measure instead of pages per hour

A builder is easy to measure: hours to a first draft. A system needs measures that show whether bids are getting more defensible. Matroosberg tracks five, and its numbers are not yet worth publishing, so here are the measures without them:

• Defects found before closing, by property. How many incomplete, unsupported, inconsistent and unauthorised items the gates caught, and at which build.
• Defects found after closing. Clarification requests from evaluators, disqualifications and delivery surprises traced back to the bid.
• Time from receipt to qualification. A good system shortens the time to a confident no-bid, which is often the most valuable decision of the month.
• Evidence coverage. The share of claims in the final package that point to current evidence.
• Commitments handed over. Whether the delivery team received the register of what was promised, on the day of award.

None of these rewards producing more text. Several reward producing less.

Building it in the right order

Matroosberg built the system in the opposite order to the demonstration:

1. The record and the requirement model first. Even without any drafting, extracting requirements with citations into a structured record paid for itself on the Bontebok bid, because the compliance check could run against it.
2. The evidence library second. Promoting the most-used references, CVs and certificates into owned, dated items took longer than expected and removed the lapsed-certificate class of error.
3. The gates third. Automated checks on completeness, support and consistency ran on every build.
4. Drafting last. Only then did the team let models draft sections, from briefs, against the library, inside the gates.

The order matters because each layer makes the next one safe. Drafting without the library produces unsupported claims faster. Drafting without gates produces them unseen.

A decision table

If most answers fall in the right-hand column, buy or build the record, the library and the gates before the writer.

Key points

• A proposal builder solves the cheapest part of bidding. The expensive part is proving the document is complete, supported, consistent, authorised and reproducible.
• Make the pursuit record the unit of work. The document is a rendering of it.
• Eight familiar stages become governable when they share one record: intake, qualification, requirement model, evidence, drafting, plan and price, gates, approval and submission.
• In South African public-sector bids, returnables and preference claims can decide a bid before quality is scored. Treat them as configuration that changes with the law, not as prompt text.
• Build in the reverse order of the demonstration: record, library, gates, then drafting.

This is part 1 of Engineering Proposal Intelligence. Next: When a 100-page proposal needs multiple agents.

Background reading: Preferential Procurement Regulations, 2022 (National Treasury); Minister of Finance statement on the Constitutional Court judgment (SAnews, September 2026); Public Procurement Act not yet effective (SAnews, 13 August 2024); Draft General Public Procurement Regulations, 2026 (National Treasury, Gazette 54528, 16 April 2026).

How CloudNala can help

CloudNala runs proposal intelligence reviews for bid teams that are being offered, or are building, AI proposal tools. We map your current pursuit process against the eight stages, test a recent bid against the five properties, and design the pursuit record, requirement model and gates that your drafting tools should sit inside, so that speed comes with evidence rather than at its expense.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Proposal Intelligence Review or write to us at consult@cloudnala.co.za