How to Add New Employee Compliance Training to an AI Onboarding Company Brain

Keep three things apart in an onboarding assistant: answering a policy question, showing a course, and recording that the course was completed. Only the training system and a named person can do the last one. We recommend a requirement register that decides who needs which course, a deterministic service that applies it, and an assistant that explains and links but never marks anything complete or tells an employee they are fully compliant. Plan the evidence path first: California's free state course ends with a certificate the employee keeps, and the state stores no completion record.

Three jobs, three owners

A company brain finds answers in scattered internal knowledge. Compliance training does three other jobs: it decides which requirement applies, delivers approved material, and keeps an acceptable record. Each has its own owner and source of truth, and the assistant owns none of them. GitLab's onboarding handbook shows the same separation in a public process: the People Operations team owns the onboarding issue template and the IT team owns access requests. It may explain why a task appears, link to the approved course, answer questions from approved sources and route an exception. It must not create requirements, forge completion, rewrite approved course content or override an accountable owner.

The assistant cannot infer requirements from a job title, because they depend on facts the title does not carry. OSHA's education and training guidance tells employers to explain the hazards of the workplace and the controls for them, and to give training in a language and at a literacy level that all workers can understand, so what a person needs depends on exposure. The California Civil Rights Department offers free harassment prevention courses for supervisory and nonsupervisory employees, and its employer FAQ sets the rules: employers with five or more employees train supervisors for two hours and other employees for one hour every two years, and train new hires within six months.

"Operations lead" might supervise people in one business and nobody in another. A remote employee's residence may not match the legal entity or work location used for the assignment, and a warehouse visitor does not have the same exposure as a warehouse operator. If the assistant guesses, it can omit required work or assign irrelevant courses that waste the first week.

A requirement register decides, and the assistant explains

Start with a controlled register of training requirements, before any prompts. For any assignment, a compliance owner should be able to say which rule or internal control requires the training, which employee facts make it apply, which approved course version satisfies it, what evidence proves completion, and who resolves an exception. A useful requirement record holds these fields:

• A stable requirement identifier and plain-language name.
• The governing source, owner and review date.
• Applicability rules for legal entity, location, role, supervisory status, work exposure and contract type.
• The clock: what starts it (hire, promotion, transfer or first exposure), how long it runs, and whether the requirement is a gate or a deadline.
• The approved course identifier and version.
• Required delivery mode, language, duration, assessment and passing rule.
• The evidence fields to retain and their retention policy.
• An exception owner and escalation deadline.
• The actions allowed when status is assigned, started, completed, expired, waived or disputed.

A checklist has a single line: complete safety training. The register says which safety training applies to this employee, why, which version is valid, what completion means and who can approve a documented exception. Keep the governing source beside the rule. When a compliance owner changes the rule, create a new version and leave existing completion records pointing to the requirement and course versions the employee actually received.

We recommend marking every requirement as a gate or a deadline and treating the two differently. A deadline, such as California's six months from hire, gets a schedule and reminders that escalate as the window closes. A gate, such as hazard training for a specific task, is not a reminder problem: the work assignment, access grant or shift should depend on the readiness status, so nobody starts the task untrained because a reminder went unread. A single list with one due date per course hides that difference.

The clock can also restart on a role change. In California a new supervisor must be trained within six months of taking the role, so a promotion creates a new requirement with its own clock. Feed promotions and transfers into the same evaluation as hires.

Separate employee facts from training decisions

The assignment engine needs verified attributes from the HR system, identity directory, safety system or another named authority: start date, employing entity, work location, manager, supervisory status, department, job family, facility access, equipment exposure and employment type.

Do not let the language model turn free text into a binding decision. It may notice that a job description mentions forklift work, but an accountable safety owner should confirm the exposure before the system assigns or removes required training. For ambiguous inputs, produce an exception task instead of a confident result. Give every input one of three states:

• Verified: the authoritative system provides a current value.
• Missing: no approved value is available.
• Conflicting: two approved systems disagree.

Only verified facts satisfy an applicability rule automatically. Missing and conflicting facts block the affected decisions and go to the field owner, while unrelated assignments continue, so one bad attribute does not freeze the whole onboarding plan. Save the fact snapshot, requirement version, rule result, course version, due date and evaluation time, so that a reviewer can rerun the same inputs and reach the same assignment.

The assignment and evidence workflow

1. Employee event intake

Receive hires, promotions, transfers, manager changes, location changes and exposure changes from the authoritative source, each with a stable event identifier so that retries do not create duplicate assignments. Validate required fields before evaluating rules. If supervisory status is missing, create an owner task for the requirements that depend on it and record the reason, instead of silently treating missing as false.

2. Deterministic applicability service

Evaluate versioned rules outside the language model, on structured facts. The output names the matched requirement, rule version, supporting facts and decision, and the same versioned inputs always give the same result. The company brain can explain the result in natural language, but its answer should cite the requirement record. If an employee asks why a course was assigned, it can name the verified attributes that triggered it and give the escalation route, without exposing private facts that the current viewer may not see.

3. Learning system assignment

Send the approved course identifier, version, due date and employee identifier to the learning system, and treat the returned assignment identifier as the authoritative link. A successful API response means the assignment was created, not that the employee completed it. The company brain can show the assignment and due date and deep link to the course. It should not recreate controlled training in chat, which keeps approved delivery behavior and assessments in the system built to record them.

4. Completion event intake

Accept completion only from an approved learning system or a documented manual process, and capture the assignment identifier, learner, course version, completion time, assessment result when required, delivery mode and issuer. The ADL xAPI specification provides one established model for exchanging learning activity statements, and its actor, verb, object, result, context and timestamp concepts can help normalize events across learning tools. Using xAPI does not decide whether a statement satisfies a legal obligation. Your requirement register still defines which event and evidence fields count.

Some courses have no completion feed at all. California's free state course ends with a certificate that the learner generates and keeps, and the Civil Rights Department does not store or track certificates or completion. The course page also says the training may not be duplicated or ingested into a third-party system such as an employer's e-learning platform. For a course like that, the evidence intake is a certificate the employee uploads and a named person checks. The company brain links to the course and does not copy its content into its index, and the assistant's job is to ask for the certificate and say what is still missing.

5. Evidence ledger

Store an immutable completion reference linked to the employee, assignment, requirement version and course version, and protect the underlying record with role-based access and a retention rule. California, for example, requires employers to keep training documentation for at least two years: who was trained, when, the type of training, the provider and any certificates. The company brain normally needs only a narrow status view, such as assigned, due, completed, expired or under review, and no access to individual assessment responses.

6. Readiness projection

Calculate onboarding readiness from authoritative states. A person is compliant for a requirement only when the expected assignment exists, valid completion evidence is present, the accepted version matches, and no blocking dispute or expiry remains. Expose the projection to the company brain as read-only data. The assistant may say, "Your required workplace safety course is complete and was accepted on August 21." It should not say, "You are fully compliant," unless the readiness service confirms every applicable blocking requirement.

The California warehouse supervisor

Take a California warehouse supervisor, an invented example, who starts in two weeks. The HR system confirms the employing entity, California work location, supervisor status and start date, and the safety system confirms warehouse access and equipment exposure. The assignment service evaluates those facts against the current register. It creates a deadline requirement for the supervisor harassment prevention course, with its due date set by the state's rules, and gate requirements for the safety courses tied to the confirmed equipment exposure, so the forklift stays off the shift schedule until the readiness status clears. Each assignment carries its own rule version, course version, owner and due date.

The safety courses live in the learning system, which reports completion. The intake service checks the assignment identifier, learner, accepted course version and required result, and the evidence ledger records the event. A course that reports completion without a required assessment result goes to under review. The harassment prevention course is the state's, so the assistant asks the supervisor for the certificate, and a named person checks it before the ledger records anything.

During preboarding, the company brain shows only tasks allowed before employment begins and answers logistical questions from approved material. If the supervisor asks whether training from a previous employer counts, the assistant opens an exception request and does not mark the course complete, because the employer FAQ makes the current employer responsible for checking that the earlier training was compliant. On the first workday the readiness projection shows which requirements passed and which stay blocked. The manager sees operational readiness, the supervisor sees their own tasks and escalation routes, and neither view exposes assessment details.

Failures that must not erase the record

• An employee fact is missing: block only the rules that need the missing field, assign the data owner, show the employee that the task is being reviewed, and rerun evaluation when the value arrives.
• A rule changes after assignment: create a new requirement version. Decide whether existing hires are grandfathered, need supplemental material or need reassignment, and never rewrite the historical rule behind an accepted record.
• The learning system rejects an assignment: keep the requirement in an assignment-failed state, retry with the same event identifier, alert the integration owner, and do not let the readiness projection treat an API attempt as an assignment.
• Completion arrives twice, or without required evidence: deduplicate on the source event or statement identifier, keep the original accepted record and link harmless duplicates to it. Quarantine an event with missing evidence for review, and do not ask the language model to read an incomplete payload as success.
• The assistant gives a wrong explanation: correct the source or retrieval path, identify the affected answers and issue a correction that links the source. Do not alter the authoritative assignment or evidence record to match the chat transcript.
• An employee disputes applicability: freeze enforcement actions that depend on the disputed item when policy allows, route the case to the named owner, preserve both the original decision and the final resolution, and communicate the outcome without exposing private notes.

Test with synthetic employees

Build a matrix of synthetic employees covering different locations, legal entities, supervisory states, work exposures, start dates, transfers and missing attributes, and have the compliance owners approve the expected assignments and exclusions for each case. Then check that:

• replaying the same employee event creates no duplicate assignment;
• changing one relevant fact changes only the expected requirements;
• removing a required fact creates an exception and not a guess;
• completion for an obsolete course version leaves readiness blocked;
• the same valid completion submitted twice leaves one accepted record;
• asking the assistant to waive or complete a course gets a refusal and the approved route;
• an integration outage produces an unknown state and not a stale success;
• a reviewer packet traces each readiness decision to employee facts, rule version, assignment, course version and completion evidence.

Kipwise's employee onboarding workflow shows how assigned reading, searchable company knowledge, and progress tracking can sit in one employee experience. Use that experience layer to make work clear, but keep mandatory status tied to the training and evidence systems.

Pick one requirement and write ten test cases

Do not automate every jurisdiction and course at once. Choose one requirement family with a clear owner, structured applicability rules, an approved course and stable completion data. Build the register, assignment path, evidence intake, exception route and readiness projection for that family, and test it against synthetic hires and one controlled pilot cohort.

Your next action is to select that requirement and produce ten approved test cases before configuring the assistant. If the team cannot agree on the expected assignment and acceptable evidence for those cases, the rule is not ready for AI-guided onboarding.