How to keep AI-written job applications grounded in your real experience

A polished application can still leave you with a problem. If the résumé says you led work that you only contributed to, or turns a prototype into a launch, the prose may get you into a conversation you cannot comfortably finish. The useful question is not how confident the document sounds. It is whether every claim has somewhere real to come from.

One failure from jobhunt's model evaluations made this concrete. A synthetic interview persona said they wanted a Principal Engineer role. One otherwise strong candidate model praised their pipeline work as “exactly the kind of deep technical ownership that lands at Principal level.” The persona had not made that claim. The model had taken a target, graded the person's experience against it, and presented the grade as encouragement.

We changed the interview instructions so Coach, jobhunt's assistant, could reflect a person's target level without asserting that their work qualified at that level. Later evaluations got rid of the hard “lands at” version, although some softer seniority framing still appeared. We kept that limitation in the evaluation record. A grounded system needs tests for the tempting mistakes, plus a record of the ones that have not disappeared completely.

Start with a record, not a blank prompt

jobhunt begins with an interview about the person's actual work. The resulting profile keeps projects, scope, numbers, uncertainty, and the difference between individual and team work. A person can also record specific red lines, such as a title they did not hold or a technology they only touched briefly. Those red lines are carried into fit analysis and document generation as constraints.

That gives the writing system something more useful than a short résumé and a job posting. If a metric was never recorded, the document should not invent one. If a project stopped at a prototype, the description should keep that boundary. If the person says they contributed to a design owned by someone else, “led the design” is unavailable no matter how closely it matches the posting.

The fit analysis uses the profile and the supplied job description. It leads with real strengths, then separates ordinary gaps from genuine blockers such as a required licence or work authorization the person does not have. It does not make the application decision. That remains with the person running the search.

Keep the generated document bounded by the record

When jobhunt drafts a résumé or cover letter, the profile is the source for claims about the candidate. The job description can guide relevance and wording, but it is evidence about the employer's needs, not evidence that the candidate has a skill.

This distinction matters because plausible additions are easy to miss. “Improved performance” can become a precise percentage. “Helped with the migration” can become ownership. Work that reached a demo can become work used in production. The document may read better after each change while becoming harder for the candidate to defend.

There is no promise here that a grounded document will clear an applicant-tracking system or win an interview. Different employers use different screens, and jobhunt's ATS validation work is still in progress. The narrower claim is the one the system can support: it can organize relevant, recorded experience without treating the posting as permission to add facts.

Use a separate check, and say what it cannot do

After jobhunt generates a résumé or cover letter, a separate pass reviews the finished document against the composed profile, the uploaded résumé text when available, and the target job description. That pass may use a separately configured validation model or the same main model. “Separate pass” describes the workflow; it does not guarantee a second opinion from a different model.

When the check finds a claim it cannot support, jobhunt flags it for review next to the document. It does not silently rewrite the file, because a false positive could remove something true. A finding by itself does not block access to the PDF.

For ordinary failures of the check, the PDF remains available and the result says that the automated check did not run. If the validation response is cut off at its output limit, jobhunt handles it more strictly: it discards the unfinished verdict, aborts finalization, and no PDF is delivered from that attempt. That distinction keeps an incomplete check from being mistaken for a clean one.

The check is advisory, not a certification. Evaluations use planted unsupported claims and known-supported traps because both misses and false alarms are possible. A clean result is useful evidence that the pass found no issue. It is not a guarantee that every sentence is correct.

The practical habit is simple: keep the source record specific, preserve the awkward boundaries, and read every flagged claim before sending. Then read the unflagged ones too. The application still belongs to the person whose name is on it.