Knowledge as code: applying docs as code to company knowledge
Knowledge as code applies docs as code to company knowledge: an owner, a review and a version for every change, so people and AI agents share one source.
Knowledge as code means keeping company knowledge the way software teams keep code. Every article has an owner, every change is reviewed before it goes live, every version is kept, and automated checks show what has gone stale. It extends docs as code, a settled practice for technical documentation, to the procedures, policies and support fixes that the rest of the company uses. People and AI agents then read the same governed source.
If you run a service desk, a data platform or an AI programme, your code is already managed this way. Your procedures, runbooks and policies usually are not. This article maps each software practice onto a knowledge base and shows where the comparison stops working.
What docs as code is
Write the Docs, the community of documentation practitioners, defines docs as code as writing documentation "with the same tools as code": issue trackers, version control, plain text markup, code reviews and automated tests. In 2017, the UK Government Digital Service (GDS) explained why it uses a docs as code approach: every change is tracked, any earlier version can be restored, anyone can propose a change for review, and the whole team shares ownership of the content.
The UK Home Office's engineering standards, updated in April 2025, ask teams to use docs as code wherever possible. They give one reason that matters beyond software: a team can block a new feature from merging until its documentation exists, so people document the work while they still remember it.
These sources cover technical documentation for developers. GDS also named two problems it had not solved in 2017: managing high volumes of documentation, and retiring old content. A company knowledge base has both.
How software practices map onto a knowledge base
Each practice below exists in software because it prevents a specific failure. The same failure happens in a knowledge base.
| Software practice | Knowledge base equivalent | What it prevents |
|---|---|---|
| One owner per file or module | One accountable owner per article, handed over when they leave | Articles that nobody maintains |
| Review before merge | Approval before an article or an update is published | Unchecked changes reaching readers |
| Version history | Every version kept, with who changed what, and a restore option | Losing what was true, and when |
| Automated tests | Checks for overdue reviews, broken links and missing owners | Silent decay |
| Deprecation | Archiving that removes an article from search without deleting it | People following a retired procedure |
| Changelog | A short note to readers on what changed and why | Readers who work from memory of the old version |
| Typed, machine-readable structure | Article types, templates and metadata that tools can read | AI agents that cannot tell a draft from an approved answer |
Owners. The guidance written by the project editor of ISO/IEC 20000-1, the service management standard, says that knowledge roles should include identifying the sources of knowledge and an owner for each (April 2025). On GOV.UK, an organisation must usually be tagged to a page before it can change it.
Review and versions. Regulated industries have long worked this way. EU rules for medicines manufacturing require instructions to be approved, signed and dated by authorised people, with a defined effective date (EU Good Manufacturing Practice, Chapter 4, 2011). The website of the UK National Health Service (NHS) requires two members of its clinical team to approve new content and major changes. A version number can also say what kind of change happened. Semantic Versioning raises the major number for a change that breaks what came before. For a procedure, a major change is a step that changes what people do, and it deserves a different signal from a fixed typo.
Tests. A check can catch an expired review date, a dead link or an article without an owner. The Knowledge-Centered Success (KCS) method, maintained by the Consortium for Service Innovation, uses a six-question content standard checklist for this kind of review: is the article unique, complete, clear, well titled, are its links valid, is its metadata correct.
Deprecation and changelogs. GOV.UK separates two ways to retire a page. A withdrawn page stays at its address with a banner saying it is no longer current, and it leaves internal search. An unpublished page is removed and can redirect to current content. Keep a Changelog, a widely used convention for software, says that "changelogs are for humans, not machines", and gives "Deprecated" its own heading.
Structure that tools can read. Version 1.3 of the Darwin Information Typing Architecture (DITA), the documentation standard approved by the standards body OASIS in 2015, classifies its core topics as a concept, a task or a reference. A task has set parts, in a fixed order: prerequisites, context, steps, result. A knowledge base gets the same benefit from templates and from metadata (owner, review date, status), because software can read them. That now includes AI agents, which often read a knowledge base through the Model Context Protocol (MCP). Our guide to AI knowledge management explains how MCP works. The protocol is itself governed like code: changes go through written enhancement proposals, and versions are dated.
Where the comparison stops working
The mapping is useful, but knowledge is not code. Three differences change how you apply it.
Knowledge has no compiler
Broken code usually fails a build or a test. A wrong procedure fails silently: someone reads it and follows it. Automated checks can test the form of an article, never its truth. A study of Stack Overflow found that 58.4% of obsolete answers were probably obsolete when they were posted, and only 20.5% of obsolete answers were ever updated (IEEE Transactions on Software Engineering, 2019). KCS replaces the missing compiler with its readers: reuse is review. The person who uses an article checks it at that moment, and flags it or fixes it if it is wrong.
The reader is a person, and the author rarely uses Git
Code has one strict reader: the compiler. A procedure has many readers in a hurry, and now AI agents too. The authors are payroll specialists, field technicians and quality managers. They will not open pull requests, and they should not have to. What transfers is the practice: owners, review, versions, checks. The tooling stays with the engineers. A company also cannot run two live versions of one procedure the way a team runs two branches, so a draft must stay invisible until it is approved.
Review is a judgement
Code review can lean on tests. Knowledge review is an expert deciding whether a statement is still right. How that review feels decides whether people keep writing. A study of knowledge repositories found that transparent, development-oriented review processes encourage contribution (Journal of Management Information Systems, 2009). KCS goes further and warns against the one-owner rule itself: individual ownership of articles is "death to successful knowledge management practices", because people stop editing articles that "belong" to someone else. The two positions fit together if the owner is accountable for accuracy while anyone can flag or fix an article.
What the trusted sources leave open
No trusted source we read answers three questions that decide how you run a knowledge base this way.
How often to review. No trusted source gives evidence for an interval. Our guide to knowledge base maintenance compares what KCS, the NHS, the US Environmental Protection Agency and GOV.UK ask for.
Who owns knowledge when people change, and what an AI answer may show. Owners leave and teams reorganise. The sources ask for an owner and say little about the hand-over. For AI, joint guidance from the US, UK, Australian and New Zealand security agencies says that the output of an AI system should be classified at the same level as its input data (May 2025). None of the sources says what to do when one answer combines documents with different access rights. MCP makes authorisation optional, and its specification states that it "cannot enforce these security principles at the protocol level". Each implementation has to apply the reader's permissions itself.
How to measure accuracy. The KCS guide is direct: "goals placed on activities will corrupt the knowledge base". Ask for 10 articles a month and you get 10 articles a month. It recommends measuring outcomes. Neither KCS nor any other source we read defines a measure of whether a knowledge base is accurate.
So the platform you choose must make these decisions easy to apply and easy to change, because the sources will not make them for you.
What a knowledge platform must offer
As requirements, the mapping gives a short list for any platform that holds knowledge for people and AI agents:
- One accountable owner per article, and a way to hand articles over when someone leaves.
- Approval before publication, for new articles and for updates.
- Every version kept, with the changes visible and a restore option.
- Review dates that create a task for the owner, and a list of what is overdue.
- Archiving that removes an article from search without deleting it.
- Templates and metadata that people and software can both read.
- One access path for AI agents that applies each reader's own permissions, and agent edits that go through the same review as human ones.
How we apply it in Elium
Elium is a European knowledge management platform, and we built it around this list. Each article has one owner, and an administrator can transfer a departing person's articles to successors, space by space. A space can make approval mandatory for new articles and for updates. Elium keeps every version of an article, shows what changed, and lets contributors restore an older one. A verification date puts the article in its owner's task list when the review is due, and archived articles leave search without being deleted.
For AI agents, Elium supports MCP, so AI assistants such as ChatGPT and Claude connect to the same source people read. Access runs with the permissions of the person who signed in, so an assistant only reaches what that person is allowed to see. When an AI assistant reads an article, it also receives its owner, review date, approval status and archive state, so it can tell the reader how current its source is. When an AI assistant writes, its changes are saved as drafts by default and go through your usual publication or approval process.
The review interval and the accuracy measure stay your decision. At the Département de l'Orne, the IT team gave every procedure an expiry date and an annual review, so no procedure stays active without being verified.
Where to go next
- Keeping it accurate. How to keep a knowledge base accurate goes deeper on owners, review and leavers.
- The AI side. Headless knowledge management separates the governed source from the screens and agents that read it, and WYKIWYG: what you know is what you get explains why an assistant can only be as right as its documents.
- Compare tools. Our knowledge management tools comparison sets out the options.
- Use a template. Plan reviews with the content review schedule template.
- Do it in Elium. Start with Elium for IT support or Elium for AI and data teams.
Knowledge as code, in short
Knowledge as code is the practice of managing company knowledge the way software teams manage code: one accountable owner per article, review before publication, every version kept, and automated checks for what has gone stale. It extends docs as code from technical documentation to procedures, policies and support knowledge, so that people and AI agents read one governed source.
Docs as code means writing documentation with the same tools as code: version control, plain text markup, code review and automated tests. Knowledge as code keeps the practices and drops the tooling, because the authors of company knowledge are business experts who do not work in Git. The owner, the review, the versions and the checks move into the knowledge platform.
Most connect through an API or the Model Context Protocol (MCP). MCP does not enforce permissions by itself, so the knowledge platform must apply each reader's access rights and should pass status information such as the owner and the review date with the content.
Sources
- Write the Docs, Docs as Code, community guide (undated).
- Jen Lambourne, Government Digital Service, Why we use a "docs as code" approach for technical documentation, 25 August 2017.
- UK Home Office, Engineering Guidance and Standards, Docs as code, updated 25 April 2025.
- Lynda Cooper, ISO/IEC JTC 1/SC 40, ISO/IEC 20000-1: implementing and auditing the knowledge requirement, April 2025.
- Government Digital Service, GOV.UK content and publishing guidance: Manage existing GOV.UK content and Retire outdated content.
- NHS website, Content policy, last reviewed 14 October 2022.
- European Commission, EudraLex Volume 4, Chapter 4: Documentation, in operation since 30 June 2011.
- US Environmental Protection Agency, Guidance for Preparing Standard Operating Procedures (EPA QA/G-6), April 2007.
- OASIS, DITA Version 1.3: concept, task and reference topics, approved 17 December 2015.
- Semantic Versioning 2.0.0 and Keep a Changelog 1.1.0, open conventions.
- Consortium for Service Innovation, Knowledge-Centered Success Practices Guide (2027 edition, released April 2026): techniques 2.1, 2.2, 5.3, 5.4 and 7.1.
- H. Zhang, S. Wang, T.-H. Chen, Y. Zou and A. E. Hassan, An empirical study of obsolete answers on Stack Overflow, IEEE Transactions on Software Engineering, 2019.
- A. Durcikova and P. H. Gray, How knowledge validation processes affect knowledge contribution, Journal of Management Information Systems 25(4), 2009.
- NSA, CISA, FBI, ASD's ACSC, NCSC-NZ and NCSC-UK, AI data security: best practices for securing data used to train and operate AI systems, 22 May 2025.
- Model Context Protocol, Specification, version 2026-07-28, its authorization section and governance.
