The Knowledge Base Build Standard

1. What this standard covers

Any business that will later ask an assistant to speak from its own material, and whose material is currently in more than one place with nobody named against it. A trades business with a price list, a set of codes and a folder of supplier terms. A practice with legislation, its own procedures and client files. A broker network with a lender panel, a credit policy and an operations manual across many offices.

It covers the phase the Knowledge Graph standard opens with in one line, “register the source”, and that for most businesses is the longest phase by far. It ends where that standard begins: a register entry with an id, an edition, a checksum and a locator scheme, which the graph takes as an instrument.

What it is not. It is not a chat assistant over the drive. It is not a migration to a new document system. The drive stays where it is; the register points at it. And it is not the graph: nothing here holds a fact, only where a fact can be found.

How big it is. Honestly, this is the foundational project, and it is measured in weeks for a network rather than an afternoon. Not because any step is hard, but because finding every source and getting a person to put their name to it is a conversation per source. The checks in section 4 can each be proved in an hour on a stub. The inventory cannot, and the pass test says so.

2. The kinds of source

Six kinds, a closed list. The kind decides who may read it and how long it is kept. The folder it was found in decides nothing.

The last row is the one that goes wrong. A client interview saved in the policy folder gets embedded with the policy, and the shared search then returns a client’s circumstances to whoever asks a policy question. Kind is set on arrival and the index is scoped by it.

3. The objects, and what is in them

Six objects. The register entry does the work. The watch run and the gap are the two most builds leave out, because a search over a drive appears to function without either.

RegisterEntry                     # one per source, the product
  - id, title, kind (from the closed list)
  - owner (a person, never a team)
  - location { system, path }     # the drive stays where it is
  - edition (where the issuer publishes one)
  - checksum, retrieved_at
  - status (current | superseded | duplicate_of | missing)
  - duplicate_of (entry id, nullable)
  - access_list[], expires_on    # required for customer_material
  - superseded_checksums[]       # earlier editions stay recoverable

Passage
  - id, register_id, locator    # page and section, offsets, or seconds
  - text
  - scope (shared | restricted)

SearchResult
  - query, asked_on
  - passages[] { passage_id, register_id, locator }
  - composed: null               # always. Answering is another standard

Gap
  - id, expected (what should exist), owner, due
  - closed_by_entry (nullable)

WatchRun
  - id, ran_at
  - checked[] { register_id, old_checksum, new_checksum, changed }
  - notified[] { owner, register_id }

GraphHandover
  - register_id, edition, checksum, locator_scheme
  - promoted_by, promoted_on

A Passage with a null register_id is the defect this standard exists to make unrepresentable: something searchable that nobody owns. A SearchResult with composed text is the second defect, and it should not be writable.

4. The checks, in order

The order is the claim. Chunk the drive first and you have a search nobody owns; register first and the search inherits an owner, a checksum and a scope from every entry it is built on.

1. Every source is on the register before anything is indexed. A file is registered with a title, a location and an owner before a passage from it is chunked or embedded. Indexing an unregistered file fails.
2. Duplicates resolve to one canonical copy, and only the canonical is indexed. Two copies of the same source are one register entry with the others marked duplicate_of. The index holds the canonical copy once.
3. Every source has a named owner, and a team is not an owner. The owner is the person who is asked when the source moves or goes missing. "Operations" cannot be asked anything.
4. Retrieved date, checksum and edition are recorded when the source arrives. A source without a checksum cannot be watched. One without an edition, where the issuer publishes one, cannot be handed to the graph.
5. Customer material is registered as such, restricted, and kept out of the shared index. Client files, interviews and emails are inventoried with kind customer_material and an access list. They are never chunked into the search everyone uses.
6. Every indexed passage names its source and a locator that can be opened. Page and section, offsets in a stable file version, or seconds on a recording. "Chunk 47" is not a locator.
7. Search returns passages with their source and locator, and composes nothing. A query returns what was found and where. It does not return a paragraph the model wrote. Answering is the Cited Answer standard, over the graph.
8. A source that should exist and cannot be found is a gap with an owner and a date. The current edition of an instrument the business relies on, not on the drive, is not a blank row. It is a task for a person.
9. Every source on the drive is re-fetched on a schedule, and a changed checksum reaches its owner. The watch runs whether or not anything changed. When a checksum moves, the register records the new one, marks the old copy superseded, and the owner is told the same run. A source held only by the issuer gets a recheck task to its owner on the same schedule, and the confirmation is recorded.
10. Retention and access follow the kind of source. An issued instrument is kept with every edition. Customer material carries an expiry and an access list. The kind decides, not the folder it was found in.
11. A source reaches the graph only from the register, carrying its id, edition, checksum and locator scheme. The Knowledge Graph standard registers a source as an instrument. That instrument is this register entry, not a fresh upload. A graph source with no register id has skipped this standard.
12. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
13. The pass test passes. On the business's real drive: every source registered with a person, one duplicate found and resolved, one client file quarantined, a real edition change caught by the watch within a cycle, and a search that returns locators the owner can open.

5. Search finds, and never answers

This is the boundary, and it is the one every product will try to talk you across. A search over the knowledge base returns passages with a register id and a locator a person can open. It does not return a paragraph the model wrote from those passages.

The reason is not caution. A composed answer from a pile cannot say which edition it used, cannot be found again when that edition is replaced, and cannot decline. Those three properties are what the Cited Answer standard provides over the graph, and the graph exists so that they can be provided. A knowledge base that answers has skipped both, and the answer it gives will be the one that was right last year.

What search is for, then: a person finding the passage to read, a person finding the duplicate to resolve, and the graph’s extractor finding candidate passages to propose. All three want a locator. None of them wants a paragraph.

6. Building it on Microsoft 365 or Workspace

Nothing in this standard needs a product the business does not already pay for. Both tenants answer every role, and the drive does not move. One limit applies to both: the scheduled watch can only compare what sits on the drive. A source the issuer publishes only on its own site is watched by a recheck task to the owner, so for that source the catch is a person, not software.

The register is a list, not a database, on purpose. A list is what the people who own the sources already open, and an owner who has to log into something new to answer for a source will not. The checks do not care which of the two you are on, because they are asserted through ports rather than against a vendor; see the standards on Microsoft 365 for the general shape.

7. The handover to the graph

The Knowledge Graph standard’s second check registers a source as an instrument with a title, an issuer, an edition, a jurisdiction, effective dates and a checksum. The title, edition, checksum and retrieved date are on the register entry already. The person promoting it adds the issuer, the jurisdiction and the effective dates, and the graph refuses the promotion without them. The handover is a promotion of the entry, by a person, carrying its id. The graph never takes a fresh upload, because a fresh upload has no owner and no history, and the first replaced edition would have nowhere to go.

Read upward, the stack is this standard, then the graph, then Cited Answer, then the Advice File. The order and the reasons are in combining the build standards.

8. What stays with a person

• ✓Owning a source, and answering for it when it moves or goes missing.
• ✓Deciding which of two copies is the canonical one.
• ✓Closing a gap for a source that cannot be found, or deciding the business does not need it.
• ✓Who may read customer material, and for how long it is kept.
• ✓Promoting a register entry to the graph.

The build may propose all five. It may not occupy owner or promoted_by, and it may not set duplicate_of without a person.

9. Provider: what to stub, and what not to hand-roll

One step not to hand-roll, and it is a schedule and a table rather than software. The rest an agent builds on the tenant in an afternoon once the sources are found.

provider:
  stub:       local.mock_drive
  production: none                       # no hosted step; runs on your own systems

do not hand-roll
  - the watch. Every source on the drive re-fetched on a schedule, its
    checksum compared, the register updated, the owner told in the same
    run. A source held only by the issuer gets a recheck task to the
    owner on the same schedule. Skip it and the register is a
    photograph of the drive on the day it was taken.

may be bought
  - the search over the libraries the register names
  - the chunker, as long as every passage carries a register id

the long part
  - finding the sources and getting a person to own each one. Weeks for
    a network. No product shortens it.

There is no hosted product for this standard. The production check runs over the business's real drive and mailbox with its real owners. A vendor selling a searchable knowledge base is selling the index, and is usually silent about who owns each source and what happens when one is replaced. Ask them that first.

10. Conformance checklist

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. Every source is on the register before anything is indexed. A file is registered with a title, a location and an owner before a passage from it is chunked or embedded. Indexing an unregistered file fails.
• ✓2. Duplicates resolve to one canonical copy, and only the canonical is indexed. Two copies of the same source are one register entry with the others marked duplicate_of. The index holds the canonical copy once.
• ✓3. Every source has a named owner, and a team is not an owner. The owner is the person who is asked when the source moves or goes missing. "Operations" cannot be asked anything.
• ✓4. Retrieved date, checksum and edition are recorded when the source arrives. A source without a checksum cannot be watched. One without an edition, where the issuer publishes one, cannot be handed to the graph.
• ✓5. Customer material is registered as such, restricted, and kept out of the shared index. Client files, interviews and emails are inventoried with kind customer_material and an access list. They are never chunked into the search everyone uses.
• ✓6. Every indexed passage names its source and a locator that can be opened. Page and section, offsets in a stable file version, or seconds on a recording. "Chunk 47" is not a locator.
• ✓7. Search returns passages with their source and locator, and composes nothing. A query returns what was found and where. It does not return a paragraph the model wrote. Answering is the Cited Answer standard, over the graph.
• ✓8. A source that should exist and cannot be found is a gap with an owner and a date. The current edition of an instrument the business relies on, not on the drive, is not a blank row. It is a task for a person.
• ✓9. Every source on the drive is re-fetched on a schedule, and a changed checksum reaches its owner. The watch runs whether or not anything changed. When a checksum moves, the register records the new one, marks the old copy superseded, and the owner is told the same run. A source held only by the issuer gets a recheck task to its owner on the same schedule, and the confirmation is recorded.
• ✓10. Retention and access follow the kind of source. An issued instrument is kept with every edition. Customer material carries an expiry and an access list. The kind decides, not the folder it was found in.
• ✓11. A source reaches the graph only from the register, carrying its id, edition, checksum and locator scheme. The Knowledge Graph standard registers a source as an instrument. That instrument is this register entry, not a fresh upload. A graph source with no register id has skipped this standard.
• ✓12. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓13. The pass test passes. On the business's real drive: every source registered with a person, one duplicate found and resolved, one client file quarantined, a real edition change caught by the watch within a cycle, and a search that returns locators the owner can open.