Save the assessment the reviewer saw, and the correction they made

“Owned” and “supported” are different claims

An assessment says a candidate owned a migration. The resume says they supported the migration team. A reviewer catches the difference and plans an interview question about responsibility.

If the team only saves the final summary, the next interviewer may never see the correction. If it only saves the original model output, the inflated claim survives. This invented example shows why the record needs both, with a clear connection between them.

NIST describes documentation as supporting accountability and human review, including oversight and system limits. The record design here applies that idea to application assessment. It does not prescribe a retention period or certify compliance.[nist]

Connect the records instead of copying everything

Scroll sideways to read the full table.

The diagram makes these relationships explicit. Link to a controlled source where access permits it; avoid multiplying whole candidate documents across logs. If the original is no longer available, record that limitation. A source reference that cannot be opened does not make the assessment verifiable.

A later job-description edit should not make an old assessment look as if it used the new requirement. Save an identifier and version, or a dated snapshot that lets the team distinguish them.

A rerun does not recover the earlier answer

Save the assessment that was shown to the reviewer. A regenerated response may differ. It cannot stand in for the result that informed the decision.

Record the provider and model identifier the service exposes, prompt or configuration version and available processing settings. Do not invent reproducibility metadata. If the provider does not expose a fixed model version, say so in the record.

OpenAI recommends evaluating agent traces to inspect mistakes in decisions and tool calls. Keep observable inputs, outputs and operations; do not treat hidden model reasoning as a necessary or reliable explanation of the hiring decision.[openai]

Write the correction in plain language

“Ownership claim unsupported. Application says “supported the migration team”. Replace with “contributed to migration; responsibility unclear”. Ask which decisions the candidate made.”

Include who checked the passage and when. Keep the question separate from the correction. The record should not turn unclear responsibility into a statement that the candidate cannot do the work.

When the assessment is accepted unchanged, record the decision it informed and any uncertainty that still matters. When reviewers disagree, keep their reasons and the resolution. “Human reviewed” alone does not explain either result.

Keep permission and execution separate

If a separate system sends a message or changes a stage, connect the action to the authorised decision. Approval means the operation was permitted. It does not mean the operation completed. A timeout may leave the outcome unknown.

OWASP recommends least privilege and human approval for privileged operations. Someone who can inspect a review record need not have permission to send candidate messages or access unrelated applications.[owasp]

Set access, correction, deletion, exports and backup arrangements with the appropriate owners. Saving more copies can make those obligations harder to manage without making the decision easier to explain.

Use corrections to choose the next test

Look for repeated failures in reviewed assessments: “supported” becoming “owned”, missing passages or extraction errors hidden by a confident summary. Turn a specific failure into a controlled test, record the changed configuration and check it before resuming the affected task.

The record should let a person reconstruct what changed and why. It should also help the team notice that the same correction keeps being made. Otherwise the audit trail becomes storage for a problem that nobody fixes.