Assemble an audit-ready decision file

Step 1: Capture the assessment structure before the first candidate

An audit-ready file starts before anyone is assessed. The first thing a challenger asks is not "why did this candidate score a 3?" but "what standard were they measured against, and was it set in advance?" So the file opens with the assessment's structure: the role blueprint with its competency weights, the rubric version used for scoring, and the mapping from each task to the skills it was designed to measure.

For a customer-support requisition, that means the file shows that empathy-and-tone was weighted at, say, a quarter of the role-fit score before candidates arrived, that the ticket-reply task maps to tone and judgment-within-policy, and that rubric version 2.1 — with its concrete descriptors for strong, acceptable, and weak replies — was frozen for the whole cycle.

Version pinning is the load-bearing detail. If the rubric was revised mid-cycle, the file must show which candidates were scored under which version and why the change was made. A rubric that quietly drifted between candidate five and candidate six is the first thread a scrutinizing reviewer will pull, and it unravels confidence in every score that follows.

• Role blueprint with competency weights, dated before the first invitation went out.
• Rubric text and version identifier, pinned for the cycle.
• Task-to-skill mapping: which task produced evidence for which competency.
• Any mid-cycle changes, with the date, the reason, and which candidates were affected.

Step 2: Attribute every score to a named evaluator and a timestamp

A score without an author is an assertion; a score with an author is testimony. Every rubric score in the file carries the evaluator's name, the timestamp of the review, and the note they recorded — so "objection handling: 2 of 4" reads as "scored by the sales team lead on the Tuesday review pass, because the candidate conceded on price at the first pushback instead of exploring the objection."

Attribution matters most where evaluators disagreed. If two reviewers scored an inside-sales role-play differently and a calibration discussion settled it, the file keeps both original scores, the discussion note, and the resolved score. Do not overwrite the disagreement — a record that shows honest divergence and a documented resolution is more credible under scrutiny than one that is suspiciously unanimous.

Timestamps also establish sequence, which auditors care about: they show scores were recorded before the advance-or-reject decision, not backfilled after it to justify a choice already made. SkillCort captures this ordering automatically as evaluators work, but it only protects you if reviews actually happen in the platform — a side spreadsheet transcribed into the system at the end of the cycle leaves no sequence worth trusting.

Step 3: Write the methodology in plain language

Assume the person reading the file is not an assessment specialist — an employment lawyer, a client's HR director, a works council member. The file needs a one-page methodology statement in plain language: what the role requires, why work samples were used to measure it, how scoring worked, and who made the final decision.

A workable template: "Candidates for this support role completed three realistic tasks — a reply to a frustrated customer, a triage of a short ticket queue, and a troubleshooting scenario. Each response was scored by trained evaluators against a rubric written before the assessment opened. Scores were weighted by the competencies the team defined for the role. Final advance decisions were made by the hiring panel reviewing this evidence."

Avoid jargon and avoid overclaiming in equal measure. Do not promise that the assessment "guarantees" performance or cite validity figures you cannot source. The defensible statement is the modest one: candidates did realistic work, everyone was measured the same way against a pre-set standard, and humans made the decision on that evidence.

Step 4: Log how AI assistance was used

If AI touched the evaluation, the file says so — precisely. Regulators and internal reviewers increasingly ask not "did you use AI?" but "what exactly did it do, and could it have decided anything?" The decision file answers with a provenance log: which model and version generated each summary or flag, what input it saw, what it produced, and which human reviewed that output before it informed anything.

The log should make one fact impossible to miss: AI never made a selection decision. In SkillCort, AI drafts evidence summaries and surfaces patterns for evaluators; the scores are human, the flag resolutions are human, and the advance-or-reject call is human. The file demonstrates this structurally — every AI artifact in it is paired with the named evaluator who read it and the judgment they recorded afterward.

Model and version provenance is not bureaucratic decoration. If a summary is later found to have mischaracterized a response, the version log tells you exactly which other candidates' summaries came from the same model build and need a second human read. Without the log, the only honest remedy would be re-reviewing the entire cycle; with it, the correction is scoped, documented, and routine.

• Every AI-generated summary or flag, tagged with model and version identifiers.
• The human evaluator who reviewed each AI output, and what they decided.
• A plain statement that no selection, rejection, or ranking decision was automated.
• No cross-client or cross-requisition candidate scoring — each file stands alone.

Step 5: Include integrity events and how each was resolved

Leaving integrity flags out of the file is the mistake that turns a routine question into a credibility problem. If a signal was raised — pasted text in a written task, unusual timing on a troubleshooting scenario — the file includes the event, the context a human reviewed, and the explicit resolution: cleared, discounted, or discussed with the candidate.

Resolved flags strengthen the file rather than weaken it. A record showing that a support candidate's tab-switching was reviewed and found to be documentation lookup — job-realistic behavior — demonstrates that your controls are proportional and human-judged, not an automated dragnet. Equally, a record showing a flag led to a follow-up conversation and a discounted task shows the process has teeth without being punitive.

What the file must never contain is an unexplained flag next to a rejection. That juxtaposition invites the inference that a machine signal decided the outcome — the one thing a proportional, human-reviewed process is designed to prevent, and the one inference an auditor will test first. Resolve every event on the record, every time, however minor it looked in the moment.

Step 6: Export one self-contained file per requisition

The final step is packaging. Export a single decision file per requisition that contains everything above — structure, scores with attribution, methodology, AI log, integrity resolutions, and the recorded rationale for each advance and rejection from the Decision Board. Self-contained is the operative word: the file must be readable in three years by someone with no access to the live platform, no logins, and no institutional memory.

Test it with a simple drill. Hand the exported file for a closed inside-sales requisition to a colleague who was not involved and ask them to answer: what was measured, how, by whom, and why did each finalist advance? If they can answer from the file alone, it is audit-ready. Wherever they had to ask you something, that answer belongs in the file.

Run the export at requisition close, not when a challenge arrives. Assembling the record while the evidence is complete takes minutes; reconstructing it under a deadline, after evaluators have changed teams, is when defensibility quietly evaporates. The close-out export doubles as a quality checkpoint: a missing rubric version or an unresolved flag surfaces now, while it can still be fixed.

• Assessment structure: blueprint, weights, rubric versions, task-to-skill mapping.
• All scores with evaluator names, timestamps, and notes — including resolved disagreements.
• Plain-language methodology statement a non-specialist can follow.
• AI usage log with model and version provenance and human review attribution.
• Integrity events with explicit human resolutions.
• Decision rationale for every advance and every rejection.