Start

Concepts

A few ideas explain how everything else behaves: the domain model, who owns the data, how writes are graded by consequence, and the one line the system never crosses.

The domain model

Four entities carry the workflow:

  • Jobs are the roles you hire for. A job can attach a HiringTest assessment and carries its own pipeline stages.
  • Candidates are records about people. A candidate can optionally claim an account, which links the record to a real signed-in person.
  • Applications are the pivot between a job and a candidate, unique per pair, and the thing that moves through stages.
  • Stages and transitions are per-job, with every move recorded as an append-only transition that names who moved it and why.

Shared tenancy

A HiringOrchestrator workspace is the same organization as a HiringTest company. One sign-in spans both products: assessments you send from the orchestrator score in HiringTest and post back automatically, and a candidate you invite to HiringCase is the same person. You do not manage two accounts.

Graded writes

Every command is graded by how reversible it is, and the grade is visible in the tool reference:

  • Read commands return data and change nothing. Call them freely.
  • Act commands write something consequential (a note, a stage move, an assessment send) and return an undo handle the agent surfaces to you.
  • Destructive commands (reject an application, merge candidates, rescind an offer) require explicit confirmation: a destructiveHint over MCP, or confirm: true over REST. Rejections are one candidate at a time, with a reason, never a silent batch.

Never an automated hiring decision

This is the load-bearing rule. An agent can move a candidate forward when a threshold is met, but it never auto-rejects, and it never decides who to hire. The orchestrator is observability and leverage, not a verdict. Scores and signals inform a person; the person decides.

The same posture runs through the whole platform: assessments score the work, not the brand; fraud signals flag and score down but never block a real candidate; filter rules suggest, a person applies. The agent inherits all of it.

The fit view and the feedback gate

Two signals usually live apart: the AI assessment composite and the human interview feedback. The fit view (get_application_fit_view) puts them side by side in one read: the composite and domain scores next to the reviewers' recommendation tally and per-dimension means, plus whether the current stage's gate is satisfied. It is a summary to read together, never a recommendation: it carries no fused score and no suggested action. An interviewer who has not filed their own feedback still sees a blinded human side (bias control), while the AI side stays visible.

The feedback gate (set_feedback_gate, admin only) makes one ask expressible: no one moves forward out of a stage until a required screen is filed. It is off by default and configured per job and per stage. When on, it blocks a forward move while a requested screen is outstanding. It only blocks: it never declines or moves anyone, and it never fires for automated moves or rejections. Filing the feedback clears the gate. An agent can request a screen (request_feedback) but can never file one on a person's behalf.

Audit by construction

Every command an agent runs lands in the same audit log as the UI, attributed to the OAuth grant or API key that made it. There is no shadow path: the tools are the product, scoped to your workspace, logged the same way whether a human or an agent calls them. Read more in Authentication.