Ask AI to "compare this resume against the JD," and you'll get impressively polished results. The problem? Half of it is fabricated.

This was the first wall I hit building Candidate Analyzer. The AI would generate analysis results that added experience not on the resume, or invented JD requirements that didn't exist. On the surface, it looked professional and logical -- but it wasn't factual.

What happens when non-factual information creeps into talent analysis? The recruiter recommends candidates based on false evidence. That's not a product -- that's an incident.

Ask It to Do Everything at Once, and It Lies

The initial approach was simple. Give the AI a resume and JD simultaneously, and ask "analyze whether this candidate is suitable for this position" in a single request.

The result was impressive. Strengths, weaknesses, match rate, recommendation comments -- all neatly organized in a polished report. Even with my 12 years of recruiting experience, my first reaction was "oh, this looks pretty good."

Then I pulled out the original resume and cross-referenced. The problems started surfacing.

Why does this happen? Because AI is trained to produce "plausible-sounding answers." When processing a resume and JD simultaneously, the AI tries to bridge gaps between them. In that process, it generates information that doesn't exist. From the AI's perspective, it's manufacturing evidence to support the conclusion that "this candidate matches the JD well."

Why We Split It into 3 Stages

The solution was surprisingly simple. Don't ask it to do everything at once.

When you tell AI to "analyze," it tries to extract, structure, compare, and judge all at once. In this process, the boundaries between steps collapse, and input data mixes with output data. The distinction between "what was read from the resume" and "what the AI invented" disappears.

So we separated the pipeline into 3 stages. Each stage runs independently, and only the output of the previous stage feeds into the next.

The core principle is straightforward. Radically constrain what AI can do at each stage. Stage 1 only "extracts." No judgment. Stage 2 only "structures." No interpretation. Judgment and interpretation are only permitted in Stage 3, and even then, it's forced to use only the outputs from Stages 1 and 2.

Stage 1: Extract Facts Only

The first stage extracts only facts from the resume. By "facts," I mean information that is explicitly stated on the resume.

An ultra-conservative Temperature setting is essentially telling the AI "absolutely do not think creatively." If the resume says "Python 3 years," the output says exactly "Python 3 years." It won't inflate it to "Python and related library experience."

If the AI adds information that doesn't exist in the original resume at this stage, every subsequent analysis gets contaminated. That's why the prompt explicitly enforces: "Do not add any information not explicitly stated in the resume." The combination of conservative Temperature and this prompt is the core of Stage 1.

Stage 2: Structuring the JD

The second stage structures the JD (Job Description). JDs are actually quite unstructured documents. Some companies write clean bullet points, others write long prose, and some don't distinguish between required and preferred qualifications.

Stage 2 transforms these varied JD formats into a consistent requirements matrix.

The critical part is the "Not Specified" category. If the JD doesn't mention education requirements, it's classified as "Not Specified." A standard AI approach would infer "a position like this probably requires a bachelor's degree" and add it. Stage 2 doesn't infer. If it's not there, it's not there.

This stage also uses ultra-conservative Temperature settings. Extract only what's written in the JD text -- don't interpret. "Preferred" stays "preferred," "required" stays "required." From a recruiter's perspective, this distinction is critical. Failing to meet a preferred qualification shouldn't count against a candidate, but most existing tools can't make this distinction.

Stage 3: Fact-Based Matching

In the third stage, AI finally "analyzes." But this analysis doesn't see the original resume or the original JD. It only receives Stage 1's output (structured candidate data) and Stage 2's output (requirements matrix) as inputs.

This stage's Temperature is slightly higher than the extraction stages but still conservative. Matching analysis requires some degree of "interpretation" -- judging whether "this candidate's 3 years of AWS experience satisfies the JD's AWS requirement" requires understanding beyond simple keyword matching.

But this analysis-optimized setting remains conservative enough that the AI doesn't "creatively" interpret matches while still understanding context. This delicate balance is critical.

Temperature: The Key

Temperature is AI's "creativity dial." Closer to 0, it produces only the highest-probability answers. Closer to 1, it generates diverse (sometimes nonsensical) responses.

Most AI services default to a Temperature of 0.7-1.0. Fine for chatting, writing, and ideation, but a disaster for fact-based analysis.

In CA, two-thirds of the analysis pipeline runs at ultra-conservative Temperature. This is the technical implementation of the principle "if it's not accurate, don't build it."

Verification Must Be Structural

"Trust but verify" is common advice for AI. It's sound advice, but having humans verify every result is impractical. For a recruiter running dozens of analyses per day, "manually cross-reference every AI output against the original" isn't a tool -- it's a homework assignment.

So we embedded verification into the structure itself.

I won't claim this structure is perfect. As AI technology advances, hallucination itself may decrease, and better methods may emerge. But right now, in a production environment, handling real hiring data while maintaining a 0% hallucination rate -- that means this structure works.

It's not technically groundbreaking. "Split it up and constrain what each stage can do." That's the whole thing. But consistently applying this simple principle in a real product is harder than you'd think. The temptation of "it's faster and easier to just do it in one shot" is always there.

In the next post, I'll discuss the structural limitations of self-monitoring. Why we fired the CHRO from our 8-person AI executive team. And what "real checks and balances" actually means.