Stages are yours. Gates are not negotiable.

A held candidate is the gate working, not a bug. Every gate is enforced where the rule lives, so bypassing the interface with a valid token does not bypass it.

your stages, per verticalin-flight roles stay pinnedproven score is insert-onlypass mark pinned per run

role · applicant board YOUR STAGES

Real product screens. Figures shown in them are seed data from a demo workspace, not customer results.

The rail

Six stages here. Yours might be nine.

Stages come from a pipeline template you configure, per vertical or role type. What matters is what sits between them.

Applied no gate

Screened GATE screening knockout raises a review task

Assessment GATE minimum measured score, enforced in the core

Interview GATE a round can require feedback before anyone advances

Offer GATE approval above your configured threshold

Joined no gate

Fig 1 Illustrative stages. A rejection always needs a reason, and if the candidate came from an agency it needs feedback for that agency too, so partners actually learn what you want.

Requisitions

The system proposes. You approve.

Paste the JD. It becomes a weighted list of must-haves, should-haves and nice-to-haves, as a draft. You see every requirement and every weight, fix what is wrong, and decide what is a dealbreaker before anything is scored against it.

“5+ years React” stays five yearsNever quietly softened into a preference.

“Rs. 18,00,000” reads as ₹18 lakhNot eighteen thousand. A salary factor that misreads the number poisons the whole score.

An unreadable JD creates nothingYou get a task saying so, rather than a half-built role quietly scoring everyone against an empty spec.

Sign-off where you want itSome role types can require a manager's approval before publishing. Simple ones just go live.

Requisition approval settings, showing which roles need sign-off before publishing

Assessments

Anyone can type React. 0.42 is what they actually know.

When a candidate reaches an assessment stage, a test is generated from your blueprint and the recruiter reviews and edits it before it is sent. The result comes back as a measured score that replaces the CV's claim inside the ranking arithmetic.

Generating an assessment, with sections, difficulty, duration and proctoring from the blueprint

Sections, difficulty, duration and proctoring come from your blueprint, and are editable here before anything is sent.

Insert-onlyThere is no code path that edits a result. A re-grade is a new assessment, and both stay visible.

Judged against the bar in force thenThe pass mark is computed and pinned per run, so it cannot be moved retroactively. A run with no pinned bar shows no verdict rather than a fail.

Below the minimum, they are heldNot by greying out a button. Moving them on by any other route is refused too.

Carried across roles, in your workspace“Rejected for Team Leader, right for Program Advisor” is one tap: a fresh application carrying the result, leaving the original rejection exactly as it was.

What this part does not do

Worth knowing before the demo, not after.

✕No auto-advancing stages the setting exists but nothing reads it

✕No scorecard carry-forward between rounds authored by a checkbox, read by nothing

✕You cannot edit a measured score a re-grade is a new assessment

✕Screening questions are not version-pinned editing mid-role changes the rules in flight

✕Proctoring config never reaches the vendor proctoring is a Paraakh claim, not this one

✕No per-skill proof of every skill the vendor emits grouped keys, and we say so

Keep going

The rest of the record.

Candidate intake Four doors in, duplicate checking, the talent pool The score receipt Seven factors, and why the number equals the table Interviews Rounds, panels, scorecards, and no calendar engine Offers & joining Approvals, two guards on the amount, onboarding Ownership & fees Who submitted first, and who gets paid Action Inbox 37 task kinds, routing, and one-tap confirmations

Book a demo → All 18 areas