Skip to main content

Enterprise knowledge assistant

The answer needs a source. The source needs permission.

An enterprise knowledge assistant answers staff questions from approved organizational sources, with citations that support each material claim. It helps people find relevant records while showing missing, stale or conflicting evidence. Werkon would validate this retrieval and correction pattern with access checked before both retrieval and release; source owners retain policy interpretation and consequential decisions.

Preserve source authority and access

Keep native identifiers, authorship, revisions, digests, retention and supersession when indexing records, messages, tables and media. Source update time, index time, policy review and business validity are different dates. Freshness depends on the source and question; popularity and embedding similarity cannot outrank named authority.

An inferred question scope or job title cannot grant permission. Retrieve the smallest authorized evidence set and check access again before release. Citations, snippets and suggestions must not leak restricted content. Treat copied text, metadata, links and embedded instructions as untrusted data.

Make the answer inspectable and correctable

Link claims to exact passages, cells, pages, time ranges or fields. Distinguish source facts, user assertions, deterministic transformations and generated synthesis. Expose disagreements and unavailable evidence instead of creating false consensus or filling gaps from model memory.

Keep query, identity, policy, corpus, retrieval, model, citation and review versions. Qualified owners handle sensitive aggregation, source conflicts and regulated interpretation. Propagate corrections, withdrawal, revocation and deletion into future answers and permitted answer history; uncontrolled caches must not retain deleted material.

Knowledge boundary

Answer from what the user may inspect, not everything the system can reach.

Internal knowledge has owners, versions and audiences. Four boundaries preserve access, evidence and accountability from question to correction.

01

Question, identity, purpose, and audience

Bind each request to the current tenant, user or service identity, role, purpose, session, device, requested audience and permitted action; clarify ambiguous scope; and reject identity, delegation or purpose that cannot be verified.

Required evidence: Tenant, subject and service identity, authentication context, role and attributes, team, purpose, session, device posture where applicable, delegated scope, requested audience, question text, clarification, sensitivity candidate, action class, policy decision, denial reason and expiry.

02

Source authority, permission, and currency

Inventory approved sources with owner, classification, access policy, authoritative scope, version and effective period; enforce source-native and system policy at retrieval; track change, supersession and invalidation; and distinguish technical recency from business validity.

Required evidence: Repository and object identifiers, owner, source type, authoritative question class, classification, access-control version, source-native decision, version, digest, author, created, modified, effective, reviewed, indexed, expired, superseded and invalidated times, retention state and coverage gap.

03

Retrieval, claims, citations, and uncertainty

Retrieve a minimum permission-safe evidence set; preserve exact locations and structured values; separate source text from transformation and synthesis; test supporting and contradicting evidence; and produce claim-level citations, qualifications, refusals or named gaps.

Required evidence: Query and filter, corpus snapshot, retrieval and reranking versions, source passage, page, cell, row, field or time range, exact quote digest, claim identifier, derivation, deterministic transform, support and contradiction links, uncertainty, missing source, refusal, citation display and answer version.

04

Review, release, feedback, and correction

Route consequential interpretation, source conflict and sensitive aggregation to qualified owners; recheck identity, permission and source state before release; collect evidence-specific feedback; and propagate corrections, revocation, deletion and supersession without rewriting history.

Required evidence: Review trigger, reviewer role and scope, cited evidence, decision and rationale, permission recheck, source-state recheck, approved audience, release receipt, user challenge, issue class, correction, source-owner response, affected answers, withdrawal, supersession, deletion handling and incident record.

Question-to-answer path

Make permission and provenance visible at every stage.

A relevant passage can still be restricted, obsolete or taken out of context. Each stage protects the evidence needed to inspect the next one.

  1. 01

    Authorize the question

    Resolve tenant, identity, role, purpose, audience and question class; clarify scope and consequence; choose the allowed source boundary; and block requests that require unverified delegation, excessive access or an unsupported purpose.

    Owner
    Identity, security, privacy and knowledge owners
    Evidence
    Identity and session, role and attributes, purpose, audience, question, clarification, sensitivity and consequence class, delegated scope, applicable policy, permitted repositories, excluded sources, decision and expiry.
  2. 02

    Resolve authoritative sources

    Map the question to approved repositories and source owners; apply source-native permissions; select current authoritative versions; preserve superseded and conflicting evidence; and surface unavailable, stale or uncovered areas before retrieval continues.

    Owner
    Records, repository, domain and access owners
    Evidence
    Source catalog, owner, authoritative scope, classification, access result, version, digest, effective and review dates, supersession, invalidation, retention, index state, conflict, unavailable source and coverage status.
  3. 03

    Retrieve and construct evidence

    Search only the authorized snapshot, retain exact source locations, resolve entities and references, apply deterministic calculations where needed, rank by authority and relevance, reject embedded instructions and assemble supporting and contradicting evidence.

    Owner
    Search, data, security and domain owners
    Evidence
    Corpus snapshot, access filter, query, retrieval and reranking configuration, source identifiers, passages and structured fields, transformations, entity links, authority rank, relevance, contradiction, prompt-injection result and missing evidence.
  4. 04

    Draft, cite, and review

    Compose only supported claims, attach precise citations, distinguish quotation, source fact, calculation and interpretation, expose uncertainty and conflict, refuse unsupported conclusions and route consequential or sensitive output to an authorized reviewer.

    Owner
    Knowledge, domain, legal, privacy and operational reviewers
    Evidence
    Answer and claim identifiers, claim-to-source map, source excerpts, model and prompt versions, uncertainty, contradiction, refusal, review trigger, reviewer, correction, accepted wording and unresolved gap.
  5. 05

    Release, observe, and correct

    Recheck identity, permissions, source versions and audience; release the answer without granting new authority; record receipt and evidence-specific feedback; detect source changes; and withdraw, correct or supersede affected answers visibly.

    Owner
    Knowledge operations, source owners and correction owners
    Evidence
    Release-time identity, permission and source checks, audience, answer receipt, access log, feedback, unsupported-claim report, source change event, affected-answer link, correction, withdrawal, supersession, deletion handling and incident review.

Authority map

Separate access enforcement, synthesis, and accountable interpretation.

A model can connect passages. It cannot grant itself access, decide which policy applies or turn a plausible synthesis into enterprise truth.

01

Deterministic knowledge software

Software owns identity binding, source inventory, policy evaluation, access filters, version and digest checks, exact retrieval records, source locations, structured calculations, release validation, logs, change detection, correction and deletion propagation.

  • Tenant, identity, repository, object, version, claim and answer identifiers
  • Source-native authorization, classification, purpose and audience checks
  • Digests, timestamps, effective periods, citations and deterministic transforms
  • Release, feedback, correction, revocation, withdrawal and deletion receipts
02

Bounded AI assistance

AI can propose query interpretations, semantic matches, entity links, summaries and answer wording from permitted evidence, but every claim remains a candidate with visible sources, uncertainty, contradictions and missing coverage.

  • Question, intent and clarification candidates
  • Semantic retrieval, reranking and related-source candidates
  • Source-linked synthesis, comparison and explanation candidates
  • Conflict, sensitive-aggregation, stale-source and unsupported-claim candidates
03

Human source and decision authority

Qualified people own source authority, access policy, business validity, policy interpretation, sensitive aggregation, consequential advice, conflict resolution, exceptions, correction, deletion and every decision that uses the answer.

  • Repository ownership, classification, authoritative scope and access exceptions
  • Policy, legal, security, employment, financial and clinical interpretation
  • Conflict resolution, sensitive audience, release and operational decision
  • Source correction, retention, deletion, incident and stop authority

Knowledge-assistant components

Build a permission-aware evidence graph, not a universal memory.

Identity, source content, policy and business meaning change on different clocks. Four components keep those changes inspectable.

01

Identity, purpose, and access registry

Bind tenant, user and service identities to current roles, attributes, teams, devices, sessions, delegated purposes, audiences, classifications and source-native permissions with explicit effective periods, denials and revocation.

Operating contract: Authentication is not universal access, role is not purpose, membership is not need to know, source visibility is not permission to quote, prior access is not current access and the assistant never expands an identity's authority.

02

Source, version, and provenance ledger

Inventory repositories and objects with owner, authoritative scope, classification, source identifier, author, version, digest, derivation, created, modified, effective, reviewed, indexed, superseded and invalidated state, retention and access policy.

Operating contract: Copy is not original, modified is not effective, indexed is not current, newest is not authoritative, owner label is not review, revision must not erase prior state and deletion must not leave an ungoverned retrieval copy.

03

Retrieval, claim, and citation ledger

Record the authorized corpus snapshot, filters, queries, candidates, exact passages and structured fields, authority and relevance ranking, transformations, model versions, claims, supporting and contradicting evidence, citations, uncertainty, refusal and gaps.

Operating contract: Similarity is not authority, nearby text is not support, citation is not correctness, source count is not completeness, absence is not a negative fact, generated synthesis is not a record and restricted context must not leak through snippets or aggregation.

04

Review, answer, and correction ledger

Bind review triggers, qualified reviewers, rationale, release-time access and source checks, audience, answer receipts, evidence-specific feedback, source changes, affected answers, corrections, withdrawals, supersession, revocation and deletion handling.

Operating contract: Review click is not expertise, release is not approval for action, useful feedback is not source truth, a correction must preserve history, revoked access must affect future answers and source change must identify which prior answers need review.

Delivery path

Prove one question class before widening the corpus.

A narrow, permission-sensitive question reveals more than a broad search demo. Five steps test source authority, evidence quality and operating ownership together.

  1. 01

    Choose the question class

    Select one recurring internal question with named users, purpose, audience, consequence, source owners and a safe manual answer path; record excluded questions and protected populations.

  2. 02

    Build the source contract

    Inventory exact sources, versions, ownership, authoritative scope, classification, permissions, freshness, retention, supersession, deletion and known coverage gaps before indexing any content.

  3. 03

    Create the evidence chain

    Implement identity-bound retrieval, source-native permission checks, stable locations, version and digest capture, authority-aware ranking, claim-level citations, contradiction handling, refusal and source-change tracking.

  4. 04

    Evaluate real failure modes

    Test unauthorized users, sensitive aggregation, stale and superseded documents, conflicting authority, missing sources, misleading citations, embedded instructions, ambiguous questions, source outages and deletion propagation.

  5. 05

    Operate review and correction

    Assign source and review owners, define escalation and stop thresholds, observe unsupported claims and permission denials, trace feedback to evidence and rehearse correction, revocation, withdrawal and retirement.

Release controls

Six controls before an internal answer can be trusted for use.

Fluency hides missing evidence. These controls keep permission, provenance, freshness and consequence visible.

Identity and purpose are current
Bind the active tenant, subject, service, session, role, attributes, delegated purpose and audience; apply least privilege; expire cached decisions; and deny rather than infer access when identity or purpose is unresolved.
Source authority and coverage are explicit
Name which repository and version is authoritative for the question, who owns it, which sources are excluded or unavailable and whether the permitted corpus is sufficient to answer.
Freshness is business-specific
Track created, modified, effective, reviewed, indexed, expired, superseded and invalidated state separately; define question-specific age and revalidation rules; and never treat transport or index recency as content validity.
Every material claim is inspectable
Attach exact source locations and versions, label quotations, calculations and synthesis, preserve contradicting evidence and make missing, inaccessible or unsupported material visible in the answer.
Consequential interpretation has an owner
Escalate policy conflicts, regulated guidance, sensitive aggregation, access exceptions and decisions with material effect to qualified owners, and keep approval to act outside the answer workflow.
Correction can reach prior answers
Link source change, revocation, deletion and user challenge to affected claims and answers; preserve history; notify the right owner; and support visible correction, withdrawal, supersession and stop.

Outcome evidence

Measure supported, permitted answers, not query volume.

A busy assistant can spread stale or restricted information faster. Evidence must show whether the pattern improves a bounded knowledge task without increasing leakage or hidden review.

Baseline

  • Question classes, users, purposes, audiences, authoritative sources, manual paths and consequence tiers
  • Current search success, source-open rate, time to evidence, escalation, abandonment and rework by question class
  • Known duplicate, stale, superseded, conflicting, missing and inaccessible sources and current correction flow
  • Current access incidents, oversharing paths, citation defects, review burden and unresolved user challenges

Outcome evidence

  • Answered, clarified, refused and escalated questions by class with complete permitted-source coverage
  • Material claims with correct source, version and location and reviewer-confirmed support
  • Time to usable evidence, accepted answer, resolved gap and qualified owner response, including human effort
  • Source changes detected and affected answers corrected, withdrawn or superseded within agreed bounds

Guardrails

  • Unauthorized retrieval, cross-tenant exposure, snippet leakage, sensitive aggregation and credential exposure
  • Unsupported claims, misleading citations, stale or superseded answers, hidden contradictions and missing-source concealment
  • Policy misinterpretation, harmful reliance, incorrect escalation, reviewer overload and action without authority
  • Deletion or revocation failures, correction misses, private-content retention, ungoverned learning and unresolved incidents

Fit test

Use this pattern when sources and answers both have owners.

Good reason to begin

  • A bounded internal question class recurs across known repositories and manual answers require repeated source discovery.
  • Identity, source ownership, permissions, versions, effective dates and qualified escalation can be made explicit.
  • Users need inspectable citations and named gaps more than a confident conversational response.
  • The organization can test permission leakage, stale sources, conflicts, corrections and harmful reliance before release.

Resolve before beginning

  • No one owns the sources, access model, authoritative versions, review cadence or correction path.
  • The request assumes that everything employees can find may be copied into one unrestricted assistant.
  • Success is defined as answer volume, speed or deflection without evidence quality, access safety or downstream outcome measures.
  • The assistant is expected to interpret consequential policy or authorize action without qualified review and separate decision authority.

Source basis

Sources behind the control model.

  • 01

    National Institute of Standards and Technology

    NIST SP 800-207, Zero Trust Architecture

    The final August 2020 publication defines zero trust around users, assets and resources, rejects implicit trust based only on network location or ownership and separates authentication and authorization before a resource session. It is an abstract architecture and set of deployment models, not a knowledge-assistant design, authorization decision, implementation certification or proof that retrieved content may be disclosed.

  • 02

    International Organization for Standardization

    ISO 15489-1:2016, Records management concepts and principles

    ISO lists Edition 2 as published in April 2016, reviewed and confirmed in 2021 and therefore current. It covers records, metadata, systems, policies, assigned responsibilities, monitoring, recurrent business-context analysis, controls and creation, capture and management over time. It does not designate an enterprise source as authoritative, grant access, define answer freshness, validate an interpretation or certify this pattern.

  • 03

    World Wide Web Consortium

    PROV-O, the PROV Ontology

    The 30 April 2013 W3C Recommendation provides classes and properties for representing and interchanging provenance across systems, including entities, activities, agents, derivation, attribution, revision and invalidation. It is a stable provenance vocabulary, not proof that recorded provenance is true, complete, permission-safe, current in business meaning or sufficient to support an answer.

  • 04

    National Institute of Standards and Technology

    NIST AI 600-1, Generative AI Profile

    NIST released the Generative AI Profile on 26 July 2024 as a voluntary cross-sectoral companion to AI RMF 1.0 and identifies risks including confabulation, information integrity, privacy, human-AI configuration and provenance, with evaluation and monitoring actions. The underlying AI RMF 1.0 is under revision. The profile does not prove an answer, citation, permission decision, corpus, implementation, compliance or outcome.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Explore governed AI agents

Compare other bounded agent patterns and the evidence, authority and recovery contracts they require.

Open path02

Design knowledge management

Define source ownership, lifecycle, discovery, use and correction before adding an answering layer.

Open path03

Build a governed AI agent

Enclose model-assisted work with explicit identity, permissions, tools, approvals, evidence and stop paths.

Open path04

Engineer the source layer

Make data contracts, lineage, quality, change and operational ownership explicit across source systems.

Open path