Scout

Between March and May 2026 I built two resume tools, one after the other: resume-tailor, nine versions, and then Hunter, from v1 to v5.10. Hunter was a five-stage AI pipeline — it read a job description, generated bullets, had a second model critique them, assembled the page and scored it for applicant-tracking systems. It worked. The PDFs came out, and they often read well.

I stopped trusting it anyway, and the reason is the whole story. Section 3 is what died. Sections 4 to 8 are the rules that replaced it, each of which exists because I watched the alternative fail — including one feature I built, measured, and then retired because nobody, including me, ever used it.

This is a tool study with one user, and that user is me. I haven't hidden that in the limitations: the research here is measurement of what the tool actually did, not interviews. What I can offer instead is a complete record — every decision written down on the day it was made, with what lost and why.

Three bugs killed Hunter, and all three turned out to be properties of generation rather than problems a better prompt could fix:

• It invented. A model writing from context fills in numbers and scope. Some were close to true; closeness is not the standard for a resume.
• Bullet counts drifted. One role got three bullets, another got seven, run to run.
• It restated. Two bullets describing the same achievement in different words — which reads worse than either bullet alone, and tells a recruiter you're padding.

The critic was my fix, and it was the wrong one. A second model scoring the first one's output is a patch over the wrong primitive: it made the good runs better and did nothing to tell me which run was the bad one.

The measurable part is the size of it. The last version, Hunter v5.10, is 50 code files, with a model at five stages of the pipeline. And across April its own ATS score climbed from roughly 58 to roughly 92 — approximate figures, but the direction is the point. Over the same weeks, my trust in its output fell.

And the fix was already sitting inside Hunter's own data, unused. Its master resume stored every achievement several times, each version written by hand from a different angle — one achievement, told as impact, as process, as research. Which meant tailoring didn't need to write anything. It only needed to choose.

The rule has one enforcement point that matters more than the rest, and it's the one I'm proudest of. Every achievement in the corpus records the numbers and names it asserts — and the employer it belongs to. Anything that ever changes a bullet's wording is checked against that employer's facts, not against the whole corpus.

The obvious design pools everything I've ever verified and asks "is this in there?" It fails on a single sentence: "Supervised a team of 7–9, scheduling floor coverage in Figma." Every word in that line is somewhere in my record. Figma is all over it. It is true of my design job and false of my retail job, and a corpus-wide check waves it through without pausing. Scoping the check to the owner of the claim is what catches it.

Four of the check's first fifteen tests failed when I wrote them. Three were my expectations being wrong — the check was stricter than I'd predicted. One was a real defect: "scheduling" rewritten as "scheduled" was flagged as a new claim. It's a tense change, and a check that makes you sign off on every tense change gets rubber-stamped, which is worse than no check. So it learned to ignore inflection — and only inflection, because "negotiations" existing in my record is not the same as me having negotiated.

I wrote down what it can't catch, because a guard trusted past its range is worse than none. It catches invention. It can't catch distortion — two true claims welded into an implication neither makes, or "supervised" quietly becoming "managed". A person still reads the page.

On 28 August I built a resume for a customer-service role — outside design, which is the point: my corpus held design work, and this posting needed my retail years. It cost a whole session. This is my own account of what went wrong, next to what each thing actually was:

What I said	What it actually was
"Scout has a set of experience for me but it didn't want to take any more information"	The root cause. The corpus was closed
"Scout was building new layouts for my CSR resume"	A symptom. My retail jobs weren't in the corpus, so no template could render them, and a one-off layout got hand-built around the gap
"I had to explain a few times what I did in my retail experience as I didn't quite remember"	The real work. No tool had ever helped with recall
"The whole process was based on this chat window"	Where the cost landed. A chat holds no state, so the next application pays again from zero

The proof was sitting in the output. The most expensive thing that session produced — thirteen bullets of retail duties I'd had to remember — had been written into a throwaway file instead of the corpus. Harvesting them afterwards took a fraction of the time it took to recall them.

This is self-observation, n=1, and I've labelled it that way. It was also the most useful research the project did, because it pointed at a problem I'd never have designed for from the outside: recall. Nobody remembers what they did at a job two years ago on demand.

My first design was a worksheet: a list of questions per posting. It fails at recall. A form is excellent at collecting what you know you need, and useless for what you don't remember until something adapts to your last answer — "who did you escalate to when a customer wouldn't leave?" is only askable after hearing about the customer. A static list of twenty questions gets abandoned around question four. So the interview is a conversation.

The first reversal. I'd planned open questions only, to avoid putting words in my own mouth. But free recall returns the ordinary day — serving, stocking, closing. A one-off, like the afternoon the till broke and someone had to work out why, is never part of "walk me through a normal shift" — and the unusual events are exactly what's worth a line on a resume, because nobody else's shift contained them. Open questions come before cues, not instead of them.

The second reversal. Then I planned to hold every bullet down to my exact phrasing. It sounded safe and it fails every single time: people understate in conversation. Something like "yeah, I fixed the till a few times" is someone being brief, not making a careful claim, and a corpus that can never exceed it guarantees a resume weaker than the truth. So the line is narrower. Words for the activity — fixed, diagnosed, resolved — need only that it happened. Words for frequency or scale — "routinely", "across the store", "40+ incidents" — need a recorded fact, and the owner-scoped check from section 4 enforces it.

One rule survived both reversals: the posting is never shown during the interview. Gaps choose the topic — "the record is thin on your retail job, and this posting leans on service work" — but never the question. "Did you handle cash reconciliation?", asked of someone who wants the job, pulls toward yes.

My own words when the "label it and let me decide" version was proposed: "I would want the tool to try and do it itself since it's backed with Claude. But yes, final check can be done by me." A tool that hands the hard half of the work back to its user has only done the easy half.

The four rules, in order of how much work they do:

1. Every requirement starts as a gap. Something has to actively move it.
2. No "covered" without a cited bullet. A verdict that can't name its evidence drops to "gap" on its own. This is what makes checking it fast: read the requirement, read the one named bullet, agree or don't.
3. Every "covered" states its edge. "Covers handling upset customers; says nothing about doing it on phone or chat." The danger isn't the wrong call. It's the overconfident one.
4. The report counts its weak spots — for example, "9 requirements — 3 covered, 2 partial, 4 gaps. Two of the covered calls rest on a single bullet each." A tool that states its own composition is harder to over-read.

What it deliberately doesn't do: produce a match percentage. A number like "78% match" compresses a judgment into a figure that reads as measurement. Counts, yes. A score, no.

This doesn't make the verdict right. It will get calls wrong, mostly on the generous side, because shared vocabulary looks like shared meaning. What it does is make a wrong call visible in seconds instead of buried in a confident paragraph.

The feature was called adjacency: take a bullet about reviewing designs with clinicians and product managers, and reframe it as stakeholder handling for a service role. It was the capability I would have felt first. It was also the most dangerous thing in the project, because reframing "reviewed iterations with clinicians" as "handled customer escalations" is a lie in which no number changes. The check from section 4 would pass it.

Then the measurement:

14 tailored resumes — rewrites used in 0

Not one bullet reworded, by the tool or by me — and a month later the count is still zero. Building an automatic feeder for a channel nothing had put a single item into by hand was speculative by definition. And the need behind it was already met twice over: the coverage step reads my whole record and notices material that fits in different words, and the angles I'd written by hand are adjacency done in advance — by the only person who can tell whether the reframing is still true.

A retirement, not a deferral, on purpose. A deferred item sits at the bottom of a to-do list forever and gets re-proposed every time someone reads the plan. What would bring it back is written down: a real posting where my record provably covers a requirement and no existing bullet can say so.

The honest remainder: one field is still written fresh for every posting — the title line under my name, the first thing anyone reads after it. It is now the only place Scout writes anything, and it's guarded by a person, not the check. On 31 August the word "marketplace" nearly went into one with nothing in my record behind it.

What it can't do, stated plainly:

• One user. Every rule here was tested against my record and my job search. That it would work for someone else is a hypothesis — which is why the public version ships with an invented person whose tests pass without any of my data in the copy.
• Outcomes are thin. Two applications and one result prove nothing about whether a Scout resume gets more interviews than a hand-written one. What they prove is that it holds up in real use.
• The check catches invention, not distortion — section 4.
• The title line is written fresh every time, and no check guards it — section 8.
• The AI is the smallest part, and replaceable. The scripts make zero model calls; everything that needs judgment lives in four plain instruction files. That's why it can run on any AI agent with a file system — and why making it public was worth doing at all. Hunter was the inverse.

• "Most of the time" is a failure mode, not a success rate. If a user can't tell which output is the bad one, every output costs a full review. Designing that out beats improving the average.
• Put the constraint where the harm happens. A question can't invent a fact; a written answer can. A label can't stop a mistake; a rule about evidence can. Every strong decision in this project moved a guard from where it felt safe to where the damage actually occurs.
• Measure before you build the next layer. Zero rewrites across 14 resumes retired the most dangerous feature on the plan before it cost anything. The measurement was a single count.
• Refuse where the damage is permanent; warn where it isn't. A bad bullet in the corpus poisons every future resume, so Scout refuses it. A missing note in one run's record affects nothing else, so it doesn't. Same-shaped problem, very different blast radius.
• Fix the form, not the instance. When a heading pattern failed for the fourth time, patching that posting would have fixed 6 occurrences. Sweeping all 2,236 stored headings fixed 128 and broke none. The previous three fixes had each been the narrow kind.