Open the role
Most hiring goes wrong at the brief, not at the shortlist.
Forty words of job description, half of them boilerplate, and a kick-off call everyone remembers differently.
Everything downstream inherits that — the search, the screening, the questions asked in the room, and eventually the argument about why the shortlist missed.
What it produces
A ledger, not a blob of text.
The description is read section by section — business context, role purpose, responsibilities, the capabilities actually required, seniority and scope, what success looks like. Each reading carries the evidence behind it, attributed to the text it came from. Each section gets a coverage score. What is missing is named rather than glossed.
Senior Warehouse Manager, Pune. Own P&L for a 40,000 sq ft facility. Must have run WMS migrations. Team of 30+ across three shifts. Regulated-goods handling essential. Competitive package.
Forty-one words. Most trackers store this as a blob of text and match keywords against it.
- Business context92
- Role purpose88
- Responsibilities95
- Capabilities required74
- Seniority and scope41
- Success in the first year18
Two gaps, named
- Does “regulated goods” mean pharma cold-chain, or hazardous materials?
- Is the team of 30 direct reports, or across three shift supervisors?
→ sent to the hiring manager as a link. Their answers become version 2.
The part nobody else does
It asks the hiring manager about exactly what is missing.
A gap the system can name is a gap it can ask about. The hiring manager gets a link — no login — and an adaptive conversation that works through the specific ambiguities, not a generic intake form. Their answers become the next version of the ledger, with the version history kept.
It stops when the ambiguities are resolved rather than when a form ends, which is why hiring managers finish it. Today it runs on roles; the same shape aimed at a candidate with a thin CV is not shipped, and we are not going to describe it as though it were.
- Versioned —
Version one is what the document said. Version two is what the document plus the hiring manager said. You can see which is which.
- Evidence-attributed —
Every reading points at the text that produced it, so a reading you disagree with can be checked rather than argued about.
- It works on any role family —
It is reading the document rather than matching a taxonomy of job titles, so a plant manager, a staff nurse and a data engineer all go through the same machinery.
- No login for the participant —
A magic link, scoped to that one conversation, that expires.
What intake teams ask
Including where it stops.
›Does this replace the intake call?
No — it makes the intake call shorter and more specific. You arrive knowing which six things are ambiguous instead of running through a checklist that covers what you already understood.
›What if the hiring manager ignores the link?
Then you work from version one, with the gaps visible on the role rather than discovered at shortlist. Nothing is blocked; you just know what you do not know.
›Is this only for technology roles?
No. The reading is of the document, not of a job-title taxonomy. It runs the same way on operations, finance, healthcare and field roles.
›Can we correct what it understood?
You correct the role's fields on the requisition, and those corrections are captured and read as true by the next extraction in your workspace. The ledger itself is not edited in place — it is rebuilt from the document plus the conversation, which is what keeps version one and version two meaningfully different.
›Does it run on candidates too?
Not today. Roles only. The candidate-side version exists as a design and not as a screen.
Book a demo
Paste a real job description on the call.
Bring the thinnest brief you have been sent this month. The interesting part is which gaps it names.