A procedure exists in a shared folder, but a team still uses an older copy. An assistant retrieves that copy and produces an answer consistent with obsolete instructions. Model quality cannot settle which version governs. The organisation must identify its reference and control its distribution.
A versioned knowledge base connects content with approval and use. Markdown files can provide a simple medium. Their value depends on the process for reviewing, publishing and withdrawing information.
Give each page an identity and owner
One file covers a defined subject, such as a procedure or calculation rule. Its title names the subject and its sections explain the relevant steps. Links connect dependencies without reproducing the same material everywhere.
Metadata records responsibility and applicability. A stable identifier survives a title change. Source references support verification. Effective and review dates distinguish current instructions from history.
| Field | Example for a procedure |
|---|---|
| Identifier | credit-note-processing |
| Owner | Role responsible for approving the procedure |
| Source | Internal instruction and approved version |
| State | Proposed, approved or superseded |
| Dates | Effective date and next review |
| Access | Groups authorised to read it |
| Relationship | Identifier of the previous procedure |
Markdown can be read with a text editor and compared line by line. It does not create permissions or verify that the procedure is correct. Hosting and publication controls must implement those decisions.
Make approval visible
Git can preserve versions and changes. A proposed edit lets a reviewer inspect the differences before publication. The discussion supplies context that a modification date alone cannot provide.
Signed commits help verify provenance according to recognised keys and identities. They do not prove that content is true or that the signer was authorised to approve it. Repository rules distinguish authorship from review and publication.
The Git signing documentation explains the mechanisms. blame identifies the last known change to a line; it does not reconstruct the full origin of an idea. History retention and branch protection complete the record.
For example, a revised credit-note procedure arrives as a proposal. Its owner examines the consequences and exceptions. The approved version receives an effective date and identifies the procedure it replaces. A reader can understand why the versions differ.
Connect publication with retrieval
An assistant must retrieve relevant passages from versions the user is allowed to read. The search index is derived from the source collection. It retains document identifiers and version information alongside the metadata needed to enforce access.
Preparation affects search quality. Headings and tables guide chunking, and a properly parsed PDF can preserve this structure too. Text files simplify some operations without making other formats unusable.
An answer should let the reader open both the cited passage and its complete document. A filename alone offers less evidence than a passage linked to a specific version.
Import tests cover permissions and currency. A restricted page must not appear for an unauthorised user. A replaced procedure must not remain current instruction. Reference questions can check both properties whenever the index changes.
Correct the cause and propagate the update
A wrong answer may come from an incorrect source, the wrong retrieved passage or a generation error. Changing the reference document in every case could damage valid content.
Where the source is wrong, its owner proposes and approves the correction. Ingestion updates the index and removes the superseded version from current retrieval. Caches and other applications must follow the same publication decision.
A test then repeats the question that revealed the problem. Recording the source and index versions distinguishes a written correction from one actually available to users.
History helps explain past decisions, but its access and retention need rules. Personal data should not remain indefinitely in every version simply because Git can retain it. Correction and deletion duties also concern derivative copies.
Start with a collection the team can maintain
An initial scope can cover procedures several people need and whose conflicting versions cause errors. The team assigns an owner and review schedule, then observes questions and corrections during use.
Evaluation asks whether people find the right version and understand its status. For an assistant, it also checks passage relevance and citation quality. Those results determine whether to expand the collection.
Approved knowledge differs from observations an agent retains between sessions. A model’s proposed note does not automatically have the authority of an approved procedure. The article on agent memory examines that lifecycle.
A durable knowledge base preserves the relationship between information, its owner and its uses. An open format makes handover easier; approval and propagated updates make it a usable reference.