Verified mechanics in our offline synthetic workflow. No real-resume accuracy claim.
Screening got faster. The record did not.
When a screening decision draws a "why" question, its evidence can be scattered across a score, a recruiter's notes and a spreadsheet. RecrewOS is being built to keep that reasoning together.
- An 82% match scoreNo reasons attached. Nobody can say which words in the resume moved it.
- A recruiter's note"Not senior enough." Written in a hurry, in a different tool.
- A rubric that changed last monthNo version history, so the criteria used on the day are lost.
- A rejection emailGeneric, sent automatically, approved by nobody in particular.
- Three weeks of diggingWhen legal or the candidate asks, someone reconstructs it from memory.
- Quoted evidenceThe exact resume lines behind each criterion, with location, split into supporting, contradicting and missing.
- Arithmetic you can redoLevel times weight for each criterion, summed in the open.
- The rubric version in forceLocked when it was approved, with the reason each criterion is job related.
- A named reviewerWho decided, when, and what they saw.
- Inspectable historyReview the recorded evidence and decisions locally. Portable exports and cryptographic verification are planned.
From job description to reviewable decision.
A preview of the workflow we are building. Evidence location, arithmetic and human routing run offline; the planned import and rubric-drafting screens are illustrations.
Illustrative example. Fictional people, roles and records; not live product screens.
Approve the rubric before anyone is scored.
Drafting a rubric from a pasted job description is planned. The offline workflow already uses versioned rubrics. The proposed drafting screen will let a reviewer define criteria, weights, requirements and job-related reasons before approval.
- In development: the internal offline check blocks "recent graduate" and warns on "culture fit". It is not a fairness guarantee.
- Required criteria with no evidence trigger human review; they never silently determine rejection
- Every change creates a new version; old decisions keep the version they used
| Criterion | Weight | Required | Why it is job related |
|---|---|---|---|
| Data pipelines | 3 | Yes | Owns daily ingestion into the warehouse |
| Production engineering | 3 | Yes | On call for services the team ships |
| Evaluation practice | 2 | Yes | Measures data quality before release |
| Ownership signals | 1 | No | Leads projects with unclear scope |
Import is planned. Failures stay visible.
A customer upload screen is planned. PDF and DOCX parsing has been exercised with synthetic files only. Internal normalization supports contact redaction before extraction; no real provider or customer-resume processing is connected.
- Synthetic-file checks distinguish missing text, password protection and parse failures
- Possible duplicates route to human review in the offline workflow
- The offline scheduler bounds concurrency; customer throughput has not been measured
Read the evidence, not a percentage.
In the offline workflow, each candidate has a packet: the resume lines that support each criterion, the lines that contradict a claim, and the criteria with no evidence at all. Gaps are explicit human-review tasks. The illustrated arithmetic is not a hiring decision.
- Click any quote to see it highlighted in the original resume
- Contradictions, such as a claimed title that dates do not support, are surfaced on their own
- Confidence comes from how much evidence was found, not from the model's opinion of itself
Explain a rejection in plain words.
In development: an internal offline feature fills a deterministic explanation from record fields after a reviewer decides not to advance someone. The AI does not write the reason. Customer delivery is planned and is not connected.
- Every sentence links back to the field it came from
- Internal approval checks keep the explanation tied to the recorded decision
- The offline record retains the approved draft; sending to candidates is planned
Thank you for applying for the Data Engineer role.
We reviewed your application against the criteria for this role (rubric version 4). Your resume showed strong experience in data pipelines. We did not find evidence of evaluation practice, which this role requires.
This decision was reviewed by M. Ortiz on October 14, 2026.
A history you can inspect.
The offline workflow records events for inspection. A tamper-evident hash chain and signed daily or nightly checkpoints are planned, not implemented. The current local history is not cryptographic proof against alteration.
- Planned: verification that detects altered or reordered events
- Planned: customer-held signed checkpoints and a verification key
- Planned: retention and erasure controls, with a reviewable history
Every claim points to a line.
Match scores ask you to trust a number. RecrewOS shows you the sentence. Each quote is checked against the resume before it is shown, and any quote that cannot be found is dropped and counted against confidence.
- Supporting, contradicting and missing evidence, kept apart
- Character-level location for every quote
- Evidence corrections retain the original in the offline record
A score you can redo by hand.
There is no gauge, badge or grade anywhere in RecrewOS. The total is level times weight for each criterion, added up in plain view, so a hiring manager can disagree with a specific line instead of a mystery number.
- Weights are set by you, in the rubric, not by the model
- Versioned rubric weights make score changes inspectable offline
- Same inputs always produce the same score
Uncertainty goes to a person.
When evidence is missing, contradictory or unreadable, RecrewOS does not guess. It opens a task with a named reason and puts it in front of a reviewer. A failed requirement is visible to the reviewer; "unknown" routes to a human. People make the hiring decision.
- Eight specific routing reasons, each with its own task
- Re-extraction creates a new result and retains the original. Closing a task does not change evidence or scores.
- Candidate delivery is planned; no messages are sent by the current workflow
Candidate data, handled like evidence.
These are planned safeguards, not available customer features. Today the application runs locally on fictional data. Security, hosting and data-handling controls must be completed before any customer-data pilot.
One record, four kinds of reader.
Review the reasoning behind a screening decision. The offline workflow brings evidence and reviewer decisions together; team reporting and exports are planned.
Focus: decision records; retention and erasure plannedInspect quoted evidence and route gaps to people. Customer time savings have not been measured; the current demonstration uses fictional applicants.
Focus: packets and routing; upload screen plannedHelp define which records counsel needs to review. Signing, exports and customer compliance workflows remain planned and require professional review.
Planned: signed checkpoints and exportsSee why a candidate is in front of you and where the gaps are, so the interview probes what the resume could not show.
Offline preview: candidate packets and gap listsNew AI hiring rules. Plan for the record.
We are considering hiring rules, including Colorado's, while designing notice, explanation, human review and record-keeping workflows. Counsel must determine which requirements apply before a customer launch.
RecrewOS is in development; it does not make you compliant and is not legal advice. Responsibility stays with the employer.
We open with what it gets wrong.
Synthetic verification checks engineering behavior, not hiring accuracy or fairness. No real-resume accuracy study has been completed, and the customer workflow is still in development.
In synthetic-file tests, scans without a text layer are not read. They become named tasks for a person; no customer upload screen exists yet.
The proxy-term check is in development as an internal offline feature. It is a first filter, not a fairness guarantee; rubric review still needs a person.
Real-resume accuracy is unmeasured. Before making accuracy claims, we will evaluate against practitioner labels and report sample sizes, uncertainty and limitations.
RecrewOS records the screening it performs. It does not yet capture other tools' decisions.
Help shape it. Review the workflow.
We are inviting employers to help shape RecrewOS around their screening workflows. In private development. Design partners get early access; customer-data pilots depend on security, legal and product readiness.
See walkthrough details- Planned: collaborative role and rubric setup
- Planned: a role-specific evaluation after data-use approval
- A say in what we build next
- Proposed pilot pricing, with terms to be agreed
- A discussion of two or three roles; no real resumes needed now
- A 30-minute check-in every two weeks
- Honest feedback, including what does not work
“An unexplained score adds a step instead of removing one. The explanation is the product.”THE RECREWOS DESIGN PRINCIPLE
Start with a pilot. Keep the record.
Proposed pricing for future pilots, not a live offer. Availability, limits and terms are not final. Customer isolation, encryption, exports and integrations are planned, not included features available today.
Pilot planned
- Proposed: up to 3 open roles
- Proposed: up to 1,000 candidates
- Planned: collaborative rubric setup
- Planned: role-specific evaluation
Team planned
- Role and candidate limits to be agreed
- Customer decision workflow in development
- Planned: export, retention and erasure
- Planned: signed daily checkpoints
Organization planned
- Proposed: multiple-team support
- Planned: ATS connection
- Planned: security review support
- Planned: custom retention policies
You've got questions. We've got answers.
Does the AI decide who gets rejected?
No. In the offline workflow, recorded extraction output proposes quotes. Each is located in the source or dropped, and plain code computes scores from rubric levels and weights. Live model extraction is planned. People make hiring decisions. Customer messaging is not connected.
Will this make us compliant with Colorado's law?
No. RecrewOS is in development and is not legal advice. Notice, customer delivery and retention controls are planned. Your counsel must determine applicable obligations and whether the completed workflow supports them.
How is this different from the AI matching in our ATS?
Our focus is inspectable evidence, visible arithmetic and a human decision record. The current workflow is an offline demonstration, not a connected ATS service. ATS integrations are planned.
Where is candidate data stored?
Today the application runs locally with fictional data only. Customer hosting, isolated instances, per-candidate encryption and key-destroying erasure are planned and need implementation and review before customer data is accepted.
Does the AI model train on our data?
No live provider is connected and no real candidate data is being sent. Before any customer-data transfer, we will review provider terms, training restrictions and data-processing agreements. There is no contracted provider or customer DPA today.
What happens with resumes it cannot read?
In synthetic-file tests, unreadable, password-protected or corrupt files become named review tasks rather than silent rejections. Possible duplicates also route for review. A customer upload screen is not built yet.
Do you integrate with our ATS?
Not yet. ATS connections and a customer upload screen are planned. Parsing and import checks currently run offline with synthetic files.
How accurate is it?
We have not evaluated accuracy on real resumes. Synthetic verification, including a 1,000-record replay, checks pipeline behavior, not whether it selects the best hire. Practitioner-labeled evaluation is needed before making accuracy claims.
How long does setup take?
Customer setup time has not been measured. Job-description drafting and customer uploads are planned. The current demonstration uses fictional records; pilot scope and timing will be agreed after readiness checks.
