Pick the right reference project, and show why it fits

The tender asks for three comparable references from the last three years. Finding past projects is the easy part. The hard part is showing, for each one, why it meets the requirement, and being honest about where it does not.

A weak reference rarely fails because the project was bad. It fails on a detail. The project ended before the window opens. The contract value was the consortium's, not yours. The buyer contact left two years ago. Each is easy to check early and painful to find in the final review.

Here is a method for choosing references against one requirement, and the part Atlas hands to its Past Proposal Agent. The example is made up. The tender, the projects and the figures are synthetic, so nothing in it belongs to a real buyer or bidder.

The rule behind the requirement

Under the EU procurement directive, a buyer may require "a sufficient level of experience demonstrated by suitable references from contracts performed in the past" (Directive 2014/24/EU, Article 58(4)). The evidence covers works over at most the past five years, and supplies and services over at most the past three. The buyer may also accept older evidence "where necessary in order to ensure an adequate level of competition" (Annex XII, Part II).

So the directive sets a ceiling, and the tender sets the actual terms. Read the requirement in the tender before you pick anything. Read the Q&A log too: an answer can change what a requirement means, the same trap as in a reissued tender package.

The setup: one requirement, ten past projects

An IT operations framework. The suitability requirement asks for at least three references for comparable operations services, each performed within the last three years, each worth at least EUR 400,000 a year. For each, the bidder gives the scope, the value, the period, its own role and a contact at the buyer. The buyer may ask for completion statements.

The bid team has records of ten past projects that could be relevant.

Step 1: split the requirement into criteria you can test

Do not start from the archive. Start from the requirement, and turn it into criteria with a yes or no answer.

Every reference you put forward has to pass all five, so the bid manager owns this list.

Step 2: shortlist from the archive, with a source for every claim

Now test each project against each criterion, and note where each answer comes from: the past proposal, the contract, the completion statement. A claim without a source is one you cannot defend if the buyer asks.

In the example, six of the ten projects make the shortlist. The other four are clearly out of scope.

Step 3: mark the gaps before anyone picks

The matrix is most useful for what it shows as missing. Five kinds of gap appear.

The scope is close, not the same. Project C was a one-off cloud migration, not ongoing operations. It is recent and large, and it answers a different question.

The project is outside the window. Project D is the best match on scope and size, and it ended in early 2022. Unless the tender says older evidence counts, it does not. Project A is a closer call. It ran from March 2022 to February 2025, so it started before the window and was performed partly inside it. Check whether the tender counts that.

The value is not yours. Project B was a consortium contract worth EUR 900,000 a year, and the bidder's share was 35 percent. Whether that meets the size criterion depends on how the tender treats consortium references. Check the tender text, and do not round up.

The proof is missing. Project E was delivered as a subcontractor. The bidder has the subcontract, but no contract with the buyer and no buyer contact.

The contact is gone. Project F passes every other criterion, but the person who signed off the project has left the buyer. Someone has to find and agree a new contact first. A smaller version of the same gap runs through the records: for A to D they hold the contact's role, not a name. A's contact has agreed to be called, but someone still has to write down who it is.

One more rule applies when a reference comes from a partner. A bidder can rely on another company's relevant professional experience only where that company will perform the services the experience is needed for (Article 63(1)). A partner's reference brings the partner into the delivery.

Step 4: a subject expert picks, and the reasons are written down

The shortlist is a working paper, not a decision. A subject expert who knows the projects picks the references. The bid manager records why each one was chosen and why the others were left out.

In the example the expert picks A, F and B. A goes in once the bid team has added the contact's name and confirmed that the tender counts a contract that started before the window and ran into it. F goes in once a new contact has agreed. B goes in only if the tender counts the consortium value. If not, E takes its place once the bid team has found a buyer contact and the tender accepts subcontract work. C and D stay out, with the reasons written next to them.

When the buyer asks a clarification question about a reference, the answer is already there.

Step 5: hand the reference to the write-up

Each chosen reference then has to be written up around the requirement. That is a separate job. The case write-up takes "a selected past project and the requirement it must demonstrate" and writes "the project example around that requirement without adding unsupported facts".

The order matters. If the write-up comes first, the reviewer works backwards from polished text to the contract. If the shortlist comes first, the reviewer checks five criteria and a source column.

What Atlas does, and what it does not

Atlas does not start from a blank page. Each customer keeps a past proposals library: the bids they have submitted, won and lost. Each proposal in it can hold the tender material that set out what the buyer asked for, the response that was submitted, and the buyer's evaluation. That library is what Atlas reads when it writes a new proposal.

Reference projects get their own agent. Atlas is the orchestration agent. When a tender asks for references, it hands the task to the Past Proposal Agent, a knowledge agent that runs as a sub-agent of Atlas. The Past Proposal Agent reads the past proposals library. It only searches the folders and filters the user picks. Inside that scope it works in a ReAct loop, short for reasoning and acting. It works out what the requirement needs, searches, reads what it finds, checks it against the criteria and decides what to look at next, then reports back to Atlas.

What comes back is a first pass at the matrix from step 2: each project in scope tested against the requirement from its own record, with the gap named where there is one. It also names conflicts between records. In the demo, project C's value is in EUR in its file and in DKK on its library entry, and Atlas flags the mismatch instead of picking one. That takes on the slow part of the method, reading past proposals and project records against each criterion.

It does not pick the reference. A subject expert does. The Past Proposal Agent does not judge whether a buyer will accept a consortium value or an older project, and it cannot find a project that is not in your records or sits outside the folders you picked. The criteria, the choice and every call on a gap stay with the bid team.

Keep the library ready for the next requirement

The shortlist is only as good as the records behind it. Most gaps in step 3 are a document nobody filed when the project ended: the completion statement, the final contract value, a buyer contact who agreed to be called.

So file the lost bids as well as the won ones, and keep the tender material and the evaluation with each response. The evaluation shows what the buyer marked down last time. Add the three missing documents when a project closes. The first record comes earlier, at signing: file the contract you checked against every promise in the offer. The next requirement then starts from projects you can prove, not projects you remember. If you are moving proposal tools, check that your past performance records come with you when you migrate your content.

Where this sits

Reference match is element 11 (REF) in our periodic table of commercial work, in the Discover family. It turns a knockout requirement, such as reference projects inside a time window, into a short list you can defend. Two related elements: the evidenced CV (ECV) does the same for named staff, as in tailoring CVs for tenders, and the case write-up (CWU) turns the chosen reference into an answer. Each element follows the same shape: one input, one agent task, one human gate.

The full table, with every element, is at /periodic-table.