The most common first step in AI proposal work is also the most damaging. Somebody points a retrieval tool at the shared drive that holds eight years of bids, waits for the index to build, and announces that the proposal agent now "remembers everything we have ever written".
It does. That is the problem. Matroosberg Digital Consulting, the fictional South African consultancy this series follows, tried exactly this before its bid for RFP BDPI 07/2026 from the fictional Bontebok Department of Permits and Inspections. In the first week the drafting agent proposed a project lead who had left the firm in 2024, quoted a day rate from a 2021 price schedule, cited a reference from a client who had never agreed to be named in public bids, and lifted a paragraph of methodology from a response to a different client that still contained that client's system names. Every one of those was retrieved accurately. Every one was wrong to use.
Part 1 introduced the evidence library, and Part 2 limited each drafting role to the parts of it that role may read. This part explains why that library cannot be a folder of old documents, what it has to be instead, and why the pipeline that fills it decides most of what retrieval will later get right or wrong.
An old proposal is a submission, not memory
A submitted proposal is a record of what the firm said to one client, on one date, under one set of conditions. It contains claims that were true then, prices that applied to that scope, people who were available that quarter, commitments negotiated for that contract and, often, details of that client's environment that were shared under confidentiality.
All of that is valuable as history. Very little of it is safe as memory, because memory is what an agent treats as currently usable. The gap between the two is where Matroosberg's first-week errors came from:
- Validity. A reference, a CV, a certification or a rate has a period in which it may be used. The document does not say when that period ended.
- Permission. A client may have agreed to be a referee for one bid, or only for private-sector bids, or not to be named at all. The document does not record that.
- Confidentiality. Prices, margins and client-specific details belong to the pursuit they were written for. The document mixes them with reusable method text.
- Authority. Some text in a bid is approved language (a legal position, a standard assumption); some is a writer's first draft that survived a deadline. The document gives both the same weight.
Tender response automation argued for a reusable capability pack of profiles, CVs, case studies, compliance documents, rates and method statements. That remains the right starting point. This article is about what each item in that pack must carry once an agent, rather than a person who remembers the history, is the one retrieving it.
Memory as governed items
Matroosberg's library stores items, not documents. A CV is an item. A client reference is an item. A certification, a case study, a standard assumption, a rate card version, an approved liability clause and a methodology description are items. Each one carries the same small set of fields.
Three of those fields do most of the work.
Owner. Every item has a named role that answers for it: the bid office knowledge lead for references, the people team for CVs, the commercial director for rates, legal for approved clauses, practice leads for methods. An item without an owner cannot be promoted into the library. That rule alone removed most of the material in the old bid share, because nobody would put their name to it.
Expiry. Every item has a valid-until date, or a rule that sets one. CVs expire when the person leaves or when the CV has not been confirmed for six months. References expire when the referee has not been reconfirmed within the period the firm sets, or when the project falls outside the window an RFP typically asks for. Certifications expire on the certificate's own date. Rate cards are superseded by the next approved version. A supplier's tax compliance status, which public-sector buyers commonly verify through National Treasury's Central Supplier Database, can change at any time, so the library records when it was last checked rather than treating a stored document as proof.
Reuse permission and confidentiality. Each item says who may retrieve it and where it may be used. A reference may be "may name the client in public-sector bids" or "describe without naming". A rate history is "commercial role only" and never leaves the commercial analyst's context. A client-specific architecture diagram is "this pursuit only".
These fields are not metadata for its own sake. They are what lets retrieval say no.
Retrieval that says no
A retrieval tool over a folder returns the closest matches. A retrieval service over a governed library returns the closest usable matches and reports what it withheld.
When the solution architect role on the Bontebok bid asked for "references for permit or licensing platforms in provincial government", the library returned two current references, and also returned three statuses: one reference expired (referee not reconfirmed since 2024), one restricted (client agreed to be described but not named), and one CV linked to a reference had left the firm. The drafting agent could use the first two, describe the restricted one without the name, and raise the expired one as a gap for the bid office to chase.
That gap is the point. A pipeline that silently drops expired material leaves the agent free to fill the hole with something plausible. A pipeline that returns "expired: reconfirm with referee" turns a hidden risk into a task with an owner. This is the same principle as the honest "I could not find that" path in The retrieval pipeline, end to end, applied to validity and permission rather than relevance.
It also feeds the red-team gate from Part 2. The gate's unsupported-claims check is only possible because each claim in a draft points to an item, and each item knows whether it is still valid.
The pipeline decides retrieval quality
Retrieval quality is usually discussed in terms of embeddings, chunk sizes and rerankers. For proposal memory, most of it is decided before any of those, in the pipeline that turns old bid material into items. CloudNala's RAG series covers the general pipeline in detail, including chunking and permission-aware retrieval. What follows is what is specific to proposals.
Choose the authoritative copy. A bid share holds many versions of each response: working drafts, review copies with comments, the version sent for signature and the package actually uploaded. Only the submitted package is evidence of what the firm said. Matroosberg links each package to its portal receipt and excludes everything else from promotion. Drafts often contain the most attractive text, because they were written before the commercial and legal reviews removed the overstatements.
Extract the text and check the scans. Signed reference letters, certificates and older annexures are frequently scanned images. An image with no text layer is either invisible to search or, worse, indexed as an empty item that appears to exist. Matroosberg runs OCR on scans, compares the result with a sample read by a person, and flags anything below a confidence threshold rather than indexing it. A reference letter whose dates were misread is a false claim waiting to happen.
Attach metadata and permissions at ingestion. Client, sector, date, outcome, confidentiality class and owner are attached when an item enters the pipeline, not reconstructed later. Permissions are copied from the source system and tested, because a CV sitting in a broadly shared bid folder does not mean every bid writer should see every CV.
Split into candidate items. A submission is broken into candidates: a case study, a method description, a standard assumption, a reference. Some content is never a candidate. Signed declarations and returnable forms, such as a bidder's disclosure or a preference points claim, belong to one bid on one date and are attested by named people; they are archived with the submission and never reused as content. Prices are not split out as reusable text at all; they go to the commercial history, where only the commercial role may read them.
Owner review and expiry. Nothing becomes retrievable until its owner has reviewed the candidate, corrected it, set its reuse permission and given it an expiry date or rule. Candidates nobody will own are rejected with a reason. This is the slowest stage, and it is the one that makes the library trustworthy.
Versioning. When an item is updated, the old version is superseded, not deleted, so that a past submission can still be traced to the version of each item it used. The item's history is part of the audit trail.
CVs, references and POPIA
Proposal libraries hold a great deal of personal information: CVs with qualifications, employment history and sometimes identity numbers; referee names and contact details; and occasionally information about the buyer's own staff or citizens from previous engagements. The following is general information, not legal advice.
The Protection of Personal Information Act applies to all of it. In general terms, section 14 limits how long records of personal information may be kept once the purpose for collecting them has been achieved, unless an exception applies, and section 19 requires appropriate, reasonable technical and organisational measures to protect personal information. For a proposal library that suggests a few concrete design rules: collect only what bids actually require, set retention periods for CVs of people who have left, restrict CV retrieval to the named pursuit team, keep identity numbers out of the retrievable text and attach them only at submission when a form requires them, and record the lawful basis the firm relies on for using each person's CV in bids, and what each person has been told about that use. Which lawful basis applies to CVs and referee details is a question for the firm's information officer or legal adviser, not one for the library design to assume. Agent memory, POPIA and South African organisations covers the wider memory questions.
Learning without polluting
After every result, win or lose, good bid teams record what they learned, as Red-team, submit and learn from evidence describes. The temptation is to let the agent write those lessons straight into memory.
Matroosberg treats lessons the way it treats old bids: as candidates. A lesson ("evaluators on this panel discounted generic methodology text") enters the pipeline, is reviewed by its owner and either becomes an item with an expiry, changes an existing item, or is rejected. An agent may propose a memory. It may not write one. That is the write-policy discipline from Memory write policies matter more than the database, and it matters more in proposals than in most domains, because a bad item will be reused in every bid that retrieves it.
A checklist for proposal memory
| Check | Pass condition |
|---|---|
| Authoritative source | Only submitted packages and owned source records are promoted |
| Owner | Every retrievable item has a named owning role |
| Expiry | Every item has a valid-until date or rule, and retrieval enforces it |
| Reuse permission | References and case studies record what the client agreed to |
| Confidentiality | Rates, margins and client-specific details are restricted by role and pursuit |
| Scans | OCR output is checked, and low-confidence items are flagged, not indexed |
| Signed forms | Declarations and returnables are archived with the bid, never reused as content |
| Versioning | Past submissions can be traced to the item versions they used |
| Personal information | CVs and referee details have retention rules, restricted access and a recorded lawful basis |
| Withheld results | Retrieval reports expired and restricted items as gaps, not silence |
| Learning | Lessons enter as candidates and need an owner's approval |
Key points
- An old proposal is a record of what was said to one client. Memory is what an agent treats as usable now. Do not confuse the two.
- Store items, not documents, each with an owner, an expiry, a reuse permission, a confidentiality class, provenance and a verification date.
- Retrieval over a governed library returns usable matches and reports what it withheld, so gaps become tasks rather than invented text.
- Most retrieval quality is decided in the pipeline: authoritative copy, checked OCR, metadata and permissions at ingestion, candidate items, owner review and versioning.
- Signed declarations are never reusable content, and prices belong to the commercial role alone.
- Agents may propose memories. Owners approve them.
This is part 3 of Engineering Proposal Intelligence. Previous: When a 100-page proposal needs multiple agents. Next: Agent authorisation in commercial workflows.
Background reading: Condition 7: security safeguards (Information Regulator); Central Supplier Database (National Treasury).
How CloudNala can help
CloudNala helps bid teams turn a shared drive of past proposals into a governed proposal library. We define the item classes, owners, expiry rules and reuse permissions, design the promotion pipeline from submitted packages and scans, set POPIA-aware rules for CVs and references, and wire retrieval so that it reports expired and restricted items as gaps, so that your agents draft from evidence you can still stand behind.
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