“Human reviewed” should mean somebody checked the application

An approval can hide an unchecked claim

An AI assessment recommends interviewing a project coordinator. The explanation mentions delivery risks, supplier dependencies and planning. The manager recognises the requirements and clicks approve.

But the application said something narrower: “Maintained the project tracker and escalated delayed supplier inputs to the project lead.” Nobody checked that sentence. The manager has approved an interpretation that may be too generous.

This is an invented example, but it gives “human review” a concrete job. Somebody has to read the source, decide what it supports and correct the next step when the interpretation is wrong.

NIST calls for documented human oversight and warns that representations of a task can lose context. Those principles help explain why adding a person to the process is not enough on its own.[nist-core][nist-human]

Put the source and the assessment beside each other

Scroll sideways to read the full table.

The candidate may still be worth interviewing. The correction changes the reason and the question. An interviewer who sees “manages delivery risks” might skip the exact area that needs examination.

Read the surrounding paragraph too. A date, heading or adjacent role can change the meaning. If extraction has joined two jobs together, fix that reading before debating the recommendation. A source link helps you find the passage; it does not guarantee the model interpreted it correctly.

Then check the requirement. Was independent replanning actually part of this opening? If the role mostly needs tracking and escalation, the original sentence may already supply useful early evidence. The review should use the agreed criteria, not a higher bar introduced halfway through screening.

Not every blank means the same thing

A short application may leave out an example. A scan may lose a page. Two passages may describe different responsibilities. An interviewer may ask a question and receive no relevant answer. These require different responses.

• Missing detail: ask a focused question if the answer could change the next step.
• Reading failure: return to the original file and check what was lost.
• Contradiction: record both statements and ask for clarification.

In the coordinator example, ask what changed after the supplier delay and what the applicant personally decided. For a later structured interview, use common core questions and rating standards. OPM describes that approach; it does not validate this particular screening routine.[opm-interviews]

Before adding another round, ask whether a credible answer would change the decision. Candidates should not spend another hour answering a question the team no longer needs.

Leave a note the next reviewer can use

“Interview recommended for coordination experience. The application shows tracking and escalation. It does not yet show ownership of replanning. Ask for a decision made after a dependency changed.”

That note is more useful than “AI assessment approved”. Put it beside the assessment or in the team’s approved decision record. Include the passage and the criterion used so a later reviewer can check the connection.

When reviewers disagree, identify the question they disagree about. A source-reading error belongs with the original document. A disagreement about the role belongs with the hiring manager. Unresolved evidence should stay unresolved in the record.

Repeated overstatements need a process fix. If several assessments turn “supported” into “owned”, inspect the configuration and test that failure before the next live review. A second approval checkbox will not repair the interpretation.

The person reviewing needs the time, access and authority to change the recommendation. Without those, “human reviewed” describes a step in the workflow, not the work that happened.