How to Make AI Onboarding Answers Verifiable

A citation is a clue, not verification. A company brain can link a real policy while giving an instruction the policy does not support, that applies to another country, or that became obsolete last month, and a new hire rarely knows enough to catch it. We recommend an evidence contract for every material instruction and two rules that make it hold: the system, not the model, cuts the quoted passage out of the source, and an answer is marked outdated in the employee's history the day its source changes. When a claim lacks a direct, applicable, current and accessible passage, the answer asks for context or names an owner.

Why a source link is not enough

AWS defines retrieval augmented generation as having the model reference an authoritative knowledge base outside its training data before it answers, and it lists, among known challenges, confusion when different sources use the same term differently. The evidence contract is how you make "authoritative" checkable for each claim: which owner, which version, which employee scope. A citation fails in predictable ways:

• the document is real, but the cited passage does not support the instruction;
• the passage applies to contractors and the reader is an employee, or covers one country, legal entity or business unit;
• a newer version changed the deadline or the required approval;
• the employee cannot open the source;
• the answer combines two sources without showing which claim came from which passage;
• the source has no accountable owner who can resolve a challenge.

These are evidence failures, not writing problems. Better prompting cannot repair missing scope metadata or an inaccessible source. The system needs a structured decision before generation and a visible evidence panel after it.

The evidence contract

Treat each material instruction as a claim, where material means that following it could change access, pay, benefits, compliance, safety, customer work, equipment handling or completion of a required task. For every material claim, require:

• claim_text: the exact action or rule shown to the employee;
• source_id: a stable identifier, not only a mutable URL;
• passage_text: the smallest passage that supports the claim;
• source_version: a revision, publication date or effective version;
• effective_from and effective_to: the period when the rule governs;
• applies_to: role, location, entity, employment type and onboarding stage;
• source_owner: the team accountable for the underlying rule;
• retrieval_permission: proof that the current employee may view the evidence;
• verification_state: verified, needs context, conflicting or unavailable.

The NIST AI Risk Management Framework asks (MEASURE 2.9) that AI system output is interpreted within its context. The applies_to field is that context, made explicit and testable. Never let the model invent these fields. Retrieve them from the knowledge record, the policy registry, the identity service and the source revision history.

Cut the quote, do not generate it

The evidence panel shows a quoted passage, and a model asked to quote can paraphrase, merge two sentences or invent one that sounds right. We recommend storing the passage as character offsets into a stored revision of the source, letting the system cut the text from that revision, and failing the claim if the cut text does not pass a deterministic support check against the claim. The quote then cannot be wrong about what the source says. It can only be insufficient, which is what the support check and the owner are for.

{
  "claim": "Submit the equipment request before your first day.",
  "source_id": "remote-equipment-policy",
  "source_version": "2026-07-15",
  "passage_span": [1204, 1281],
  "passage": "Remote employees must submit the equipment request before their start date.",
  "support": "direct",
  "scope": {
    "employment_type": "employee",
    "work_location": "remote"
  },
  "state": "verified"
}

The check returns direct, partial, unsupported or conflicting. Reject vague values such as likely or probably. A benefits page that says enrollment is available does not support a claim that enrollment closes after 30 days, because the deadline needs its own passage. Partial support requires another passage or a human answer.

Applicability, version and permission

Match source scope to the employee's current attributes before giving the passage to the model: country, legal entity, role, department, employment type, work location and start date. Missing context should produce a question and not a guess. If the policy depends on country, ask for the work country or read it from an approved identity attribute, and do not pick the most frequently retrieved policy.

A current URL can still show a policy that is not yet effective, so compare the employee's relevant event date with the policy interval and keep future, current and retired versions distinct in the index. Make the version visible. The GitLab onboarding handbook page ends with its last-modified date, the change message and a commit hash, which is the kind of version label the evidence panel should show next to the owner. When two active sources disagree, stop: do not let a ranking score decide company policy. Mark the state conflicting and route it to the accountable owner.

The answer and its evidence share one permission boundary. In the preview of sensitivity-label support in Azure AI Search, the retrieve response returns label information for each reference, which clients can use for display banners and policy enforcement. That is the shape to copy: permission data travels with every reference, so rendering can check it again after retrieval. Never cite a restricted document to an employee who cannot open it, because it reveals that hidden material exists and leaves the employee unable to verify anything. Offer an approved employee-facing source or route the question to an owner who can give a shareable answer. Check permissions against current identity and group data, since a role field copied on the first day goes stale after a transfer.

Mark old answers stale in the employee's history

New hires screenshot answers, paste them into notes and reopen old chats. Store source_version with every answer, and when a revision supersedes it, flag the earlier answers that cited it. When the employee reopens the chat, show that the answer was based on the earlier version, that the policy has since changed, and a button to ask again. You cannot recall a screenshot, but you can stop your own interface from presenting a superseded answer as current.

One claim, one passage, one of four states

Do not put three links at the bottom of a long answer. Put the evidence beside the sentence it supports, so that a deadline, an approval rule and an exception each have their own passage. The employee-facing panel shows the action in plain language, the quoted passage, the source title and owner, the version and effective date, why it applies to this employee, a link they can open, and a challenge button or named support route. Keep the passage short enough to inspect: a link to a 70-page handbook hands the verification burden back to the new hire.

Use four output states:

• Verified: passage, scope, version and permission all pass.
• Needs context: an employee attribute required for scope is missing, and the answer asks one specific question.
• Conflicting: two applicable active sources disagree, and the answer names the policy owner without recommending anything.
• Unavailable: no accessible passage directly supports the claim, and the answer says it could not verify and gives a support route.

Only verified claims appear as instructions. This is more useful than a confidence percentage, because a score of 82 percent does not tell an employee whether the policy applies to their country or whether the source is current.

Who owns what

People Operations owns the policy meaning and the employee-facing correction. Knowledge managers own source structure, metadata, review dates and retired versions. IT owns identity attributes and access enforcement. The AI platform team owns retrieval, claim binding, fallback behavior, logging and tests. Kipwise's employee onboarding workflow combines assigned reading with searchable company knowledge. In that kind of system, the evidence contract should work in both places. A generated answer and an assigned onboarding task should resolve to the same governed source version. Settle five points for every source collection: who approves its meaning, who updates its metadata, which employee attributes define scope, how quickly a challenge gets a response, and what happens to answers when the source expires. A source without an owner should not support a consequential instruction.

Checking one answer by hand

If you are the person checking an AI answer today, check the claims and ignore the prose. List what could change a decision: numbers, dates, names and conditions. Open the cited source and find the sentence that states each one, because a page merely about the topic does not count. Then check three things the assistant cannot see for you: that the sentence applies to your country, entity and employment type, that its version is current, and that the named owner still owns the rule. Asking the same assistant to double-check is not an independent check, since it works from the same retrieved text. Whatever you cannot find in the source goes to the owner before you present it.

Test with realistic employee contexts

Unit tests for URLs are not enough. Build a matrix of questions and identities that exercises the scope boundaries: an in-scope employee gets the correct passage, a contractor gets the contractor rule, two countries get their own policies, a future policy does not govern an earlier start date, a retired version cannot support a new answer, a user without access cannot retrieve or see the passage, a missing location triggers a clarifying question, conflicting sources trigger owner escalation, paraphrases bind to the same governing evidence, and every citation link opens for the test identity. Also test claim precision. If the source says approval is required, the answer must not name an approver the passage does not identify, and if it states a general rule, the answer must not add an exception. Record failures by layer (source, metadata, identity, retrieval, support check, generation, permission or rendering) so the right owner fixes the defect and nobody changes the prompt after every incident.

Before release, sample consequential answers and ask whether the employee can see the exact passage, whether it states the action shown, whether the source version is active for the relevant date, whether its scope matches the employee's identity and location, whether the employee can open it, whether the owner is visible, whether a failed check blocks the instruction, and whether the employee can challenge the answer without starting over. A citation that merely points to a related page fails the gate.

Trace one live answer

Choose one consequential topic, such as equipment access, benefits enrollment or required security training, and trace every instruction in one live answer back to a passage. An instruction without a direct, applicable, current and accessible passage becomes a blocked claim until its owner repairs the evidence path. Then add scope and version metadata to the governing sources, enforce document permissions, implement the four output states, and test across at least two roles and two locations before expanding.