The contract was specific about this. The supplier running the first-line desk would use the organisation's knowledge base to record the details of incidents and problems already resolved, that base would be managed and maintained by the desk, and it would stay available to every resolver group across the IT organisation. One store, curated by the people closest to the work, readable by everyone standing behind them. It is a good clause. It is the clause you would write today.
None of it was what the review found. The incumbent kept its own knowledge base and recorded resolutions there. The organisation had started a second one and handed it to a different supplier's team, a crew contracted separately to walk the floors and head off tickets before they were logged. That team maintained the organisation's base and updated it regularly. It was open to every agent on the desk, to read and to add to. The desk's agents were not using it often enough. The incumbent's own base, the one the desk actually worked from, was recorded as infrequently updated and out of date.
Two bases, then. One current and unread, one read and stale.
The challenge
The tempting reading is that a supplier was being lazy and needed to be told. The review says something closer to that, recommending the incumbent be encouraged to use and update the organisation's base. But look at where each store sat commercially, because that is what actually decided the outcome.
Three supplier relationships touched the resolution of a single incident. The incumbent held first line and kept the base its own agents were trained against. A second supplier held the proactive floor-walking service and kept the base the contract had promised. Behind both, unresolved calls escalated either to internal second-line queues or, where appropriate, to a third-party service provider. Each party curated the record it controlled, and each one was right to, because the record it controlled was the one it would be measured on.
Nothing above that reconciled them. The whole contracted governance model was a nine-activity matrix across four roles, lifted from a single section of the contract's technical conditions: service level monitoring, service level achievement, changes to service levels, staff planning, service delivery, break-fix requests, break-fix management, ad hoc reports. Four of the nine rows leave at least one role's cell blank, and two of the rows are the same activity written twice. Knowledge appears nowhere in it. The reviewers recommended standing up a knowledge owner and an audit team, which is the plainest available statement that neither existed. So the divergence between the contracted base and the operated base was not an unresolved argument. It was an argument nobody had standing to hold.
The cost of that shows up in the interview record, in the users' own words. The same incident was escalated over and over to second and third line, because a resolution reached once was never written where the next agent would meet it. Misrouted tickets were passed around between teams two or three times a month, per team. Knowledge concentrated instead of spreading: only two agents handled incidents for the organisation's own in-house applications, so a single person's leave produced a backlog that grew until they came back. On the technology side the complaint was blunter still. Searching the text of incident tickets was difficult, different departments ran different tools, and there was no way to bring the information together. Even the resolutions that had been written down were not reliably reachable.
There is a number attached to what that did to competence. The organisation ran its own quizzes on its applications, four sittings, with the questions repeated and the repetition announced in advance. Average scores went 32.3%, then 28.9%, then 46.3%, then 52.9%. Nearly six months to produce a minor increase, on a test where difficulty had been deliberately removed as a variable. The review reads that as motivation and supplier management, and it is partly both. It is also what a knowledge estate with two competing stores and no owner does to the people working inside it. Nobody could say which store an agent was meant to have learned from.
The approach
The recommendation on the table was two jobs presented as one. Connect the organisation's base to the ticket tool so an agent has a single window rather than two, and get the incumbent using it. The first is a build with a known shape. The second is a decision, and it had no author.
That distinction is the one worth carrying forward, because it is the same distinction that decides whether retrieval-augmented generation over support content pays back. Retrieval over past resolutions is the least speculative thing anyone can do with a language model in a support estate: no autonomy, no irreversible action, a copilot drafting an answer for a human who approves it. What it cannot survive is ambiguity about the corpus. A copilot answers from whichever store it was indexed against. Point it at two and you have industrialised the disagreement: same question, two confident answers, at speed, with no seam a user can see. Build one vector store per supplier and you have encoded the commercial boundary into the retrieval layer, which is exactly the boundary the organisation was paying to remove.
So the sequence inverts the usual one. Declare the authoritative base first, and give the declaration an owner with a named role and a place in the governance matrix. Then merge, with lineage kept from every surviving article back to the incidents that produced it, because an answer whose provenance cannot be traced cannot be corrected and cannot be defended. Then instrument freshness: article age, last-touched date, and the share of resolutions that cite an article rather than a person's memory. Only then index. Our Platform work treats that order as non-negotiable, and Hominis is built on the assumption that the substrate has one owner, because a retrieval layer over a contested corpus produces confident output that nobody in the room can adjudicate. Traceability of this kind is where the European rules on AI have been heading since the first draft. The reason to build it now is not the rules. It is that an answer you cannot trace is an answer you cannot improve.
One clause in this contract already understood the compounding. Root-cause documentation was required for the most severe incidents, for application-outage incidents at the next level down, and for anything that had recurred three or more times in production. That is a well-designed learning trigger. It wrote into the base the desk did not use.
The outcome
What this engagement produced was a review. It set the contracted process beside the operated one and named the divergences: ticket ownership through hand-off and hand-back, the follow-up call that checks whether a closed issue actually went away, and which knowledge base was used. It counted the stores, recorded that the organisation's base sat on a document site with no connection to the ticket tool, and recommended the roles the governance model was missing. No base was merged, no store was retired, no integration was built in this phase. The findings fed a re-procurement.
What would be done differently now is measurement, and it is cheap. Nobody had the share of escalations whose answer already existed somewhere in one of the two stores. That single figure is the business case for consolidation, and it can be computed from the ticket log and the article set without asking anyone a question. Nobody had article age distribution either, so "outdated" stayed an adjective in a review rather than a number on a dashboard.
Two bases is not a knowledge problem. It is a governance problem wearing a knowledge problem's clothes. The stores diverged because the contract named a maintainer, practice named a different one, and no role existed that could say which naming won.