Christophe MontagneInterim CTO · Advisory

Building It/2 min read

02One system, two sides

A knowledge base, answering software, and the contract between them that defines trusted data.

Any system that answers questions from company knowledge, whether manuals, financial results, sales trends or inventory, is two systems that must work as one (Figure 1).

Knowledge base raw data in, trusted data out Documents Systems of record Spreadsheets and notes Trusted data Owner: CIO changes when knowledge changes Contract every item carries Source Version or date Applies to Status Known gaps Who may see it Answering software question in, response out A user's question one of three responses Answer, with its source Pointer to the source "I don't know": ask this expert Owner: CTO seconds per question
Figure 1. The two sides and the contract

The knowledge base turns raw data into trusted data. Raw data is what the company has: documents of every age and format, figures in systems of record, spreadsheets, notes. Trusted data is data whose status is known, recorded and checked. It need not be complete or final: a provisional figure, marked as provisional, is trusted. Depending on the source, the knowledge base indexes documents, extracts tables from reports, or queries a system of record live. It is a set of prepared sources, not necessarily one store.

The answering software receives a question, finds what it needs, checks that the person asking may see it, and responds within seconds.

What connects them is a contract, and the contract defines trusted data. Everything that crosses it states where it came from, which version or date it reflects, what it applies to, its status, its known gaps, and who may see it. The answering side relies on these facts and nothing else. As long as the contract holds, either side can change without breaking the other: a better scan reader on one side, a new model on the other.

Knowledge always has holes: a missing quarter, stock that was never recounted, a value documented for one engine model but not the next. Some are defects the knowledge base can repair. Others are genuine absence, and filling them during preparation would only make invented data look trusted. So the knowledge base repairs what it can, fills what it can from real sources such as experts, and records the rest as known gaps. The answering side respects those gaps and handles the ones nobody has found yet: it says so, points to the source, or names someone who knows (Figure 2).

A hole in the data A defect we can fix? yes no Repair it Known elsewhere? an expert, another source yes no Fill it, with its source Trusted data Record a known gap Answering side says so, points to the source, or names an expert, also for gaps nobody has found yet Never invent no interpolating, no nearest match
Figure 2. How holes in the data are handled

The two sides differ in rhythm, skills and ownership. The knowledge itself belongs to the business: each source has an owner, such as a maintenance expert, a controller or a department head, who decides what it means, what is validated and who may see it. The systems that hold and serve it belong to technology. The knowledge base will outlive the first use case and falls under the CIO; the answering side is where the path to production is won or lost, which makes it the CTO's first concern. A demo blends all of this into one pipeline. A production system keeps it apart and connects it on purpose.

The words in the contract, such as "revenue," "applies to" or "provisional," belong to the business. They must be defined with the people who use them, not invented by engineers. Software designers will recognise the idea.

The two sides are built together: thin at first, but end to end and measured from the start (chapter 10).