Six days ago a company called TypeSafe released a model named Jev. I have had it running against real resumes since, and it is now built and tested into Ryzio as a second safety layer.

I went in expecting it to make things faster. That turned out to be the wrong question, and the right one was sitting one layer down.

The unusual thing about Jev

Most AI models write. You ask, they produce sentences, and your code has to read those sentences and hope they are shaped the way you asked for.

Jev does not write anything. You hand it some information and a set of questions with fixed answer shapes: pick one of these, rate this, is this true. It hands back answers your code can use directly, each with a number saying how sure it is.

That sounds like a limitation. It is the whole design. Nothing is written, so there is nothing to parse, nothing to validate, and no invented sentence to catch. It is also fast and close to free.

What Ryzio already does

Ryzio is the resume and job search tool I build. You upload a resume, optionally paste a job posting, and it comes back rewritten and scored. Two AI calls do the heavy lifting: one reads your file into structured data, the other rewrites it. Everything else is my own code, including the scoring, which is fixed. Same resume, same score, every point traceable to a written rule.

It already has a guard against invented content. An AI rewriting someone’s resume can add things, and an invented line on a resume is not a typo. It is the question a recruiter asks in an interview that the candidate cannot answer. So before anything is shown, the guard compares the original against the rewrite and catches content that got added: new bullets, entries that grew, sections that appeared. It does that job well, and it is still the only thing allowed to block a result.

What it was never built for is content that got altered. A bullet that stays one bullet, stays true underneath, and quietly gains a percentage nobody stated.

I measured before I changed anything

My first thought was speed, so I timed the existing thing first: seven real resumes, committed code, a clean copy so nothing half-finished could skew the result.

Ten point four seconds per resume. The two AI calls are ninety-nine percent of that. Every line of code I wrote myself, file reading and scoring and assembly combined, comes to 79 milliseconds.

Chart: 99.2 percent of an optimize run is two AI calls Jev cannot make, with everything it could replace totalling 79 milliseconds
Where the ten seconds actually goes.

Then I read the spec properly. Jev writes no text, and both of my calls need a model that can write: real names, real dates, new sentences. It cannot do either. The absolute most it could ever save me is those 79 milliseconds out of ten point four seconds.

That took an hour, and it killed the whole idea. It also pointed at the real one.

A different question needs a different check

Deciding whether a claim is backed by the source is a judgement call, and you cannot make it by comparing strings.

So I tested both layers against the same thing. I took every substantial bullet across the seven resumes, 122 of them, and inflated each one the way an over-eager rewrite actually inflates: a percentage nobody stated, a team size nobody mentioned, a market nobody operates in, a dollar figure from nowhere. The underlying claim stays true. Only the addition is invented, and the number of bullets never changes.

Then a control group: the same bullets reworded honestly, nothing invented. Neither layer should flag those.

The guard caught one, which is the expected result for a test built entirely out of the case it does not cover. Jev caught all 122, and flagged none of the honest ones.

Chart: across 122 real resume bullets each given one invented detail, the existing guard caught 1 and Jev caught 122, with zero false flags on 160 honest bullets
One versus 122, with no false alarms on the honest control group.

Then I nearly shipped the exact bug

Jev scores each claim between zero and one. Bullets lifted straight from someone’s own resume land between 0.94 and 0.99. Fully invented ones land between 0.01 and 0.03. Real bullets with a fake detail bolted on land between 0.02 and 0.70.

That is a wide gap, and the width is what made me careless.

I moved my “this is supported” line from 0.85 down to 0.7, to sit comfortably in the middle, and wrote a confident comment citing my own numbers. Those numbers came from three bullets per resume, and the highest I had seen was 0.29.

When I widened the test to all 122, one inflated bullet scored exactly 0.700. My new line passed it as supported.

Chart: invented bullets score 0.01 to 0.03, real bullets with an invented detail score 0.02 to 0.70, verbatim bullets score 0.94 to 0.99, with one fabrication landing at exactly 0.700
The separation, and the one that slipped through.

I had shipped the precise failure the thing exists to prevent, in the commit where I claimed to be calibrating against evidence. I put it back to 0.85, where that bullet lands in the uncertain band and gets surfaced for a human to look at.

A sample is enough to show something works. It is never enough to set a cutoff, because cutoffs live at the edge of the range and a small sample is almost all middle.

How the two layers sit together

They stack rather than replace. Jev reports, the guard still decides, and Jev never touches the rewrite or the score.

It costs about half a second on a ten second job and roughly a tenth of a cent per resume. If TypeSafe goes down or the model drifts, the extra warnings stop and nothing else about Ryzio changes. For something I have known about for six days, that felt like the right amount of trust to extend.

What I am not claiming

Seven resumes is not a study.

All four of those fake-detail patterns were mine. A real rewrite will invent in ways I did not think to imitate.

The honest bullets all came from resumes that parse cleanly, which is the easy case.

The half-second figure is arithmetic across two separate measurements, not one observed run, because there is no live call site yet. The cost is worked out from published pricing rather than measured.

And the one that matters most: the code is committed and tested, and it is not switched on for users yet. That is a sequencing decision rather than a technical blocker, but nobody using Ryzio today is protected by any of this.

This is a first attempt

Jev is six days old and I have used it in exactly one place, and I picked that place partly by accident, after the speed idea fell through.

What I actually want to know now is what else it is good for. Anywhere my code has to make a judgement and currently makes it with a string comparison or a hand-written rule is a candidate for the same treatment, and I have a list of those.

I am going to work through it, and I will write up whatever I learn.