How to Resolve Conflicting Policies in an AI Onboarding Company Brain

Colorful letters and a question mark scattered on a desk

Conflicting policies in AI onboarding can produce an answer that sounds clear but relies on the wrong rule. A new hire asks how to approve an expense. The company brain finds a current finance policy, an old team checklist, and a regional exception. Sending every passage to a model may produce one response that combines incompatible instructions. A longer prompt cannot fix missing authority rules. Build a source precedence layer that filters unauthorized material, identifies the governing document, detects unresolved conflicts, and stops when the evidence is ambiguous. The new employee should receive either a cited answer or a specific handoff.

Why contradictory answers survive retrieval

Retrieval augmented generation gives a model access to external knowledge instead of relying only on training data. The AWS explanation of retrieval augmented generation describes retrieval as a way to ground responses in company data and keep source knowledge updateable. Grounding helps, but retrieval does not decide which of two company documents has legal or operational authority.

These failures usually start before generation. Teams index pages from a wiki, shared drives, handbooks, ticket templates, and chat exports. The sources use similar terms, so semantic search can rank several of them highly. A procedure written for one country may look more relevant than a global policy. A detailed checklist may outrank the short policy that governs it. An obsolete document may remain searchable because nobody marked its replacement.

The model then receives evidence with no explicit hierarchy. It may select the most detailed passage, merge the passages, or hedge between them. None of those behaviors establishes policy authority. The system needs a deterministic decision before prose generation begins.

Access control must come first. Microsoft's document level access control guidance shows patterns for filtering search results using user or group access. A conflict resolver must compare only documents the employee is allowed to retrieve. It must not reveal that a restricted policy exists, quote it during comparison, or use it to shape an answer.

Define what makes a source authoritative

Create a small metadata contract for every source that can support an onboarding answer. Do not ask the model to infer these fields from writing style. Record them when content is published or ingested.

document_id: expense-policy-uk-v5
document_type: policy
policy_domain: expenses
jurisdiction: united-kingdom
audience_groups:
  - all-uk-employees
owner: finance-operations
approver: chief-financial-officer
effective_from: 2026-06-01
expires_at: null
supersedes:
  - expense-policy-uk-v4
status: approved
source_url: /handbook/finance/uk-expenses
last_reviewed_at: 2026-06-01

The minimum useful fields are domain, scope, owner, approval state, effective date, replacement relationship, and access policy. Add jurisdiction, employment type, business unit, or product line only when those attributes change which rule governs the employee.

Document type matters. A policy defines a rule. A procedure explains how to follow it. A checklist helps someone complete the procedure. A chat message may clarify an incident, but it should not silently override an approved policy. Set an explicit default order, such as:

  1. Approved policy for the employee's applicable scope
  2. Approved exception that names that policy and scope
  3. Current procedure linked to the governing policy
  4. Current onboarding task or checklist linked to the procedure
  5. Informal guidance used only for discovery, never as sole authority

This order is an implementation rule, not a universal legal hierarchy. People operations, legal, security, and each policy owner should approve the order for their domains. The NIST AI Risk Management Framework organizes AI risk work around governing, mapping, measuring, and managing. For source precedence, that means assigning decision ownership, mapping policy domains, measuring conflict behavior, and managing unresolved cases.

Resolve scope before comparing text

A company brain should determine the employee's context from trusted systems before retrieval. Useful attributes include location, legal entity, department, employment type, role, and start date. Do not let a chat prompt override identity or HR records.

Suppose a new salesperson in London asks, "How much can I spend on a client dinner?" The resolver should convert that question into a policy domain and trusted context:

{
  "policy_domain": "expenses",
  "user_context": {
    "legal_entity": "example-uk-ltd",
    "location": "united-kingdom",
    "department": "sales",
    "employment_type": "employee",
    "groups": ["all-employees", "uk-employees", "sales"]
  },
  "as_of": "2026-07-27"
}

Use the group list to enforce access. Use legal entity, location, and employment type to select applicable policy scope. Use the question and department to improve relevance. Keeping those functions separate prevents a highly relevant restricted page from entering the candidate set.

Public onboarding programs demonstrate why context cannot be reduced to one universal list. The GitLab onboarding handbook links structured tasks, role templates, access requests, buddies, and source material. A company brain should preserve those relationships. It should know whether a checklist is an onboarding aid, a procedure, or the governing rule.

Apply a deterministic source precedence sequence

Run conflict resolution after authorization filtering and before answer generation. A practical sequence looks like this:

function resolve_policy(question, user):
    context = load_trusted_user_context(user)
    candidates = retrieve(question, access_filter=context.groups)
    candidates = keep_effective_documents(candidates, today())
    candidates = keep_applicable_scope(candidates, context)
    groups = group_by_policy_domain(candidates)

    for group in groups:
        governing = select_approved_policy(group)
        exceptions = select_applicable_exceptions(group, governing)
        supporting = select_linked_procedures_and_checklists(group, governing)

        if has_two_governing_documents(governing):
            return escalate_conflict(governing, question, context)

        if supporting_contradicts(governing, supporting):
            flag_for_owner_review(supporting)
            supporting = remove_contradictory_support(supporting)

        return generate_cited_answer(governing, exceptions, supporting)

First remove documents that are not effective on the answer date. An expired document can remain in the archive without remaining eligible for ordinary retrieval. Next apply scope. A global policy and a country exception may both be valid, but the exception must explicitly identify the rule it changes. Do not assume that a more specific page overrides a broad policy unless your metadata says so.

Then follow explicit relationships. supersedes, exception_to, and implements are more reliable than text similarity. If the current procedure links to policy version 5, an old checklist linked to version 4 should not support the answer.

Detect any conflict that remains after those checks. Two approved, effective policies in the same domain and scope indicate a governance defect, not a ranking problem. Stop generation and route both policies to the accountable owner.

Give new hires an answer they can inspect

A resolved answer should state the applicable rule, the scope that made it applicable, and the source. It should separate mandatory policy from practical steps.

For example:

> For UK sales employees, client dinners up to the approved regional limit require manager approval in the expense system. This answer uses the UK expense policy effective 1 June 2026. Follow the linked submission procedure for receipt and cost center requirements.

Show the policy title, effective date, owner, and direct link beside the answer. If a procedure contributes steps, cite it separately. This lets the employee see that the rule and the workflow come from different document types.

Do not display a synthetic confidence percentage unless real evaluations have calibrated it. Use an operational status instead: resolved, resolved with an applicable exception, or unresolved and escalated. Each label corresponds to an action the system can verify.

Handle conflicts without leaking or guessing

An unresolved response should be useful without exposing restricted evidence. Tell the employee what is known, what remains unclear, who owns the decision, and when they can expect a response.

A safe handoff might say:

> I found two current expense documents that may govern this request, so I cannot confirm the limit. I sent the question and the permitted source references to Finance Operations. Do not submit the expense until the owner confirms which policy applies.

The escalation record should include the question, employee context needed for scope, permitted candidate document IDs, conflict reason, and assigned owner. Do not copy restricted passages into a ticket the employee can view.

When the owner resolves the issue, update the source metadata or content. The Kipwise guide to keeping a knowledge base up to date recommends clear ownership, review workflows, and collaborative maintenance. A resolution that lives only in the support ticket leaves the next new hire exposed to the same contradiction.

Test the resolver with conflict fixtures

Build a small evaluation set before rollout. Each fixture should include the question, trusted user context, candidate sources, expected governing document, expected citations, and expected action.

Cover at least these cases:

  • A current policy and an expired predecessor
  • A global policy and an explicit regional exception
  • A policy and a procedure that uses outdated limits
  • Two current approved policies with the same scope
  • A relevant restricted policy and a less relevant permitted policy
  • A checklist that links to a superseded procedure
  • A question with no approved governing source

For every case, verify four layers. First, unauthorized documents never enter the generation context. Second, the expected source wins only through metadata and policy relationships. Third, the answer cites the rule and separates it from procedure. Fourth, unresolved conflicts create an owner task instead of a guessed answer.

Track conflict rate by policy domain, time to owner resolution, repeated conflict count, and the share of answers supported by an approved governing source. Review samples of resolved answers as well as escalations. A low escalation rate is not success if the system quietly chooses the wrong policy.

Common mistakes to avoid

Do not use document recency as the only authority signal. A new team note can be less authoritative than an older approved policy. Effective date, approval state, scope, and explicit replacement links carry different meanings.

Do not solve contradictions by placing every source in a larger prompt. More context can preserve the conflict while making the final answer sound more comprehensive.

Do not let a source owner approve their own exception when your governance model requires another approver. Store both owner and approver when separation matters.

Do not hide conflicts from knowledge owners. Aggregate repeated conflict records into a maintenance queue and fix the source graph. The company brain should expose documentation defects, not normalize them.

Make source precedence part of onboarding governance

Prompt wording alone cannot resolve conflicting policies in AI onboarding. Start with one domain where a wrong answer would cause a real problem, such as expenses, access requests, leave, or security reporting. Define the document types, authority order, scope fields, owner, approver, and escalation target. Add five conflict fixtures. Run them through authorization and precedence checks, then refuse generation whenever two governing sources remain.

The next action is specific: choose one onboarding question that currently produces inconsistent answers, map every source that can answer it, and mark which document governs each employee scope. If your team cannot make that decision outside the model, the model should not make it for a new hire.

References

Want a better team wiki?
Try Kipwise - integrated with your favorite everyday tools