Requirement changes versioned and sent to candidates in flight

The requisition carries a dated version of its requirements; when the team changes the stack, the level or the scope mid-search, everyone in flight is told what changed and which of their completed assessments still counts.

Intervention int.requirement_changes_versioned_and_sent_to_candidates_in_flight Actor: employer policy Scope: organizational Cost: medium Evidence: supported

What it looks like when this intervention is in place

Composite excerpts, written to be typical rather than copied. No particular message, company or person is quoted here.

What goes out on the day the requirement moves reconstruction

req #5120 — requirements changed today, and what it means for your assessments

v3, 14 March: level moved from senior to staff; the service in scope changed from ingest to billing. v2 is archived and linked.

Your system design round was taken against v2 and still counts. The take-home was scoped to ingest and does not; we are not asking you to redo it, and it is not held against you.

If the new version is not the role you applied for, say so and we close the file with the reason recorded as ours.

What to notice: Teams' needs change mid-search and no policy stops that. What a version stops is the change being absorbed silently, so that work already done is quietly revalued against a specification the candidate never saw and a rejection is issued as though they had failed the new one. The cost is that the requisition has to admit which version each assessment was taken against.

What this targets

Expected effects

mech.mid_process_role_requirement_redefinition keeps operating — needs change — but stops being absorbed silently by the candidate
Which specification an assessment was taken against becomes a recorded fact rather than a later reinterpretation

What to measure

requisition_version_disclosure_rate
assessments_revalued_without_notice

Reached without being linked

The relations above are one step. This is what the entry reaches only by walking through them — the shape of it, since the list runs long in a registry this cross-referenced.

Bears on25: Observation8Barrier12Mechanism5

Walk it in the graph →

From each side

The same entry from inside each position that meets it: what reaches them, what it means from there, and what happens next given what they control.

Hiring manager

What reaches them: A version bump on the requisition, and the list of candidates whose completed rounds it invalidates.
What it means from there: Changing the role mid-search has a cost that used to fall entirely on people outside the company; the list is that cost, itemised, at the moment the decision is made.
What happens next: Bumps the version deliberately, and decides per assessment whether it still counts rather than leaving it to the panel to reinterpret.

Recruiter

What reaches them: A generated notice listing what moved and which rounds survive, ready to send to everyone in flight.
What it means from there: The alternative was carrying the change silently and then explaining a rejection that came from it, which is the conversation this removes.
What happens next: Sends the notice the day the version moves, and closes files at the candidate's request with the reason recorded on the employer.

Candidate

What reaches them: A dated diff of the role, and a line per assessment saying whether it still counts.
What it means from there: The ground moved, and it moved for reasons in the team's own plans — the work already submitted was not found wanting, it was scoped to a version that no longer exists.
What happens next: Decides whether the new version is worth continuing for, and keeps the rounds that still stand instead of starting over.