

The company's leadership came to us with a broad brief — build an AI transformation strategy and identify where AI could become competitive advantage. The operational knowledge function surfaced early in the audit as a quiet structural exposure: hours lost to searches, 1,000+ documents with no single owner, station-level staff deciding on whatever copy was easiest to find. Once named as a transformation target, the question stopped being whether to act and became how to redesign the function. The engagement was framed as functional transformation, not search deployment.
We didn't run this as a vendor engagement. We worked side by side with the client's teams for weeks — co-interviewing employees, shadowing workflows in head office, and travelling to //stations to watch how staff actually access information under operational pressure.



Ground-level discovery
That on-the-ground perspective was structurally important. Most knowledge transformations are designed from conference rooms by people who imagine how end users work.
We sat with the people who actually run the function — operational staff under time pressure, regulatory affairs explaining why some documents had competing versions, head-office owners who held individual pieces of the content estate but had no view of the whole.
Built together
The close collaboration did two things.
1. It gave us the operational truth — not the version of the function described in policy documents, but the version that actually runs.
2. It gave the client's teams co-authorship of the transformation: the new operating model wasn't presented to them as an outside design, they had helped build it. This is the precondition for adoption that actually holds, and the reason the client retained internal capability to keep extending the work after the engagement closed.

An enterprise-grade, governed retrieval layer designed for a distributed workforce operating under regulatory and time pressure.
AI Capability Layer
Operational Impact
Knowledge Function Performance
Financial & Organizational Impact
Governed Foundation, Then Retrieval
Most knowledge projects start with the technology layer. We started with content governance — defining ownership, retiring obsolete versions, building the tiered authority model. The retrieval layer was then designed on top of a governed estate, not used to paper over an ungoverned one. This sequencing was the single biggest predictor of durability.
Designed for the Hardest User First
Operational staff working under time pressure on shared devices were the design centre — not the office user with a desktop and time to read. Designing for the hardest population first meant office use cases came along naturally, the inverse approach would have failed at the front line.
Co-Authored With the People Who Own the Function
Regulatory affairs, operations leadership and front-line supervisors weren't presented with a finished design. They helped build the operating model — defining what authoritative means, who owns what, how exceptions escalate. Co-authorship is the precondition for adoption that actually holds.
Capability Transfer as the Deliverable
The engagement closed with an internal team (operations and IT together) equipped to evolve the function as procedures change. The client retained not a search tool but the capability to operate a governed operational knowledge function as a permanent organisational capability.
