Trust the receipt. Filter the slop.
Inbound applications carry verifiable authorship signals. Reframed Verify reads them, scores them, and writes the result back into your ATS. The trust layer between applicants and your inbox.
Your inbox got 5x in the last 12 months. Most of it isn't real.
Generative tools made it free to fire 200 applications in an hour. Recruiters drown. ATS scoring catches keyword stuffing but not voice-flat slop. The signal-to-noise problem is structural.
Reframed Verify gives you signal that doesn't exist anywhere else: a verifiable claim from the candidate that they wrote what they sent. Receipts are issued at generation time, signed with ed25519, and verified against a public key. Tamper-evident. Cannot be faked.
Example values, taken from a receipt you can open: /verify/example
Every applicant pretending to use tools is making the next applicant's resume look generated. Reframed flips the script.
Verifiable authorship is the new credential. The receipt doesn't say “a model helped.” It says how much is yours, signed and timestamped, before you hit send. That's the thing recruiters are missing. Not another slop filter. Proof.
No funded round. No enterprise customers yet. Built by ICs who got tired of the slop wave and thought the honest path deserved better tooling. Reach out if you want to shape the early product.
Three tiers. All start with a real conversation.
For independent recruiters and small teams triaging in email or spreadsheets.
- ·Receipt lookup by email, tailor ID, or verify URL
- ·Dashboard with verification history
- ·Verification history across your pipeline
- ·Public verify URL for every receipt — share with clients
- ·Signature checked against the published key, no account needed
For talent orgs at scale, agencies, and groups with compliance requirements.
- ·Volume lookups
- ·Single sign-on
- ·Support terms in writing
- ·Receipts verified on your own domain
- ·Audit logs
Native integrations. Zero scrape.
We register OAuth apps in your ATS so verification happens server-side. No browser extensions you have to install on every recruiter's laptop, no scraping that breaks when the ATS ships a UI change.
| Platform | Status | Pattern |
|---|---|---|
| Ashby | Roadmap | Partner program — not yet applied |
| Lever | Roadmap | OAuth + signed webhooks — not started |
| Greenhouse | Roadmap | Harvest API — not started |
| Workable | Roadmap | OAuth, event-driven webhooks |
| SmartRecruiters | Roadmap | Marketplace partner OAuth |
| Workday | Roadmap | Innovation Partner Program |
| iCIMS | Roadmap | Marketplace integration |
| Bullhorn | Roadmap | REST API + agency tier |
Don't see your ATS? Talk to us — partner-program approval typically takes 4-8 weeks; we sequence based on customer demand.
Verification, exposed to your agent.
Your team uses Claude Code, Cursor, custom agents to triage hundreds of inbounds. Thereframed-recruiter-mcppackage gives any LLM-driven workflow native verification tools.
Position: verification data for your agent, not a screening filter. Your process consumes the score; you decide what advances. Avoids the automated adverse-action minefield.
Four properties. Architecturally enforced.
Issued server-side at generation time
The Ed25519 signing key lives in server environment and is never handed to a browser, so a candidate cannot mint a receipt for themselves. Receipts are issued by the tailoring pipeline, not requested.
Public verification, no Reframed account needed
The signing key's public half is published at /.well-known/honesty-receipt-keys.json. Anyone holding the receipt JSON can check the signature offline, with no call to us and no account.
Any edit breaks the signature
The signature covers a canonical serialization of the whole receipt — the percentages, every classified line, the timestamp. Change one number and verification returns false. There is no partial pass.
Recruiter-side cannot issue receipts
Nothing on the verification path can sign. A recruiter looks a receipt up and checks it; there is no endpoint that mints one for a candidate.
Receipts are retained 90 days
Hosted lookup at /verify/{id} expires after 90 days — long enough for a search, not forever. The receipt JSON itself stays verifiable against the published key for as long as you keep a copy.
What recruiters ask before signing.
Can I issue receipts on behalf of candidates?
No. Receipts are signed at generation time using the candidate's email account. The hash is bound to the resume content. Recruiters cannot mint receipts — only verify them. This is the load-bearing trust property: a receipt is the candidate's claim, not yours.
What does 'slop detection' actually catch?
Resumes that read as generated even if no receipt is present. Looks at voice flatness, generic phrasing density, suspicious structural patterns, and consistency markers. Returns a score 0-100 with a confidence band. Independent signal from receipt presence.
How will the ATS write-back work?
Designed pattern: we register an OAuth app in your ATS, you authorize, we subscribe to the inbound-application webhook. On every new application, we verify the receipt (if present) and write reframed_receipt_verified: true/false plus authorship_score: 0-100 to a custom field on the candidate record. Your ATS stays the source of truth; we enrich it. Status: this is a design, not a build. No integration code exists, no partner application has been filed, and every one of these programs requires a shared customer before it opens. Treat it as a direction, not a date.
Is this legal for screening?
Receipt verification is a signal, not a filter. We position Verify as enrichment data your existing process consumes — same as any background-check or skills-test integration. Full automated adverse action is on you to handle compliantly per your jurisdiction. We surface the data; you decide what to do with it.
What happens if a candidate edits their resume after the receipt is issued?
The receipt still verifies, because it attests to what the engine produced at that timestamp — it is not bound to the file you were sent. So a receipt tells you what left Reframed and when; it does not prove the attached document is that same document. Compare the lines in the receipt against the resume in your hand.
Do candidates know we're checking?
The verify URL is public — anyone with the receipt URL can check it. Candidates expect verification when they include the receipt; that's the point. We don't notify candidates when a recruiter checks. Verification is silent.
What about candidates who don't use Reframed?
Slop detection runs on any resume, receipt or not. You get a score on every inbound. The receipt is a positive signal when present; absence isn't a negative signal in itself. The combination is what matters: high slop score + no receipt = high confidence the resume is generated.
How does this differ from a generated-text detector?
Detectors guess after the fact, and they guess badly — a plain writer gets flagged, a careful faker doesn't. A receipt is issued at the moment the resume is made, so there is nothing to guess at: it states what came from the applicant's own history and what was shaped for the role. Where no receipt exists you are back to reading the resume, and slop detection is only a hint.
Can I get a demo or a sandbox?
Yes. Receipt lookup and public verify URLs work today — one receipt at a time. See /verify/example for a real signed one. Batch lookup and write-back into an ATS do not exist yet.
Check the receipt. Skip the guesswork.
Receipt verification and the dashboard work today, one receipt at a time. Tell us how your pipeline runs and pricing comes back fitted to it.