Posting copy, with a language scan
Requisition, deterministic posting copy, and a rules-based exclusionary-language scan that reports rather than rewrites. A role cannot leave draft without a named human approver.
Works todayCannot reject a candidate. Cannot see a protected characteristic.Recruitment Specialist
Bharti cannot reject a candidate, because the database will not let the row exist.
A CHECK constraint refuses any stage transition where the actor is a machine and the move is adverse — not a setting, a row the database itself rejects. There is no protected-characteristic column anywhere in this product — no caste, religion, gender, age or marital status — so nothing a resume volunteers can ever become a scoring input, and the interview panel's own roundup view refuses to send a composite score even by accident.
What Bharti cannot do is on this page, first
An adverse move needs a named humanNo column for a protected characteristicNo average, ever, in the panel view
How it works
Post, screen fairly, decide together.
Three steps, and every one of them keeps a machine from being the actor on an adverse decision.
- 01
Post
Build a requisition and generate deterministic posting copy, with a rules-based scan for exclusionary language that reports what it found rather than silently rewriting your words. Every draft version and its flags are kept, and a role cannot leave draft without a named human approver.
- 02
Screen fairly
Search returns which fields matched a role's requirements, never a ranking, and refuses outright any query that selects on a protected characteristic. A screening run stores its reasons as separate factor rows with no score column anywhere — the number shown is recomputed from them and arrives with decision: null and decided_by: "human_required" on every response.
- 03
Decide together
Interview scorecards stay blind until every expected interviewer has submitted their own, keyed to the kit's own list rather than who happened to start one. The roundup view that follows shows raw per-interviewer evidence, and the route checks its own outgoing response for an average or a composite before it sends it — refusing to answer at all rather than let one through.
The boundary
A machine cannot reject anyone.
Bharti never makes or executes a hiring decision. No candidate is archived, rejected or deprioritised by a background job, a threshold rule or a scoring model without an explicit, logged human confirmation at the moment of that action — and that rule is enforced twice, once in application code and once as a constraint the database itself will not let anything bypass.
- bharti_stage_transitions carries a CHECK constraint that refuses the row combination actor_type='system' with to_stage_is_adverse=true. A rule can propose moving a candidate to an adverse stage all day; it cannot execute that move — the database refuses the row, not just the request, and an adverse move that does go through must name a human actor and carry a written reason.
- The service layer refuses the same move earlier, with a message a recruiter can act on — the constraint is the line that holds when nobody remembered to call the service.
- A denormalised flag on the transition row is what makes the guarantee row-level: a CHECK constraint cannot join to the stages table, so an automated archive is stopped at the write, not at a later read.
- Only one stage kind is treated as adverse and terminal at all — every other move, including a benign archive, is unaffected by the constraint.
Nowhere to go
No protected characteristic has anywhere to land.
The cheapest defence against a protected attribute becoming a scoring input is that the field has nowhere to be stored in the first place. There is no date_of_birth, gender, marital_status, caste, religion or photo_ref column anywhere in this module. Indian resumes routinely carry all of them, so a value that was never stored cannot become a scoring input, leak into an export, or be reverse-engineered out of an analytics breakdown. The one disability-adjacent table the law requires is deliberately unreachable from screening.
- Candidate search refuses any query that selects on a protected term, arriving through the same field the scorer already cannot see.
- Resume parsing withholds date of birth, gender and marital status even when the resume itself states them — Bharti receives only its own candidate columns.
- bharti_accommodation_requests is the one RPwD Act table that exists, and it is unreachable from screening by construction, not by convention.
- The scorer's own input type is a keyword-only frozen dataclass whose fields are the entire allowlist — a column added to a candidate table next month cannot silently become a scoring input.
A prompt, not a verdict
The panel view checks its own answer before it sends one.
A screening score exists and is shown — hiding it would be its own kind of dishonesty — but it arrives captioned as a prompt to read the application, not an outcome, and the interview panel's roundup view goes further: it runs its own payload through a guard before responding, and returns a server error instead of a composite rather than risk one reaching a decision-maker.
- Every screening response carries decision: null and decided_by: "human_required" — there is no branch that sets either to anything else.
- The roundup view returns every submitted scorecard side by side, with no average, ever — a visible '8.2 overall' next to a name is exactly the moment NYC Local Law 144 and the EU AI Act's recruitment classification exist to stop.
- assert_no_composite() runs against the route's own outgoing payload and raises before a composite could be returned, guarding against a future edit as much as a current one.
- Candidate search follows the identical rule: it returns which fields matched, never an ordering by score.
What it does
Thirteen things Bharti does today.
Each card carries its own limit, and the label is derived from the backend's capability module rather than written here.
Stages a machine cannot end alone
Configurable stages, append-only transitions recording who moved a candidate and whether they were human, and a screening signal stored as contributing factors with no score column.
Works todayMatched fields, never a ranking
Skill, location and experience search returning which fields matched, never a ranking, and refusing any query that selects on a protected characteristic. Saved searches are refused on the same protected-characteristic terms, so a standing filter can't smuggle one through, and a real reindex worker keeps the index current on every candidate create or correction.
Works todayBlind until everyone has submitted
Blind-until-submitted is enforced in the backend, keyed on the kit's own expected interviewers so it cannot be dodged by simply not starting a scorecard.
Works todayRaw evidence, no composite
Raw per-interviewer evidence with no average, composite or recommendation — the route checks that against its own payload before returning it. A decision requires a named decider and a written rationale.
Works todayDrafted after a human has decided
Drafting is gated on an existing human roundup rejection, uses de-identified scorecard themes, and is approved by a named person before a send route — reachable only from an approved message, only once — can fire. Email sends for real today, since ZeptoMail is already configured on this deployment; WhatsApp needs META_ACCESS_TOKEN and META_PHONE_NUMBER_ID.
Needs a credentialThe same stage staff see
An expiring, token-authenticated portal showing candidates the same stage staff see. Withdrawal propagates across every application and revokes every live link.
Works todaySelf-booking, real calendars pending
Holds, candidate self-booking and a visible accommodation request at the booking step all work locally. Real availability needs a connected Google or Microsoft calendar.
Needs a credentialAnchored to the pay band, not prior salary
Offer drafting anchored to the role's own pay band — never prior salary, for which there is no column — with an in-order approval chain. Dispatch for signature needs an e-signature provider.
Needs a credentialLive counts, not projections
Live stage counts, days-in-stage and conversion, plus immutable daily snapshots and real per-board source performance — both computed against this workspace's own data with no external dependency. A snapshot taken twice in one day hands back the same row rather than overwriting it, so a later dispute has one permanent answer.
Works todayNothing auto-declines an adjustment
A policy record and accommodation tracking, structurally unreachable from screening. An adjustment cannot be marked unfulfillable without a written reason, and nothing declines it automatically.
Works todayTheir consent, not an inference
Flagging runs automatically when a requisition closes, on documented job-relevant signals only — never a private note — and every rediscovery match is kept for audit. Re-engaging always asks for fresh, per-role consent rather than assuming a standing one. Email sends today through this deployment's already-configured ZeptoMail; WhatsApp needs META_ACCESS_TOKEN and META_PHONE_NUMBER_ID.
Needs a credentialNo column for what is withheld
Parses contact details, skills, employment history and education, and defines no protected characteristic at all. Bharti receives only its own candidate columns, whatever the resume states.
Built, with limitsOne real channel today, three gated on a partnership
A self-hosted careers page is real: publish, and a candidate can apply, creating a genuine application attributed to the system rather than a fabricated person. Naukri, LinkedIn and Indeed have no client here — each needs a partner business relationship this deployment hasn't set up, so a failed attempt against one is recorded honestly rather than faked.
Built, with limitsReal delivery on two channels, not three
Templates, a manual send and message history run against real data, and a stage move triggers a message automatically — notifying of a decision a human already made, never making one. Email sends for real today through this deployment's already-configured ZeptoMail; WhatsApp needs META_ACCESS_TOKEN and META_PHONE_NUMBER_ID. There is no SMS gateway anywhere in this codebase — that gap is a missing integration, not a missing key.
Built, with limitsA working conversation engine, not yet reachable
A fixed four-question flow in four hand-checked languages, gated on explicit consent before any question is asked, converts to a real candidate and application on completion — and it's testable locally today. Two real gaps: sending anything over WhatsApp needs META_ACCESS_TOKEN and META_PHONE_NUMBER_ID, and no route here is wired to Meta's actual inbound webhook yet.
Built, with limitsConsent and refusal are real; no provider is connected
A result cannot be recorded before consent is on file, checked both in the route and by a database constraint underneath it, and nothing in this codebase lets a background-check result move a candidate's stage. No India BGV provider — EPFO employment history, PAN/Aadhaar-linked identity, DigiLocker education — has a client here; each needs a licensed-intermediary relationship no operator has set up yet, so nothing is faked against a guessed contract.
Built, with limitsDrafts a note from a transcript, not from audio yet
Both-party consent is enforced at the database level, not only checked in the route. Paste a transcript — a provider's own captions — and it drafts a per-category note today with no extra credential, using the LLM pool already configured, and accepting a draft writes only into the scorecard's comment, never a score. The real gap: turning a recording into text needs a speech-to-text provider, and none is connected.
Built, with limitsThis page still needs an employment-law reviewer's eyes on it.
Every claim above traces to a route, a constraint or a status entry in the code, and a test fails the build the moment the two disagree. That proves the page matches the schema — it does not prove the schema itself satisfies every jurisdiction's hiring-compliance rules, which vary by state and change over time. Before this page goes live, a qualified employment-law or HR-compliance reviewer should read the boundary claims specifically and confirm they hold up as a compliance statement, not only as an accurate description of the code. Saying that here is a trust signal, not an admission.
Before you switch
Screen fairly. Decide with a name attached.
Tell us how your hiring pipeline is structured today, and we will tell you exactly what Bharti can run now — and where it insists a human stays the one deciding.
Questions
Straight answers.
Can Bharti reject a candidate automatically?
No, and not because of a setting — because the database refuses the row. bharti_stage_transitions carries a CHECK constraint that refuses the row combination actor_type='system' with to_stage_is_adverse=true. A rule can propose moving a candidate to an adverse stage all day; it cannot execute that move — the database refuses the row, not just the request, and an adverse move that does go through must name a human actor and carry a written reason. A rule may flag or suggest all it wants; only a named human, at the moment of the decision, can actually move someone to an adverse stage.
Does Bharti ever see a candidate's caste, religion, gender, age or marital status?
There is no date_of_birth, gender, marital_status, caste, religion or photo_ref column anywhere in this module. Indian resumes routinely carry all of them, so a value that was never stored cannot become a scoring input, leak into an export, or be reverse-engineered out of an analytics breakdown. Resume parsing withholds them even when a resume states them outright, and the screening function's own input type is a fixed allowlist that has no field for any of them to arrive in.
What is a screening score, exactly?
A number recomputed from named factor rows, each naming the exact field it read, with no stored score column behind it. Every response that carries it also carries decision: null and decided_by: "human_required" — there is no code path in this product where that score becomes a verdict by itself.
Can an interview panel see an average score before deciding?
No. The roundup view returns every submitted scorecard side by side and nothing else — no average, composite or recommendation — and the route checks its own response against that rule before sending it, raising a server error rather than letting a composite reach a decision-maker even by accident.
Can Bharti send a rejection message to a candidate?
It can draft one, but only after a human has already recorded a rejection in the roundup, using de-identified scorecard themes rather than a person's raw notes, and a named person still has to approve it before a send route can be called — approval is reachable only once, and there is still no code path from a score, a stale-application rule or an automated stage move straight to a send. Once approved, email delivers for real today; WhatsApp needs a Meta credential this deployment hasn't configured.
Do I need to connect anything before I can start?
No. Building requisitions, running the pipeline, structured interview kits, the hiring-team roundup, the candidate portal and equal-opportunity tracking all work today with nothing configured. Real calendar availability needs a connected Google or Microsoft account, and sending an offer for signature needs an e-signature provider — both say so on their own card below.