---
name: build-and-maintain-ai-knowledge-base
description: Your team should not have to hunt through old chats for key facts.
category: Knowledge System Maintenance
stage: —
definitive_article: https://blitzmetrics.com/how-to-build-use-publish-ai-knowledge-base/
status: needs-work
---

# Build and maintain an AI knowledge base

Your team should not have to hunt through old chats for key facts. This guide puts source files, facts, and work notes in one home. Start with one person or business and the job you need to do.

**The path:** Allowed sources → Checked facts → Real task → Updated base

**Start when:** A scoped task needs a reliable, reusable source of facts about one real subject.

## Inputs

- The actual goal, source material and intended reader, explained in [Goals, Content and Targeting](https://blitzmetrics.com/gct-business-strategy/).
- Allowed websites, social exports, transcripts and project records; a named owner and storage/access plan.
- An existing knowledge base if one exists, with its revision and source-authority rules.

## Steps

1. Confirm the subject’s identity, the work scope and who may see each source. Use an existing approved base; installation of a separate package is only needed if that is the chosen setup.
2. Create or map separate locations for raw sources, compiled references and deliverables. Add a source index with URL or private file reference, date, owner, access limit and retrieval result.
3. Collect the agreed corpus without bypassing source access limits. Track found, captured, unavailable and excluded items. “The whole site” needs a real inventory, not an assumed count.
4. Derive four references from the material: voice with quoted examples, supported topics, goals/current project state, and entity facts such as name and role. Every claim points to its source; an uncertain identity stays unresolved.
5. At session start, read the relevant base, then verify changeable facts in the system that owns them. A newer direct instruction or authoritative record can reveal a stale compiled fact; retain the conflict and resolve it before updating.
6. Use the base for one bounded task. At wrap-up, save what changed, what shipped, actual output links, failures and next owner. Confirm a fresh session can find that state; writing a file alone does not load it into every app.
7. If public output is in scope, prepare only approved material in the correct voice with owned links. The source’s map/build-writeup/first-person-companion pattern is an editorial option requiring its own useful purpose and release authority. Keep private project records out of public copy.

## Definition of done (QA checklist)

[Quality assurance (QA)](https://localservicespotlight.com/article-guidelines/) means checking the work against the agreed result.

- [ ] Raw, compiled and finished work are separate and traceable.
- [ ] Voice, topics, identity and current state have source support and visible unknowns.
- [ ] A fresh reader can recover one task and its result; public drafts disclose no private records.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional shop base contains five public pages and one allowed interview. Two pages use an old opening time; the current owner record gives a new time. The base keeps both dated sources, marks the old time superseded, and uses the verified current time in a draft. It does not invent missing sales figures.

## Handoff and Content Factory context

This work supports the [Content Factory, our four stages of using real content](https://blitzmetrics.com/content-factory/): Produce → Process → Post → Promote. Use the specific inputs and next task below to place the work; a maintenance task does not manufacture transcripts, clips or other stage outputs it does not call for.

The next scoped task reads the base. Use [shared-memory coordination](https://local-service-spotlight.github.io/task-library/?task=coordinate-agents-with-shared-memory#task-coordinate-agents-with-shared-memory) for multi-agent work and [the publishing task](https://local-service-spotlight.github.io/task-library/?task=step-12-post-article-on-wordpress#task-step-12-post-article-on-wordpress) only for authorized public output.

## Run with an agent

Give the AI worker this recipe, the real Inputs above, the intended result and the actions already authorized. Ask it to return the saved output, checks, evidence and remaining owner. Check its work against this guide; loading a skill does not prove access, installation of a job, or successful execution. Keep media muted with volume at zero if playback is needed.

For recurring work, keep the actual trigger, owner and runtime in the job record. Scheduling and observed firings are separate. Do not create a schedule merely because this guide mentions a review interval.

## Record the real execution

Open the run record when the work starts. Keep the exact starting recipe revision, one execution ID, source evidence and actual state. Write a [meta article, the record of one run](https://blitzmetrics.com/meta-article-prompt/) with decisions, results, checks, failures and next owner. Link it to this task and register it through the [Task Library](https://local-service-spotlight.github.io/task-library/) execution process. Writing is part of the work; public release follows existing authority.

Reuse the same execution ID for revisions, QA, meta writing and retries within that run. A blocked run stays open with its dependency and next owner; do not invent a finish time. Use supported findings to propose and verify a better recipe. A historical public-example count without distinct run IDs remains dated article volume, not verified execution frequency.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 2/5 `●●○○○` — frequency 2, revenue 1, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/how-to-build-use-publish-ai-knowledge-base/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=build-and-maintain-ai-knowledge-base#task-build-and-maintain-ai-knowledge-base)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [current article guide](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, a client outcome, access or an executed task.

Actual source coverage, conflict resolution, fresh-session readback and any public output require real task evidence. The published hub still contains older package/setup and automatic-feed examples; verify those separately before using them. The fictional example teaches the method; a real example with relevant proof is still needed where required. The task-specific flow above is source guidance; its visible presentation and the full document need a named reviewer and desktop/mobile checks.