Vouch

Not what you wrote. How you wrote it.

Inspiration

Hiring has quietly broken on both sides of the funnel at the same time. A role that used to draw 30 applicants now draws 500, and a growing share of them are AI-generated, AI-polished, or outright fabricated — recruiters told us they're drowning, and the tools built to help them screen faster have no clear winner yet. On the other side, candidates are getting scammed by fake recruiters and impersonated employers, with no easy way to verify who's actually on the other end of an email.

We kept coming back to one observation: every existing "fix" tries to answer the wrong question. Tools that try to detect "AI-written text" are fighting a losing arms race — generation models improve faster than detectors can keep up, and worse, they punish honest candidates who used AI legitimately to polish a resume or overcome a language barrier. We didn't want to build another classifier that reads a paragraph and guesses. We wanted to find a signal that content itself can never fake.

That's when we landed on the idea that changed the whole direction of the project: don't read what someone wrote — watch how they wrote it. Keystroke rhythm, paste behavior, whether pasted text gets edited before submission — none of that shows up in the final text, and none of it is something a copy-pasted AI paragraph can fake on its own. From there, the rest of the system fell into place almost naturally: if the behavioral signal looks strongly automated, don't reject the person — just ask them one honest, on-the-spot question about their own experience and see if they can answer it like someone who actually lived it.

What it does

Tellsign is a lightweight trust layer that sits in front of a job application form and gives recruiters a transparent, explainable signal about how genuine a submission looks — without ever penalizing someone just for having used AI to help write.

On the applicant side, while someone fills out the free-text fields of an application, Tellsign silently captures:

Keystroke timing — the natural, irregular rhythm of a person typing versus the near-uniform intervals of scripted or automated input
Paste behavior — how long a field was focused before a paste landed, since someone who paused to think and then pasted a prepared answer behaves very differently from a script that pastes on focus, instantly, every time
Post-paste editing — whether pasted text gets touched up afterward. Real people editing their own prior writing almost always adjust it for the specific job; a dropped-in AI block usually goes in untouched

These signals feed a transparent, weighted scoring function — deliberately not a black box — that produces a composite human-likelihood score $S \in [0, 100]$:

$$ S = w_1 \cdot f_{\text{variance}}(\Delta t_{\text{keystroke}}) + w_2 \cdot f_{\text{timing}}(t_{\text{paste}}) + w_3 \cdot f_{\text{edit}}(d_{\text{edit}}) $$

where $\Delta t_{\text{keystroke}}$ is inter-keystroke interval variance, $t_{\text{paste}}$ is the time between field focus and a paste event, and $d_{\text{edit}}$ is the edit distance between pasted text and the final submitted text. Every score returned to a recruiter comes with the reasoning attached — which signals drove it — not just a number, because a defensible tool has to show its work.

When the score drops to 70 or below, rather than silently rejecting the application, Tellsign triggers a short, live conversational check: it generates a specific follow-up question drawn from the overlap between the applicant's resume, the job description, and what they wrote (never a generic "tell us about yourself"), gives them an 8-second window to respond out loud, transcribes it live in the browser, and scores whether the spoken answer adds coherent, specific, consistent detail — the way someone recalling a real memory naturally does, rather than reciting or vaguely restating what was already written.

The result, on the recruiter's side, is a single dashboard showing every submission's full reasoning chain end-to-end — form signals, explanation, and (when triggered) the challenge question, transcript, and follow-up score — plus a cohort view that flags clusters of submissions sharing suspiciously identical behavioral signatures, since a single bad actor can fake one convincing trace, but faking hundreds of distinct ones defeats the entire point of automating at scale.

How we built it

We used Claude Code as our primary build partner throughout the day, feeding it full-spec prompts up front rather than one feature at a time, which let it make consistent architectural decisions instead of bolting pieces on ad hoc.

Capture layer: vanilla JavaScript listening for keydown/keyup, paste, and focus/blur events on the application form's free-text fields, logging raw timestamps and computing edit distance between pasted and final text.
Scoring function: a plain, transparent weighted formula rather than a trained model — we had no labeled data and a matter of hours, and a formula we can explain out loud is more defensible than a model we can't.
AI narration: a call to the Claude API that takes the raw signal object and returns one plain-English sentence a non-technical recruiter can read at a glance, explaining what the pattern suggests without making the final call itself.
Conditional voice challenge: MediaRecorder and the Web Speech API for live, in-browser recording and transcription, paired with a Claude API call that generates a targeted follow-up question from the resume/JD/written-answer overlap, and a second call that scores the live transcript for specificity and consistency.
Dashboard: a simple, deliberately unglamorous table — color-coded scores, expandable rows showing the full reasoning chain, and a clustering view grouping submissions by behavioral similarity.

We made one decision early and stuck to it deliberately: no black-box scoring, anywhere. Every number the system produces is traceable back to a specific, explainable signal.

Challenges we faced

The hardest problem wasn't technical — it was resisting the urge to build things that would demo badly. Two ideas we seriously considered and explicitly cut:

Deepfake video/voice-authenticity detection. It's tempting to say "we also detect if the voice itself is AI-generated," but reliable synthetic-voice detection is a genuinely hard, actively-researched problem that dedicated companies build entire products around. A detector we hacked together in a few hours would have unknown accuracy, and the failure mode is bad — it could confidently flag a real person's genuine voice as fake, live, in front of judges. We chose to lean entirely on response timing and content relevance instead, which are both more reliable and, we'd argue, harder to fake anyway.
Blanket paste-flagging. Our first instinct was "paste = suspicious." We quickly realized that punishes completely legitimate behavior — people draft answers in Notes, reuse their own resume bullets, or aren't native English speakers and compose offline first. The fix was tracking post-paste editing behavior, not the paste event alone, which took real iteration to get right.

On the pure build side, getting the live in-browser speech transcription reliable took real testing — permissions and recognition behavior vary enough across browsers and networks that we made a point of testing the exact flow on our actual demo hardware rather than assuming it would carry over from development.

What we learned

The biggest lesson was architectural: the most defensible trust signal is the one content itself can't produce. Every team building a "detect AI text" tool is fighting the same model that's generating the text it's trying to detect — a race the detector is structurally destined to lose. Signals like typing rhythm, paste timing, and real-time recall under a short window live outside that race entirely, because they're properties of the process, not the product.

We also learned to be honest, out loud, about what we chose not to build. Naming the deepfake-detection idea and explaining why we cut it turned out to be a stronger moment in our pitch than pretending we'd solved something we hadn't.

What's next

Calibrating the scoring weights and the 70-point challenge threshold against real labeled data instead of hand-tuned defaults
Extending the cohort-clustering view into a live, continuously updating fraud-ring detector rather than a static post-hoc view
Exploring the DNS-based employer-attestation idea we scoped early on, to address the outbound half of the trust problem — verifying that a recruiter reaching out to a candidate is who they claim to be — as a complementary product, not a replacement for this one