The idea started with a fairly common product question:
What part of hiring is still unnecessarily painful even with modern ATS platforms and AI?
At first, I was thinking broadly about building an AI-assisted hiring tool. The concept looked similar to a lightweight ATS: recruiters create a job, candidates move through stages, applications are screened, assessments are completed, and the strongest candidates rise to the top.
Something like:
Job Posting
↓
Application
↓
Resume Screening
↓
Assessment
↓
Candidate Ranking
↓
Interview
Technically, this was straightforward.
But the more I looked at the hiring problem, the less convinced I became that another pipeline was the answer.
The bottleneck wasn't the pipeline
Modern ATS products already handle pipelines well.
They can collect applications, filter candidates, rank resumes, schedule interviews, add screening questions, and increasingly use AI to evaluate candidate information.
The real issue seemed to happen before the interview.
Recruiters were dealing with large volumes of applicants, while candidates were increasingly using AI to tailor their resumes to job descriptions.
That creates an interesting problem.
A resume can look extremely aligned with a job description without necessarily giving the recruiter much confidence that the candidate can actually do the work.
At the same time, recruiters often have only a surface-level understanding of the technical or specialized roles they are hiring for.
This isn't really a recruiter problem or a candidate problem.
It's an information translation problem.
The three sides of the hiring disconnect
While reading recruiter discussions, forums, and social media posts, a recurring pattern became clear.
There are effectively three different representations of the same job:
The actual job
↓
What the recruiter writes
↓
What the candidate says they can do
Those three things don't always line up.
A hiring manager might need someone capable of solving a particular class of problem.
The recruiter turns that need into a job description containing responsibilities, tools, technologies, years of experience, credentials, and preferences.
Then candidates translate their own experience into the vocabulary of that job description.
Every translation introduces information loss.
For example, a job description may mention a specific tool because that's what the company currently uses.
A recruiter may interpret that tool as a hard requirement.
But a candidate might have years of experience with a closely related technology that demonstrates the exact underlying capability the company actually needs.
A traditional keyword system can miss that completely.
AI ranking alone doesn't necessarily solve the problem either. If the AI simply becomes a smarter keyword matcher, the underlying misunderstanding remains.
Recruitment needs a translation layer
That led to the core idea behind the project:
Hiring needs a reliable translation layer between the job, the recruiter, and the candidate.
Instead of immediately asking:
"Does this candidate match this job description?"
the system should first ask:
"What does this job actually require someone to be capable of doing?"
That sounds like a small distinction, but it changes the architecture of the product.
The job description stops being the final specification.
It becomes an input that needs to be interpreted.
Reconstructing the job before evaluating candidates
The first step became a Job Interpreter.
Its job is not to rewrite the job description.
It reconstructs the actual role:
- Why does this role exist?
- What outcomes should this person produce?
- What work will they repeatedly perform?
- What do they actually own?
- What capabilities are required to perform that work?
- Which items in the JD are tools, credentials, preferences, or context rather than true capabilities?
The important rule is that the interpreter cannot simply fill gaps with plausible assumptions.
If the job description doesn't support something, it remains unknown.
The output becomes a more grounded representation of the job.
But even that isn't enough.
Capabilities are not the same as evidence
Once the actual capabilities are identified, another question appears:
What candidate experience would actually prove each capability?
That became the job of the Evidence Mapper.
For every required capability, it defines possible evidence relationships:
Direct Evidence
The experience demonstrates the full material capability.
Strongly Implied Evidence
The experience strongly supports the capability, but one meaningful part isn't directly stated.
Transferable but Incomplete Evidence
The experience demonstrates an adjacent ability that could transfer, but doesn't prove the full capability.
Uncertain Evidence
The signal is potentially relevant, but there isn't enough information to know.
This is where the translation layer becomes particularly useful.
Instead of asking whether a resume contains the exact words from the JD, the system reasons about what the experience actually demonstrates.
Job titles, years of experience, tools, and industry labels are not automatically treated as proof.
The important question becomes:
What did this person actually do, own, handle, produce, or achieve?
Adding verification without making AI the decision-maker
Both the Job Interpreter and Evidence Mapper use lightweight grader agents.
Their purpose isn't to decide whether the pipeline succeeds or fails.
They exist to improve consistency.
Agent
↓
Grader
↓
Looks good? ── Yes → Continue
│
No
↓
Specific correction
↓
Agent revises
The grader looks for things such as unsupported assumptions, inflated evidence classifications, occupational stereotypes, or contradictions.
If the output still isn't perfect after several revisions, the pipeline remains optimistic and continues with the latest result.
The grader is a correction mechanism, not an authority.
Knowing when the AI should stop
Another important realization was that not every ambiguity should be sent to the recruiter.
A recruiter shouldn't be asked questions like:
"Is Technology A equivalent to Technology B?"
or:
"Would experience with this adjacent professional workflow demonstrate the same capability?"
Those are questions the system should resolve itself, using external research when necessary.
The recruiter should only be involved when there is consequential uncertainty about the actual job.
For example:
- Does this person merely execute a process, or are they expected to design it?
- Is something required on day one, or can it be learned?
- Does the role make the decision, or only recommend one?
- Would two interpretations materially change who qualifies?
That became the central decision gate.
The Trusted Hiring Model
The resulting workflow looks like this:
flowchart TD
JD[Job Description]
JD --> JI[Job Interpreter]
JI --> JG[Interpreter Grader]
JG -->|Needs correction| JI
JG -->|Acceptable| EM[Evidence Mapper]
EM --> EG[Evidence Mapper Grader]
EG -->|Needs correction| EM
EG -->|Acceptable| R[Main Reviewer]
R --> U{Consequential uncertainty?}
U -->|Yes| RD[Recruiter Dialogue]
RD --> R
U -->|No| F[Finalizer]
F --> THM[Trusted Hiring Model]
THM --> CA[Candidate Evidence Analysis]
CA --> EP[Candidate Evidence Profile]
EP --> GAP{Important evidence gap?}
GAP -->|Yes| V[Targeted Verification]
V --> EP
GAP -->|No| DB[Recruiter Decision Brief]
EP --> DB
DB --> DA[Optional Deeper Assessment]
DA --> INT[Interview]
The Trusted Hiring Model becomes the structured source of truth for evaluating candidates.
It contains the role's actual purpose and outcomes, required capabilities, acceptable evidence, equivalent experience, transferable evidence, and unresolved areas that may need verification.
Only after that model exists does candidate evaluation begin.
Candidate assessment becomes evidence resolution
This also changes what candidate screening looks like.
Instead of assigning someone a mysterious AI score like:
87% match
the system builds an evidence profile.
For every required capability:
Capability
↓
Candidate evidence
↓
Direct / Strongly Implied / Transferable / Uncertain / Missing
If an important capability remains uncertain, the system identifies the strongest consequential evidence gap.
Rather than forcing every applicant through a long assessment, it can ask one targeted verification question.
Ideally, that interaction takes only a few minutes.
The question is based on the candidate's actual experience and the specific evidence that is missing.
After the response, the evidence profile is updated.
A deeper assessment is only necessary when it would actually add useful signal.
The product changed when the problem changed
The original idea was essentially:
Use AI to screen candidates more intelligently.
The idea eventually became:
Build a trusted representation of the job first, then evaluate candidate evidence against that representation.
That distinction matters.
The system isn't trying to replace recruiter judgment.
It's trying to make sure the recruiter, the job, and the candidate are actually talking about the same thing.
The pipeline became less about automated ranking and more about reducing information loss:
What the company needs
↓
What the job actually requires
↓
What capabilities satisfy it
↓
What evidence proves those capabilities
↓
What the candidate actually demonstrates
↓
What still needs verification
↓
Human hiring decision
That's the idea behind the Trusted Hiring Model:
A translation layer that turns imperfect hiring information into evidence a human can make a decision with.