Case study · AI & Product
Designing an Evidence-First AI Recruitment Partner
Most AI recruitment tools start with a job description and a résumé. A human recruitment specialist starts by understanding the person.
I used my own diverse career to investigate what happens when AI mistakes a document for the human behind it—and designed a workflow that asks before it assumes.
Role: Concept, research, service design and workflow architecture · Status: Working guide and prototype · Independent usability testing planned.
The problem was bigger than a better prompt
Across social media, AI résumé advice had become a content category of its own.
LinkedIn, Instagram, Facebook and TikTok were full of prompts promising to optimise a résumé, calculate a match score or produce the perfect cover letter.
At the same time, recruiters were complaining about “AI slop”: generic applications, repeated phrases and no sense of the person behind the document.
Candidates wanted less repetitive work. Recruiters wanted better evidence. Another prompt was unlikely to solve either problem.
AI slop is often caused by sloppy workflows.
The question was not simply how to improve the writing.
It was: what should happen before the writing starts?
I tested the prompts on myself
I followed a range of social-media AI prompts step by step, using my own career as the test material.
I saw generic language, confident fabrication and drift as I tried to correct the output. When I constrained the system more tightly, different problems appeared: relevant experience disappeared because it was not stated in the particular résumé being assessed.
One striking example was its conclusion that I lacked budgeting and P&L experience, despite my résumé showing multiple Head of Marketing roles.
Those titles did not prove the scale or nature of my financial responsibility—but they should have prompted a question, not a negative conclusion.
That exposed the central design failure.
When unconstrained, AI can invent. When constrained to a résumé and job description, it can mistake omitted information for absent capability.
The workflow needed a third response:
Ask.
A résumé is not the person
A résumé is useful because it leaves things out. It compresses a career into the evidence most relevant to a particular reader.
My communications, government, strategy, CX and product résumés all offered legitimate but different views of the same career.
Changing the document did not change the underlying capability.
A résumé is a lossy compression of a career.
An experienced recruiter uses professional context to identify possibilities. Seeing “Head of Marketing” might prompt questions about budgets, agencies, procurement or executive reporting.
That context can generate a question. It cannot generate a claim.
Equally, the absence of detail cannot establish a gap.
Before assessing an opportunity, the system needed a broader evidence base—and rules governing what it could do with information it did not have.
Design around the human process
A competent recruitment specialist working for the candidate would first understand:
- what the person can do;
- what they want to do;
- the evidence supporting their experience;
- their circumstances and constraints; and
- the compromises they are willing to make.
Only then would they assess a particular opportunity.
Candidates also wanted relief from repetitive administration. A separate frustration was trending across social media: application portals asking people to re-enter information already contained in their résumés. Commenters described abandoning otherwise relevant opportunities because the process demanded too much duplicated effort.
The design question became:
How might we reduce the cognitive and administrative burden of recruitment while preserving candidate truth, individuality and decision-making authority?
Common AI workflow
- Job description
- selected résumé
- match score
- AI rewrite
- generic application
Designed workflow
- Know me
- know what I want
- find opportunities
- assess
- ask
- verify
- represent me
- preserve what was sent
- learn
Routine work can be assisted.
Career direction, new factual claims, personal declarations and final submission remain with the candidate.
Evidence before eloquence
The workflow distinguishes between three evidence states.
| State | Meaning | Required behaviour |
|---|---|---|
| VERIFIED | Supported by candidate-supplied evidence | Use only within the scope established |
| UNKNOWN | Not currently established | Ask; never silently convert it into a fact or a gap |
| GAP | The candidate confirms it is absent | Record the specific gap and never claim it |
Professional context can identify an “evidence shadow”: something that may reasonably exist but has not been established.
The system then asks.
A yes leads to questions about context, scale, contribution and outcome. A no closes the branch. Limited exposure remains limited exposure.
AI cannot promote its own inference to VERIFIED.
The candidate may still choose to pursue an opportunity with an unresolved requirement, but that decision does not turn an unsupported claim into a fact.
Operating it changed the design
Using my own career history allowed me to operate the workflow end to end before asking another person to disclose sensitive information.
That exposed requirements that prompt testing alone would not have revealed.
The workflow needed to support live vacancy research, evidence retrieval, document production, visual quality checks and repetitive application tasks. It also needed to stop when it encountered a new factual claim, a personal declaration or the final submission decision.
The larger problem was continuity.
Career evidence, preferences, corrections and application records could not remain scattered across conversations and documents. The system needed durable records of what had been verified, what remained unknown and exactly what had been submitted.
It also needed to preserve the person.
An application can remain factually close to its source and still erase individuality through generic language, altered seniority or lost specificity. The objective was not merely a technically acceptable document. It was an application the candidate could honestly recognise as their own.
From operated workflow to self-build guide
A colleague, mentor and former client—who is also a friend—watched me operate the workflow and encouraged me to make it available to other people.
That was an independent signal of perceived value, not proof that someone else could use it without me.
I translated the architecture into a public, self-build guide with practical stages, prompts and reusable records.
The candidate configures the workflow inside their own AI environment. The guide supplies the method, governance and checkpoints.
The next question is:
Can another person independently configure and use the system without Rebecca operating it for them?
Usability testing will examine where people become confused, whether the evidence audit uncovers relevant omitted experience, whether claims remain supported and whether the resulting documents still sound like the person.
Why I did not build another AI app
I could have built an application around this.
As an experienced AI founder, I also understand what sits behind the excitement of “just build an AI app”.
A standalone product would introduce model and token costs, authentication, sensitive data storage, privacy and security obligations, infrastructure, support and an entirely separate go-to-market challenge.
Those costs would begin before the underlying workflow had demonstrated that other people could use it successfully.
The candidate already has an AI environment. The more responsible first product is therefore the method: a self-build tool that helps people organise capabilities they may already be paying for around a better human process.
This makes the workflow accessible, keeps career information within the candidate’s chosen environment and allows the proposition to be tested before funding another application layer.
If independent use demonstrates value—and software would materially improve the experience—the decision to build can be made with evidence.
Until then, the right product decision is not to build more technology than the problem requires.
AI is a force multiplier. It is not a compass.
Its value lies in expanding what we can examine, retrieve and test.
Direction, truth and career decisions remain human.