Case study · Knowledge base · Product quality
In short: a large platform's knowledge was spread across code, tickets, wiki pages and people, and the three did not agree. We built a knowledge base that captures what the product does, what the business intended, and where the two diverge. Every ambiguity found was resolved. Product quality went up, because hidden defects were found before customers found them. Development speed tripled, because engineers stopped waiting on the business for answers. And the business started building better products, because the base flags problems in requirements before any work starts.
The platform had been built over years by changing teams. Its behaviour was documented in places: a wiki that nobody trusted, tickets that described what was asked for rather than what was built, and the memory of a few long-serving people. New engineers learned by reading code. Business analysts learned by asking engineers. AI tools, when the organisation began using them, learned nothing reliable at all, because there was nothing reliable to learn from.
The cost was not the missing documentation; it was the gap it hid. Every requirement carried questions that took days to answer. Every change risked breaking a rule nobody had written down. And some of what the product did was simply wrong, had been wrong for years, and nobody knew, because nothing ever compared what the business intended with what the code did.
Product owners' time was the scarcest resource, so the base could not depend on them confirming hundreds of rules by hand. Findings had to be precise, because a false defect report to a product owner costs credibility once and never gets it back. And nothing about the base could rely on people remembering to update it, because that is how the wiki had died.
We captured the product's knowledge from every source it lived in: the code and its tests, tickets, wiki pages, test cases and permission matrices, and the people who knew it. Each rule was recorded with its identifier, its status and its source, organised by business capability rather than by technical component, so that a product owner and an engineer read the same page.
The decisive design choice was to keep two kinds of evidence apart. The code is the authority on what the product does; only people are the authority on what it should do. Where the two agreed, the rule was confirmed. Where the business could not say, a question was raised with an owner. And where the business was certain and the code disagreed, the base raised a finding, with its evidence, for a person to decide. Nobody edits the base directly: every correction is checked against the product first, which is why it cannot drift the way the wiki did.
The base now sits under everything downstream. Requirements are checked against existing rules before grooming ends. Engineers and AI tools answer their own questions from it. Testers derive test cases from it. Every change to the product re-checks the base, so it stays current without anyone remembering to update it.
| Measure | Before | After |
|---|---|---|
| Ambiguities in reviewed capabilities | unknown, discovered in production | identified and resolved, with an owner for each |
| Hidden intent-vs-behaviour divergences | none known | 10 found in the first 30 capabilities, including confirmed shipped defects |
| Time for an engineer to get a business answer | days, by meeting | minutes, from the base |
| Development speed on reviewed capabilities | baseline | up to 3× |
| Requirement issues found | at review or in production | at grooming, before work starts |
| Documentation currency | decaying wiki | re-checked on every change |
Note that the speed figure is the client's comparison on capabilities covered by the base against comparable work before it, and reflects mostly the removal of waiting time; it is not a controlled measurement. The divergence count is exact. The first of the shipped defects was a validation path with no duplicate guard, found by the base before any human reviewer had looked at the capability.
The larger effect is a change in how the organisation builds. Requirements that contradict existing rules are caught before an engineer sees them. The business spends its time only where intent is genuinely unconfirmed, and gets defect findings back for it. The aim is First Time Right: work done once, correctly, because everyone, including the AI, is working from the same truth. The knowledge base became an integral part of building the product and of managing it for the long term.
Services: The knowledge base · AI-native engineering
Case studies: AI-native engineering for a software organisation · Standards enforced by the build · All case studies
Book a free 30-minute call. We will look at where your knowledge lives today and show you what a reconciled source of truth would surface.
