Maintaining the Wordhouse: keeping it true as it grows

Every knowledge base starts with good intentions. Someone spends a fortnight gathering the best answers, it works well for a quarter, and then it starts to drift. New contracts get signed on different terms. The award rate changes. A release retires a feature. Nobody updates the library, people stop trusting it, and the team goes back to searching old email.

Maintenance is where most knowledge bases quietly die. For a Wordhouse, it is also the part that decides whether every later answer is right. Wordhouse

The same pattern, run in reverse

Building and updating the Wordhouse uses the same patterns as using it, pointed the other way.

1. Structure the incoming document the same way as for a review: confirmed structure, coverage ledger, second reader. Structure first
2. Map every section to a topic. The model proposes which topic each section belongs to, using the index. A person confirms the map.
3. Propose updates, not rewrites. For each topic, the job proposes what to add: a new variant, a changed position, a new fallback. It returns those as changes to the topic file, not a new file.
4. Weave them in with code. Changes are applied deterministically, and the verbatim source wording is copied by code, never retyped. Never retype

The result is a Wordhouse a team can keep current without a developer. The files stay readable, and every addition shows where it came from.

Account for every section

The check that matters most is the same as anywhere else: every section of every source either lands in the Wordhouse or is excluded on purpose, with a reason. The register only passes when every item is accounted for exactly once.

It is worth being precise about what that check covers, because the benchmark found a gap in mine. My library skill checked coverage section by section, and it passed while 14 substantive clauses inside those sections had no position at all. The sections were mapped; some of their clauses weren’t. A targeted second run fixed it, and the check now works at clause level. BigDocs: the benchmark A test that only checks the level above the one that matters will pass with a smile.

Who owns it

The Wordhouse belongs to the people whose positions it holds. Legal owns the contract topics, HR owns notice and leave, the bid team owns the tender answers, support owns the product capabilities. The maintenance skill does the reading and the weaving; the owner confirms the map and approves the changes. That is a few minutes per document rather than a project.

Across teams

• Legal and commercial: each signed contract feeds its negotiated positions back in.
• HR: a new award or enterprise agreement updates the relevant topics, and every affected policy can be found from the topic.
• Sales and marketing: each submitted tender adds its final answers, so the next one starts from the best version.
• Support: each release note updates the capability topics, and the help articles that depend on them are listed for review.

What your team can do on Monday

Pick the library you already have, however informal. Choose one recent document that should have updated it and check whether it did. If it didn’t, you have found your maintenance gap, and the fix is a routine, not a rebuild.