Tailoring CVs for tenders: evidence for every claim
A tailored CV rarely goes wrong through lying. It goes wrong through drift. Here is one Atlas run, step by step: a template from the tender, candidates ranked per role, a CV filled only from facts, and every gap left visible.
Pentimenti team

Tailored CVs rarely go wrong through lying. They go wrong through drift.
"Took part in" becomes "led". A project from seven years ago slides inside the five-year window. A certification in progress reads as held. Each edit looks small. Together they produce a CV the person could not defend in an interview, and a promise the delivery team has to keep if you win.
An AI drafting tool speeds this up in both directions. It can tailor a CV in minutes. It can also drift in minutes, and it writes fluently while doing it.
The fix is order. Read the tender, pick the person on the evidence, then write only what the CV supports. Anything the CV does not support stays visible as a gap.
Here is what that looks like in one demo run in Atlas, against the documents of a cybersecurity tender. The tender is public, and the candidates and their CVs are fictional demo data we created for the run. The same flow applies to any tender or request that asks for named CVs, public or private.
Step 1: the template comes from the tender
The first request is plain: build a CV template for the key personnel we have to submit.

Atlas starts with the tender file index, the proposal context and the bidder profile. Then it reads the annexes that govern consultant services and searches them for three things: rules on replacing key staff, security clearance requirements, and required qualifications.
The output is a Word template. Headings and field labels are in English for this demo. The consultant categories keep their names from the official order form. Requirement IDs and clearance levels stay exactly as the tender writes them, so a reviewer can trace each field back to its source. Yellow instruction boxes tell the writer what goes where, and the agent notes that they must be deleted before submission. It also notes that the real submission must be in the language the tender requires.

Step 2: a team overview, with names left open
The template opens with a team overview: one row per role, the consultant category, and empty name fields. Most rows are key roles from the tender. The agent adds one recommended role and a blank row for an additional role. Nobody has been picked yet.
Step 3: candidate search goes to a separate agent
The next request: find the most relevant candidate and fill in the template for one of the roles.
Atlas does not pick from memory. It hands the search to a sub-agent that works over the CV pool.

Step 4: a ranking per role, including the bad news
The CV agent comes back with a best candidate and a runner-up for each role, each with a one-line reason. This is the part worth reading closely, because it does not round up.

| Role | Best candidate | What the agent said |
|---|---|---|
| Sentinel architect / SIEM specialist | Sofie Jensen | Best available, and only a partial match. The runner-up has 12 years as an IT architect but no Sentinel or security operations content. |
| SOC lead | None | No real match. The closest candidate has threat intelligence and incident response work. The runner-up is junior, 3 years, with no lead experience. |
| Incident response lead | Sarah Andersen | Director, 24 years, CISSP. |
| Transition / project manager | Anders Sørensen | PRINCE2 practitioner, 20 years. The runner-up's details come from profile metadata only. The agent says it did not review that person's full CV. |
Three things in that table matter more than the names.
The top pick for the first role is called a partial match, in the first sentence. One role gets no candidate at all. And where the agent only saw metadata, it says so. Each of those is a decision for the bid manager, raised before any CV text exists.
Step 5: the CV is filled from facts, and the gaps stay open
Atlas then fills the template for the first role.

Its notes on the result:
- The profile text is a draft, written only from CV facts.
- Dedication, start date, deputy, clearance and signatures are left as bracketed placeholders for people to fill.
- An internal fit assessment recommends pairing the candidate with a hands-on engineer, who could also be named as deputy, because a requirement in the tender rewards direct use of the buyer's own platform.
- An employer mismatch: the CV pool lists a different employer from the bidding company. The agent asks for her employment or subcontractor status to be confirmed before she goes into the bid.
That last flag is the one a tired reviewer misses at midnight. It is also the kind of error that turns into a compliance problem after submission.
What the agent does, and what it does not
In this run the agent:
- built the CV template from the tender documents, keeping requirement IDs traceable
- handed candidate search to a CV agent working over the CV pool
- ranked candidates per role, including partial matches and a role with no match
- filled one CV from CV facts only
- left unknown fields as placeholders and flagged an employer mismatch
It did not decide that a partial match was good enough. It did not fill the SOC lead role with the closest name. It did not confirm anyone's employment, clearance or availability.
Two people sign off. The consultant confirms every fact in the CV is true and fills the placeholders. The bid manager decides what to do about partial matches and empty roles, resolves flags like the employer mismatch, and approves the final CV.
Why the order matters
When the CV is written first, the reviewer has to reverse-engineer every sentence. Where did this come from? Is "led" accurate? Is this person even employed by the bidder? Most reviews under deadline do not get that far.
When the ranking comes first, the reviewer checks a short table and a list of flags. Gaps surface while there is still time to find a missing certificate or put forward someone else, not in the final review the night before submission.
It also changes what you keep. A CV pool with facts an agent can search is easier to reuse on the next tender than a folder of polished CVs. If you are moving proposal tools, that is worth knowing before you migrate your CV library.
How to know it works
We have not measured this, so here are the two measures we would use.
- The share of CV claims with a verified source at expert review.
- The number of corrections the expert makes before approval.
If the first goes up and the second goes down, the method is working. Count those, not the number of CVs generated or files downloaded. Activity tells you the tool was used. It does not tell you the CV was right.
Where this sits
The evidenced CV is element 41 (ECV) in our periodic table of commercial work, in the Write family. Two related elements: reference match (REF) finds the right past project, and case write-up (CWU) turns it into an answer. Each element follows the same shape: one input, one agent task, one human gate, one measure.
The full table, with every element, is at /periodic-table.