How to Run a New-Hire Probation Review with an AI Company Brain

Use the company brain to assemble the evidence for a probation review and never to judge the employee, because a fluent summary built from evidence the employee has never seen is how a review becomes a verdict nobody can defend. We recommend three rules. The employee sees the packet before the meeting. The decision screen refuses "not met" on any expectation that was never flagged as at risk at an earlier checkpoint. And a late account, a canceled shadow session or an absence shows up as a process blocker, never as the employee's performance. The manager fills in the outcome by hand.

What Acas expects from a review

Acas describes probation reviews as formal checkpoints held one-to-one. It says managers should share what they have gathered with the employee before the meeting, keep records and give the employee a copy after each review, and make sure the outcome does not come as a surprise. It also says employers must keep those records in line with UK GDPR. Legal requirements vary by country, contract and worker status, so employment counsel should adapt this workflow to each place you hire. What follows controls the evidence and the system's behavior, and it is not legal advice.

Limit what the assistant may do

Write a short operating contract before the first review period begins: who decides, what evidence is allowed and excluded, how the employee can respond, and which outcomes the process supports. The company brain gets four jobs: retrieve the current role expectations with their effective dates, collect references to allowed evidence with owners and timestamps, flag records that are missing, conflicting, stale or inaccessible, and format a draft packet for both people to review. It never assigns a pass probability, infers attitude or cultural fit, ranks the employee against peers, guesses at a disability or recommends dismissal. Enforce that in application logic and access policy, not in a prompt.

The ICO's guidance on AI and data protection has chapters on accountability, transparency, accuracy, fairness and individual rights, including one on how Article 22 of the UK GDPR, which covers solely automated decisions, bears on fairness. It carries a notice that it is under review after the Data (Use and Access) Act, so check its current state. The design answer is the same under any version: the manager makes a real, informed decision, which means the manager can see the evidence, can disagree with it and enters the outcome and the reason personally. Whether a given setup counts as solely automated is a question for counsel. NIST describes its voluntary AI Risk Management Framework as a way to manage risks to individuals, organizations and society. In a probation review, the individual who carries the risk of a wrong output is the new hire.

Agree the expectations before the evidence

Start from expectations the manager and the employee already discussed, never from criteria invented after the model has seen the records. Give each one an owner, a source, a measurement method and a support dependency:

expectation_id: support-queue-01
outcome: "Resolve two supervised customer cases using the approved escalation path"
owner: "support-manager"
governing_source: "kb://support/escalation-policy"
effective_from: "2026-08-01"
evidence_allowed:
  - "case IDs selected by the manager"
  - "employee reflection shared for review"
support_dependencies:
  - "helpdesk access"
  - "assigned shadow session"
excluded_evidence:
  - "private onboarding chat"
  - "medical or accommodation records"
at_risk_flagged_on: []
decision_authority: "support-director"

The support_dependencies field prevents the most common substitution. Take a new support specialist who should resolve two supervised cases by week six, whose ticketing account arrived in week four and whose shadow session was canceled twice. The tracker shows zero completed cases, and a generic summary calls that "insufficient progress". The packet should instead show both dependencies unmet, with the access log and schedule as sources, mark the outcome not_yet_observable, assign owners to restore the missing support and leave the decision blank. CIPD's induction factsheet includes an induction checklist for planning or refining the process. Use it to confirm that the support the expectations depend on exists before the period starts, and record any gap under support_dependencies so that fixing it is the employer's job.

Treat "closed" and "complete" as different facts as well. GitLab's onboarding handbook says its employment bot automatically closes any onboarding issue still open after 60 days. A closed issue can therefore hold unfinished tasks, and a packet that reads closure as completion reports work nobody did. Check what your own onboarding system does when a task ages out.

Keep retrieval narrower than the manager's access

A manager can open many documents that do not belong in a probation packet, so the retrieval identity has to carry the review purpose as well as the person. Azure AI Search trims results by comparing the caller's user or group identity with permission metadata stored on each document. That answers who is asking and says nothing about why, so model the purpose yourself: index each reviewable item with the employee, purpose, audience, owner, retention class and effective date, build an allowlist of evidence types, intersect it with current permissions, and reject a result when any scope fails.

Keep raw accommodation records, health details, background reports, protected leave reasons, private buddy conversations and unrelated chat out of the review collection. When one of those processes affects the employee's ability to do a task, the packet shows only a safe operational state such as support_dependency_pending, and the HR owner handles the underlying record in the authorized system. Test it with three requests that must return nothing and leave an audit event: private onboarding questions, another employee's review, and an expired manager note. A positive test shows only that search works.

The packet separates facts from interpretation

The output is an evidence packet in five sections: the agreed expectations and the versions in force during the period, employee-selected evidence and reflections, manager-selected observations with dates and sources, missing support and unresolved conflicts with any correction requests, and blank decision fields for pass, extension or formal escalation under company policy. The generator refuses to finish when a source lacks an owner, two records conflict, or the employee cannot inspect evidence marked for discussion:

for expectation in approved_expectations:
    records = retrieve(allowlist, expectation.id, review_purpose)
    visible = intersect(records, employee_view, manager_view)

    if support_dependency_is_open(expectation) or window_shortened(expectation):
        packet.add_process_blocker(expectation)
    elif visible.has_conflict_or_stale_source():
        packet.add_requires_resolution(expectation)
    else:
        packet.add_evidence(expectation, visible.with_citations())

packet.leave_decision_blank()

Label generated text as a draft and show source dates and owners. "The employee missed the target" should be impossible unless the target, the period, the evidence, the dependency state and the reviewer are all present, and even then the sentence belongs to the manager and not to the model.

Make the earlier checkpoints binding

Acas says the outcome should not come as a surprise, and that regular reviews help identify extra support such as more training. A system can enforce what guidance only asks for. We recommend that the decision screen offers "not met" for an expectation only when the packet history shows the employee was told, at an earlier checkpoint and on a recorded date, that the expectation was at risk. Without that record the manager can still extend probation and hold the missing checkpoint first. This covers performance against agreed expectations. Conduct concerns follow the formal HR process and do not belong in this packet. The rule also leaves the manager a dated record that the employee was told, which is the kind of evidence Acas says review records exist to provide if a probation ends in dismissal.

Absence needs the same care. Acas says an employer should rearrange a review when the employee is off sick, and should consider a probation extension after long-term absence, including whether the absence is disability-related and reasonable adjustments might help. It also notes that an employee does not have to tell their employer about a disability. So the company brain must never infer a reason from a quiet stretch in the data. We recommend that HR sends it a single signal, review window shortened by a number of days, with no reason attached. Expectations that depended on those days become not_yet_observable, the meeting date moves, and the packet shows the shorter window rather than a count of tasks that looks like a shortfall.

A correction window that works

Send the packet early enough to read and answer, with explicit states: received, disputed, corrected, manager response pending and resolved. The employee can mark a source wrong or stale, add evidence the contract allows, explain a blocked dependency, request a correction of factual data, or ask for a private HR route without putting sensitive details in the packet. Keep the original and the corrected record linked, never overwrite the trail, and show unresolved disputes in the meeting instead of choosing the version that makes a clean summary.

Kipwise's employee onboarding page describes assigned reading, searchable policies and procedures, progress tracking, and workflows for keeping content current. Those features can supply source-linked onboarding context, and they should not become a performance scoring system.

The meeting and the record

The manager owns the meeting. Start with the unresolved evidence and the support dependencies, ask whether the packet reflects the period accurately, and give every open item an owner and a due date. The decision screen asks the manager to type the outcome and the reason, offers only the choices company policy allows, such as pass, extension or escalation, and preselects nothing and shows no model confidence score. If the outcome may end in dismissal, the case goes through the required HR and legal procedure, and Acas notes extra steps for a fair process in that case. Afterwards, share the approved record with the employee and store who decided, when it took effect, which policy version applied and what follow-up remains, under your employment-record retention policy.

Test the whole path with synthetic employees before the first live review, with cases built to fail: criteria added after the evidence period without a visible version change, another employee's records, private chat and accommodation details, a stale or conflicting source, an unmet dependency or a shortened window turning into a negative mark, a prompt or tool call that tries to fill the decision field, and "not met" without an earlier flag. None may get through. Run the set again whenever the schema, model, permissions, expectations or policy change, and have People Operations, privacy and employment counsel review the failed tests and not only the clean packet.

Pilot it on one role that has written expectations and a review in the next month. Map each expectation to an allowed source, an owner, a dependency and a correction path, run the negative tests, and generate the first packet only after they pass. The first milestone is one cited packet that both people can inspect, with every decision field still blank.