ATS Screening — Shared Engine or Two

ATS Screening — Shared Engine or Two

Decision diagram for where Toptal's ATS screening engine is built. Contrasts three shapes: a shared path+review engine hosted in TopAssessment with ATS owning every surface (Option A); the screening engine in ATS with TopAssessment demoted to a headless artifact service (Option B); and two independent engines (Option C, dominated). Traces the real seam between screening orchestration (paths, journeys, reviews, verdicts, assignment) and artifact capture (forms, versions, submissions, video, file upload, applicant runner), plus the reviewer-identity choice between mirroring ATS users into ta_users and passing identity in the token.

ПМПолный Миша · @mixan946_46509ca0

0 звёзд

2 просмотра

только что · последнее обновление

ats-screening-engine-decision.js·5 сценариев

Loading canvas…

Overview

Where should Toptal's ATS screening engine be built? The diagram separates the two layers the debate keeps conflating: screening orchestration (paths, journeys, review requests, verdicts, assignment) and artifact capture (forms, versions, submissions, video, file upload, applicant runner). Artifact capture is live, large, and exists only in TopAssessment — so ATS calls TopAssessment under every option. The only real question is where the seam sits.

What is already settled

Three orchestration workstreams are aligned and in progress on TopAssessment, and the diagram marks them:

Path authoring — BAs on TopAssessment, authoring UI on ATS. This is the recommended seam already working in practice, without the engine moving.

Scorecards / rubrics — in progress on TopAssessment (ta_verdicts).

Assignment / queue / SLA — in progress on TopAssessment (ta_review_requests).

What is genuinely undecided is the journey runtime — ActivateStep, advance/retry, grant, withdraw, skip — which exists on neither side, plus multi-org tenancy, outreach, scheduling and provider ownership.

How to read it — use the layer switch

The three layers are cumulative, and that is the argument:

v1 — Today. ATS with three domain tables; TopAssessment's artifact layer live in production; TopAssessment orchestration with three workstreams in flight and the journey runtime absent; engines/screening carrying all real screening traffic.

v2 — Option A. Adds the ATS screening UI wired to TopAssessment: authoring, verdicts, startScreening, lifecycle events back to assessment_requests, and the ATS-reviewer identity problem.

v3 — Option B. Adds the ATS-side engine and rewires the same UI to it. Its nodes carry the cost the other option does not: each one restarts a workstream already in flight on TopAssessment.

Switch v2 and v3 on together and you are looking at Option C — two path engines, two verdict stores, two template libraries. That is why Option C needs no separate diagram: it is what duplication looks like.

Scenarios

[today] What is on master: the artifact layer built, scorecards and assignment in progress, and the journey runtime as the one genuinely open piece.

[option-a] Shared engine in TopAssessment. "Send and advance" spans two services, and reviewers must be mirrored into ta_users.

[option-b] Engine in ATS. The recruiter click goes local and internal Developer Screening migrates too — at the price of restarting three in-flight workstreams.

[option-c] Both layers on: the same model built twice.

[identity] Sync-versus-token, and why retiring the TopAssessment CMS removes the drawback entirely.

Tradeoffs

Relocation cost is asymmetric and time-sensitive. The journey runtime is 8 tables and two unmerged branches today; in six months it is a migration of live journeys. Artifact capture is never cheap to move. Multi-tenancy is day-one under every option — the first customers are Toptal recruiters and Arc.