A knowledge base your team can ask

T04-L02 · Your documents & knowledge · Level 2 Power user · 26 minutes

2. The old policy gives the new answer

You ask your department's knowledge base how quickly a request must be acknowledged. It answers confidently: within five business days. The citation opens, the wording is exact, and a teammate has already copied the answer into a draft response.

Then you notice the source date. The policy was superseded two years ago. The current policy says two business days, but both files were loaded as policy-final.pdf and policy-final-new.pdf. A real sentence still produced today's wrong answer because two incompatible versions lacked a usable status signal.

You do not solve this first by changing models or writing a more forceful prompt. You solve it by deciding what the knowledge base is for, admitting only sources that fit that purpose, separating superseded material, naming current sources clearly, and assigning someone to keep the boundary current.

At Level 2, the blast radius is your team: a bad document or wrong figure becomes available for teammates to reuse. A stale protocol can waste an experiment; a stale policy can put a wrong commitment into a customer reply.

3. After this you can

• Assemble a corpus worth asking.
• Decide what not to put in it.
• Recognise a bad answer caused by a bad corpus.

4. Prerequisites

• T04-L01 · Ask questions about your own files.
• An approved document-question workspace in which you can add, inspect, and remove sources.
• Permission to create a test collection and an identified person who can confirm which sources are current.
• A local source register, such as a small spreadsheet or Markdown table.

Use only the synthetic material on this page, public sources, or explicitly approved documents. Do not upload credentials, personal data, participant or patient records, unpublished results, confidential commercial terms, security material, or production exports merely because the workspace is described as internal. Confirm the model, storage, access, retention, backup, and deletion path with the deployment owner before adding real material.

5. The idea in one page

A team knowledge base is a named collection for defined questions, not a dumping ground.

Write an inclusion/exclusion rule before adding files. State purpose, users, accepted authorities, date/version requirements, exclusions, owner, and review rhythm.

Keep one corpus boundary record for the workspace. It holds the rule and a register of each candidate's stable ID, title, owner, type, date/version, status, replacement, sensitivity decision, workspace decision, and next review date. Keep it outside retrieval unless deliberately approved as a source. It maps searchable copies but does not replace originals.

Prefer one authoritative current source for each operational rule. Keep history in a separate archive, outside current-answer searches. Exclusion is stronger than a SUPERSEDED label. Remove duplicates: repeated text can look like independent support.

Use filenames that remain meaningful outside the interface. A practical pattern is:

[topic]_[document-type]_[stable-id]_[effective-or-publication-date]_[status].[ext]

intake_protocol_LAB-P17_2026-08-15_CURRENT.pdf is clearer than final-v3.pdf. Confirm status with the owner or authoritative publication location; a filename is not proof.

For a bad answer, inspect its original citation. Did that source belong? Was a newer authority missing? Did versions compete? Repair membership, refresh by the documented process, and rerun the same test before tuning prompts.

Name an accountable owner, a review date, and triggers such as amendment, replacement, correction, or withdrawal.

6. The worked example: replace a contaminated corpus with a current one

The Lab and Company versions use the same six-step build. Each starts with eight synthetic candidate records, applies a written rule, admits five files, runs three questions, diagnoses one deliberately seeded stale-source answer, repairs the active collection, and hands upkeep to an owner.

Choose one framing

Lab framing: protocols and papers

Follow the Lab route for the fictional Northstar group's NS-7 protocols, paper, exception, and glossary.

Company framing: policies and contracts

Follow the Company route for fictional Harbor Service policies, supplier schedule, handbook, exception, and glossary.

Step 1: define the questions and source authority

Lab framing: The fictional Northstar group needs current handling and analysis answers about its NS-7 assay. Approved protocols govern; papers are background. Notes, raw exports, participant data, and superseded protocols are excluded.

Company framing: The fictional Harbor Service department needs current request and delivery answers. Approved policies and signed current schedules govern; guidance is background. Drafts, customer records, credentials, and superseded documents are excluded.

Both teams use this copy-pasteable rule structure:

Purpose: Answer [bounded question types] for [named team].
Include: [authoritative source types] with a confirmed owner, date/version, and current status.
Use as background only: [non-governing source types], labelled BACKGROUND.
Exclude: superseded or draft versions, duplicates, out-of-scope material, and any content
not approved for this workspace's model, storage, access, retention, backup, and deletion path.
Conflict rule: governing current sources outrank background; unresolved conflicts return
"conflict - ask the source owner" rather than a recommendation.
Owner: [name or role]. Review: [rhythm] and whenever a source is replaced or withdrawn.

Step 2: inventory the parallel candidates

The teams inspect these synthetic candidates. Here, status and replacement fields are owner-confirmed ground truth; do not infer authority from filenames. For real sources, record who confirmed status and when.

Each active base has slots 1, 3, 5, 7, and 8. Archive slot 2 separately; do not copy slots 4 or 6 into the base. The admitted fixtures and stale probe below reproduce the build; other exclusions are register-only examples.

Step 3: create one complete five-file fixture set

Choose one complete synthetic route. Copy each block into a separate plain-text file with exactly the shown filename. The fixtures contain no real people, organisations, participants, customers, or operations.

Lab fixture 1 — NS7_protocol_LAB-P17_2026-08-15_CURRENT.txt

Title: NS-7 Handling Protocol
Source ID: LAB-P17
Owner: Northstar protocol lead
Status: CURRENT
Effective: 2026-08-15
Replaces: LAB-P11
Rule: Record NS-7 quality-control readings after 2 hours.
Scope: Routine NS-7 runs. Consult LAB-E02 for the documented interruption exception.

Lab fixture 2 — NS7_qc_LAB-Q04_2026-07-01_CURRENT.txt

Title: NS-7 Quality-Control Review
Source ID: LAB-Q04
Owner: Northstar quality lead
Status: CURRENT
Effective: 2026-07-01
Rule: Mark a reading below 0.80 as REVIEW and notify the quality lead.
Record: Store the run code, reading, and review date in the approved run log.

Lab fixture 3 — NS7_methods_paper_SYN-A12_2025-11-20_BACKGROUND.txt

Title: Synthetic note on NS-7 measurement stability
Source ID: SYN-A12
Owner: Northstar literature coordinator
Status: BACKGROUND — NON-GOVERNING
Published: 2025-11-20
Content: In a synthetic bench demonstration, early readings varied more than later readings.
Limit: This note explains context only. It does not set timing, exceptions, or permissions.

Lab fixture 4 — NS7_exception_LAB-E02_2026-08-20_CURRENT.txt

Title: NS-7 Interruption Exception
Source ID: LAB-E02
Owner: Northstar protocol lead
Status: CURRENT
Effective: 2026-08-20
Exception: If a documented instrument interruption lasts more than 30 minutes, record the
quality-control reading after 4 hours and label the run INTERRUPTED.
Scope: This exception applies only to that interrupted run. It does not authorise a permanent change.

Lab fixture 5 — NS7_glossary_LAB-G03_2026-08-01_CURRENT.txt

Title: NS-7 Glossary
Source ID: LAB-G03
Owner: Northstar protocol librarian
Status: CURRENT
Effective: 2026-08-01
Terms: CURRENT means approved for present use. BACKGROUND means explanatory and non-governing.
INTERRUPTED means a run affected by a documented instrument interruption longer than 30 minutes.

Company fixture 1 — request_policy_CO-P17_2026-08-15_CURRENT.txt

Title: Standard Service Request Policy
Source ID: CO-P17
Owner: Harbor service policy owner
Status: CURRENT
Effective: 2026-08-15
Replaces: CO-P11
Rule: Acknowledge a standard service request within 2 business days.
Scope: Standard requests. Consult CO-E02 for the documented outage exception.

Company fixture 2 — delivery_schedule_CO-C04_2026-07-01_CURRENT.txt

Title: Synthetic Supplier Delivery Schedule
Source ID: CO-C04
Owner: Harbor supplier manager
Status: CURRENT
Effective: 2026-07-01
Rule: The synthetic office-supply delivery is scheduled for Tuesday each week.
Record: Report a missed delivery to the supplier manager within 1 business day.

Company fixture 3 — request_handbook_SYN-H12_2025-11-20_BACKGROUND.txt

Title: Synthetic service communication handbook
Source ID: SYN-H12
Owner: Harbor training coordinator
Status: BACKGROUND — NON-GOVERNING
Published: 2025-11-20
Content: A short acknowledgement can reduce uncertainty while a request is being assessed.
Limit: This handbook explains communication only. It does not set timing, exceptions, or permissions.

Company fixture 4 — request_exception_CO-E02_2026-08-20_CURRENT.txt

Title: Declared Service Outage Exception
Source ID: CO-E02
Owner: Harbor service policy owner
Status: CURRENT
Effective: 2026-08-20
Exception: During a declared service outage, acknowledge a standard request within 4 business days
and label the request OUTAGE-AFFECTED.
Scope: This exception applies only during that declared outage. It does not authorise a permanent change.

Company fixture 5 — service_glossary_CO-G03_2026-08-01_CURRENT.txt

Title: Harbor Service Glossary
Source ID: CO-G03
Owner: Harbor service policy owner
Status: CURRENT
Effective: 2026-08-01
Terms: CURRENT means approved for present use. BACKGROUND means explanatory and non-governing.
OUTAGE-AFFECTED means a request received during a declared service outage.

Neither corpus names a permanent-change approver, making the not-found test reproducible.

Step 4: create and inspect the active workspace

In an approved instance of AnythingLLM, Open Notebook, or an equivalent tool, create an empty workspace with the bounded purpose in its name. Add only the five included files. Wait for the interface's source-processing step to finish, then compare the visible source list with the register. Source existence and source selection can differ, so confirm which five files are actually available to the question.

Use this shared prompt:

Use only the active sources. State the current rule and cite the source ID and exact words.
Treat files labelled BACKGROUND as explanation, not authority. If current governing sources
conflict, say "conflict - ask the source owner". If no active source answers, say
"not found in the active corpus". Do not infer approval or permission.

Ask three parallel questions: What is the current timing rule? What exception is documented? Who may approve a permanent change? Check for these results:

Wording may vary, but the values, limits, labels, and citations must agree with the originals. A conflicting or invented answer fails the test.

Step 5: diagnose and repair the seeded failure

Create the matching stale file below, but never add it to the team workspace. Put only this file in an empty synthetic probe workspace and confirm its source or context list has one item. Then add it to a separate six-source test copy.

Lab seeded-failure file — NS7_protocol_LAB-P11_2024-04-10_SUPERSEDED.txt

Title: NS-7 Handling Protocol
Source ID: LAB-P11
Owner: Northstar protocol lead
Status: SUPERSEDED
Effective: 2024-04-10
Superseded by: LAB-P17 on 2026-08-15
Obsolete rule: Record NS-7 quality-control readings after 24 hours.
Instruction: Do not use for current practice.

Company seeded-failure file — request_policy_CO-P11_2024-04-10_SUPERSEDED.txt

Title: Standard Service Request Policy
Source ID: CO-P11
Owner: Harbor service policy owner
Status: SUPERSEDED
Effective: 2024-04-10
Superseded by: CO-P17 on 2026-08-15
Obsolete rule: Acknowledge a standard service request within 5 business days.
Instruction: Do not use for current operations.

In the one-source probe, ask: What timing rule does this source state? Cite the source ID and status. Expect 24 hours — LAB-P11 (SUPERSEDED) or 5 business days — CO-P11 (SUPERSEDED). The inspected one-source boundary makes this reproducible. In the six-source copy, rerun the ordinary question and record stale, current, conflict, or no answer; ranking is not deterministic. Diagnose with the citation and register, not expected wording.

Remove slot 2, confirm the test copy again lists slots 1, 3, 5, 7, and 8, refresh by the documented workflow, and rerun the unchanged question. It should cite slot 1 with current timing. Keep checking citations. Visible removal does not prove deletion from storage, indexes, logs, or backups; for real material, use the deployment owner's approved deletion path.

Step 6: make the base a team responsibility

The Northstar Protocol librarian and Harbor Service policy owner each conduct monthly and event-triggered reviews. They compare the active list with the register, resolve unknown status, remove replacements, and rerun the three questions.

Teammates receive the purpose, rule, not-found phrase, citation-check instruction, source boundary, and owner's role. Do not claim that the base "knows the answer."

7. What goes wrong

Everything useful is added

Symptom: broad questions return fragments from unrelated projects, old meeting notes, and background reading.

Fix: define supported questions first. Exclude irrelevant sources and those without stated authority.

Superseded and current versions compete

Symptom: the answer cites a real but obsolete rule, especially when filenames say only final or new.

Fix: keep one confirmed current version active. Record replacements and archive history separately.

Duplicates manufacture confidence

Symptom: several citations repeat the same passage, making one position appear independently supported.

Fix: compare IDs, titles, dates, and content. Keep one authoritative copy and its origin.

Nobody owns the next update

Symptom: the launch-day corpus looks clean, but approved replacements never reach it.

Fix: name an owner, review rhythm, status contacts, and event triggers. Register the next review date.

Internal is mistaken for permitted

Symptom: sensitive documents are included because only colleagues can see the interface.

Fix: approve the entire processing and access path, minimise the corpus, and exclude material whose model, storage, logs, backups, retention, deletion, or access boundary is unresolved.

A corpus problem becomes a prompt rewrite

Symptom: the team adds stronger instructions while the wrong version remains available or the current authority is absent.

Fix: inspect the cited original and source register first. Repair membership, status, duplicates, and missing authorities; rerun the same question before changing anything else.

8. Do it yourself: curate a team base in 60 minutes

Minutes 0–8: choose one bounded purpose and three questions. Name who a bad answer affects. Use a test workspace and synthetic, public, or approved material.

Minutes 8–18: write the rule: authorities, background, date/version requirements, prohibitions, conflict response, owner, review rhythm, and replacement triggers.

Minutes 18–30: inventory six to twelve candidate sources in the corpus boundary record. Record stable ID, title, owner, date/version, status, replacement relationship, sensitivity decision, workspace decision, status confirmer and confirmation date, and next review date. Include at least one synthetic superseded candidate and one duplicate candidate so that exclusion is visible.

Minutes 30–40: add only admitted sources to an empty workspace. After processing, reconcile its active list with the register.

Minutes 40–49: ask one current, one exception/conflict, and one absent question. Require source ID, exact words, and the not-found phrase. Open every citation.

Minutes 49–55: in a separate one-source probe workspace, add only the synthetic superseded candidate, inspect that boundary, and ask what rule that source states. Then use a separate test copy of the active base to add and remove the stale candidate. Record the mixed-corpus result, restore the five-source boundary, refresh it, and confirm the current answer returns.

Minutes 55–60: assign the owner and next review. Have a teammate reproduce the active list and open citations. Remove temporary test workspaces through the approved process.

9. Exit check

Deliver exactly one artifact: one working knowledge base, including its single corpus boundary record with the written inclusion/exclusion rule.

It passes when the boundary record contains the rule, register, three results, owner, and next review; every active source has owner, date/version, confirmed status, sensitivity decision, and next review; disallowed candidates are excluded; the tests produce a cited current answer, handled exception/conflict, and explicit not-found result; original sources support retained claims; and one teammate can reproduce the boundary. Probe workspaces are temporary practice, not exit artifacts; delete them through the approved process.

10. Rule to remember

Garbage corpus, confident garbage.

11. Further reading & tools

• Taught: T04-L01 · Ask questions about your own files - provides the citation-checking and upload-boundary skills used here.
• Taught: AnythingLLM - practises an inspectable workspace, supported and absent questions, and processing-boundary recording.
• Taught: Open Notebook - separates sources, selected context, chat drafts, and reviewed notes.
• Catalogued: AnythingLLM: RAG in AnythingLLM (opens in a new tab) - official guidance on workspace retrieval and document scope.
• Catalogued: AnythingLLM security and access documentation (opens in a new tab) - primary guidance for current access modes and roles.
• Catalogued: AnythingLLM privacy and data handling documentation (opens in a new tab) - primary guidance for current document handling and deletion behaviour.
• Catalogued: Open Notebook repository (opens in a new tab) - primary project overview and documentation entry point.
• Catalogued: Open Notebook: Notebooks, Sources, and Notes (opens in a new tab) - primary guidance for organising notebooks, sources, and notes.
• Catalogued: Tools index - compare current knowledge-base tools only after defining the corpus purpose, approval boundary, and ownership.