Corporate AI Knowledge Base: Architecture for an Internal Assistant
Build an internal assistant around current, permitted and inspectable evidence
Source contracts, staged ingestion, permission-aware retrieval and human review
Original KBASE-9 workflow with an input/output example and acceptance criteria
corporate AI knowledge base, internal assistant architecture, enterprise RAG assistant, permission-aware retrieval, AI knowledge base and KBASE-9
$ initialize knowledge-base --contract KBASE-9
> register: source / owner / revision / scope
> stage: extract / normalize / chunk / attach locator
> verify: access / currentness / known-answer / no-answer
> promote: candidate version / eligible retrieval
> reconcile: source registry / index / answer receiptA corporate AI knowledge base is not a folder of documents connected to a chat window. It is an operating system for evidence: it decides which source may be used, for whom, at which version, with what answer boundary, and how a person can inspect or correct the result.
This guide answers a narrow implementation question: how to design an internal assistant around a controlled knowledge base. For the broader service scope, see RAG systems. If the task needs a delivery plan, ownership model and controlled pilot, start with an AI engineering brief. Neither page promises that a general-purpose chatbot can safely replace a source of truth.
Start with the decision the assistant is allowed to support
The first architecture decision is not the model or the vector database. It is the job the assistant may perform. A useful bounded job has a known reader, evidence sources, consequence of a wrong answer, and a named owner. Examples include helping support staff find the current approved procedure, helping a sales team locate a product rule, or helping an operations team compare an exception against a policy.
Write down what the assistant must not do as well. It should not invent policy, reveal documents outside the caller's scope, silently turn a draft into an approved decision, or pretend that absent evidence is an answer. A concise no-answer route is a feature: it tells the employee when to open the source, ask an owner or create a content gap.
Before ingestion, build a source register. Each source needs a stable identifier, business owner, audience or permission scope, version or revision marker, lifecycle state, update path and a human-openable URL. A file that is useful but has no owner or update path belongs in a review queue, not in production retrieval.
Model the knowledge contract before the index
The assistant should retrieve evidence, not just semantically similar text. A practical knowledge contract separates four records:
| Record | Minimum fields | Why it exists |
|---|---|---|
| Source | ID, owner, revision, scope, lifecycle, locator | Establishes the authority of a document |
| Derived chunk | source ID, revision, locator, text hash, access labels | Makes each retrieval result traceable |
| Request | user identity, role, tenant, purpose, timestamp | Applies the same boundaries at query time |
| Answer receipt | retrieved IDs, versions, policy decision, feedback | Makes a response reviewable after delivery |
The source record is authoritative. Chunks, embeddings and index rows are replaceable projections. This distinction prevents a common failure: an old chunk survives in an index after the underlying procedure was revised or access was removed.
Use source metadata for retrieval filters, not only for reporting. A department, tenant, role, document state, language and effective date may decide whether a candidate is eligible before similarity ranking begins. If a system cannot enforce a boundary consistently at retrieval time, it should not claim that its permissions are inherited from the document system.
Design the workflow as a controlled path
The following KBASE-9 path is an original implementation pattern. It is deliberately small enough to test on one department before a wider rollout.
- Register. Accept a source event with source ID, revision, owner, scope and lifecycle.
- Validate. Reject incomplete metadata, unsupported formats and unowned sources into a visible queue.
- Derive. Extract text, normalize it, create deterministic chunks and attach source locators.
- Stage. Write the candidate version outside the live retrieval set.
- Verify. Check count, hashes, permissions, known-answer probes and deliberate no-answer probes.
- Promote. Atomically expose only the verified candidate version to eligible requests.
- Answer. Retrieve permitted evidence, produce a bounded answer and return source citations plus uncertainty.
- Review. Route low-confidence, conflicting or consequential requests to a named person.
- Reconcile. Compare the source register, staged jobs and live index; retry, quarantine or remove stale projections.
The important boundary is between staging and promotion. A successful extraction job is not enough evidence that the assistant may use the result. Promotion needs explicit checks, and removal needs a fast exclusion gate so that revoked or obsolete material stops appearing while downstream stores converge.
Example: a request and a reviewable answer
An operations employee asks: “Which approval is required for an exception to the current purchase policy?” The request carries the employee's role and department. The retrieval layer first limits candidates to current procurement policies that that role can view. The answer then names the relevant rule, links to the revision, shows the section locator and says whether the exception requires a manager or finance owner.
If the two current documents disagree, the assistant should return the conflict and route rather than choose a policy by wording similarity. A good response can be short:
Evidence found: procurement-policy / revision 18 / section 4.2
Scope match: operations / approved access
Decision: manager approval required; finance review is required above the stated threshold
Uncertainty: a second current source has a conflicting exception rule
Route: procurement owner / attach both source locatorsThis is more useful than a fluent generic answer because the reader can inspect the evidence and the owner can repair the source conflict.
Treat integrations as contracts, not connectors
An internal assistant often touches a document system, identity provider, business application and feedback or ticketing destination. Naming the software does not make the integration safe. Each boundary needs a contract.
The document connector must expose a stable source ID, revision signal, deletion event or periodic reconciliation, permission labels and a usable locator. The identity boundary must resolve the active user and group claims without trusting client-supplied role text. A writable destination needs idempotency or duplicate-safe lookup, a named owner and an independent read-back. The assistant should preserve the request and answer receipt without copying sensitive source content into an uncontrolled log.
For scheduled ingestion, plan for duplicate, out-of-order and missed events. A job key such as sourceId + revision + pipelineVersion makes retries inspectable. A reconciliation pass catches source changes that the event stream missed. A deletion or access-revocation event should first exclude affected source IDs from retrieval, then remove their derived representations and verify absence with probes.
Define acceptance criteria before the pilot
A pilot is ready for real internal users only when the team can test the important failure paths. Acceptance criteria should be observable and tied to one owner.
- A permitted user can retrieve a current approved source and open the cited locator.
- A user outside the scope cannot retrieve that source through normal wording variants.
- A revised document becomes current only after the staged candidate passes checks.
- A removed or revoked source is excluded from retrieval before the removal workflow reports complete.
- A deliberately unanswerable request results in a no-answer or review route, not a fabricated procedure.
- A conflicting source set is visible to the reviewer with source IDs and revisions.
- A failed job is retryable or quarantined with a reason, rather than silently disappearing.
- An answer receipt can be matched to its retrieved source versions and policy decision.
Do not express these as generic accuracy percentages unless a team has a defined test set, sampling method and acceptance threshold. For an early pilot, a curated evaluation set with known answers, access-denied cases, stale revisions and no-answer cases is more actionable than a dashboard number with unclear meaning.
Operate the assistant as a changing system
After launch, the knowledge base needs routine ownership. Monitor source-to-index lag, candidate promotion failures, permission-denied retrieval attempts, citation coverage, no-answer rate, conflict routes and feedback that resulted in a source correction. These signals point to different problems: a no-answer can be a healthy boundary, while a surge after a procedure update may reveal an ingestion or ownership gap.
Give every source class a review rhythm and retirement path. The assistant must show when evidence is stale enough that a human should decide. When a source owner leaves or a document stops receiving revisions, make its lifecycle explicit; do not let it stay “current” because the last index job succeeded.
Expansion should follow proof, not interface demand. Add one department, one source family or one consequence level at a time. Reuse the same register, permission checks, evaluation set, review route and rollback path. This keeps a corporate AI knowledge base inspectable as it grows.
A controlled first pilot
Choose one narrow internal question with a responsible owner, a bounded source collection and a clear no-answer route. Create the source register, build a staged ingestion path, test access and stale-content cases, then release only to that group. Review answers and source gaps with the people who own the underlying procedure.
That is the practical architecture of an internal assistant: current permitted evidence, visible uncertainty and accountable human control. To discuss a controlled RAG pilot for a specific workflow, use the RAG systems service page or start an AI engineering brief.
require(source.id && source.owner && source.revision && source.scope);
require(candidate.locators.length && candidate.accessVerified);
require(testSet.knownAnswer && testSet.accessDenied && testSet.noAnswer);
if (!candidate.accepted) route = "retry-or-quarantine";
if (source.revoked || source.stale) route = "exclude-from-retrieval";
if (answer.conflict || answer.consequential) route = "named-human-review";