The knowledge that makes your AI useful to your business, the standards it applies, the context it draws on, the way it represents how your organisation actually works, is a strategic asset. In most organisations it currently lives inside a vendor’s platform, where you neither own it nor fully control it. That is a design choice, and usually an unexamined one, which is worth reversing before the cost of reversing it becomes significant.
I wrote previously about why AI assistants fall short on anything business-specific, and the conclusion was that the gap is architectural rather than a matter of better prompting. Organisations are missing a knowledge layer: a place for what they know to live in a form an AI can reliably draw on. This piece is about the next question, which is where that knowledge layer should sit once you have built it, and who gets to control it.
The knowledge has to live somewhere
When an organisation does the work of encoding what its AI should know, that knowledge has to be stored somewhere and delivered to the AI somehow. The path of least resistance is to build it inside whatever platform the organisation is already using. The knowledge gets configured in the vendor’s system, formatted according to the vendor’s structure, and delivered through the vendor’s tooling.
This feels efficient at the time, because the platform is already there and the integration is already built. The cost shows up later, in three predictable situations.
The first is when you want to change provider. A better model arrives, or the commercial terms shift, or the vendor’s roadmap diverges from your needs, and you discover that the knowledge you painstakingly encoded is entangled with the platform you are trying to leave. Moving it means rebuilding it, which means the switching cost is far higher than simply repointing an integration.
The second is when someone asks you to account for what your AI knew. A regulator, an auditor, a board member, or a client wants to understand what your AI was permitted to say on a particular date, and why. If the knowledge lives inside a vendor’s platform with no independent record, you usually cannot reconstruct it with confidence, which is an uncomfortable position to be in when the question carries consequences.
The third is quieter and more common. Over time, nobody is entirely sure what the AI has been told, because the knowledge has accumulated inside a system that was never designed to be read and reviewed by the people accountable for it. The knowledge exists, but it has stopped being legible to the organisation that depends on it.
This is a design problem
None of these situations is a failure of the AI or the vendor. They are the predictable result of bundling two things together that should be separate: the knowledge your organisation owns, and the tools that execute it.
The knowledge is yours. It reflects your standards, your judgement, your accumulated understanding of how your business works. The execution is a service you buy, and the market for that service is moving quickly enough that you will almost certainly change providers more than once over the next few years. Tying the first to the second means that every decision about the second is constrained by the cost of moving the first, which is exactly backwards. The thing you own and intend to keep should not be hostage to the thing you rent and intend to replace.
Separating them is straightforward in principle. Your organisational knowledge should live in a format you own and control, in a form that is readable by your team and by any AI you choose to use, governed by you, with a history you can inspect. How that knowledge reaches the model becomes a separate architectural decision, made deliberately on its merits rather than dictated by where the knowledge happens to be stored.
What this looks like in practice
This is the problem Score was built to address. Score is an open standard for encoding organisational knowledge in a format that belongs to you rather than to any vendor.
The principle is simple enough to state plainly. Your knowledge is written into structured files that your organisation owns, stored in systems you already control, readable and editable by your team without specialist tools, and versioned so that every change is tracked and every version recoverable. Those files can be read by any AI model, and when you change models, the knowledge travels with you, because it was never tied to the model in the first place.
Score is published as an open standard under a permissive licence, which matters for a reason beyond cost. An open standard cannot be withdrawn, cannot be locked behind a commercial relationship that sours, and cannot become a dependency in its own right. Solving vendor lock-in is pointless if the solution introduces a new vendor to be locked into. Score is owned by nobody, which is the only credible position for something whose purpose is to keep your knowledge independent.
The governance dimension matters most in regulated environments. Because the knowledge lives in versioned files with a clear history, the question of what your AI was permitted to say on a given date has a verifiable answer rather than a reconstruction. For organisations in financial services, legal, healthcare, and professional services, where that question is not hypothetical, this is the difference between a governance position that holds under scrutiny and one that does not.
Where Score stops
Score is a knowledge management standard. It does not plug directly into a vendor’s proprietary skill or agent framework, and does not claim to. What it gives you is ownership and governance of the knowledge layer, in a form independent of any platform. How that knowledge is delivered to a model in production remains a separate decision, which is the point. The knowledge layer belongs to you. The execution layer is a choice you make and remake as the market changes.
What Score offers is control over an asset you will increasingly depend on, held in a form that does not expire when your vendor relationship does.
The question worth sitting with
Most organisations have not asked where their AI knowledge lives or who controls it, because the question has not yet become urgent. It becomes urgent at exactly the moment it is most expensive to answer: when you want to switch, when someone asks you to account for what your AI knew, or when you realise nobody can quite say what it has been told.
So the question to sit with is this. If you decided tomorrow to change the AI tools your organisation depends on, what would happen to the knowledge you have built up inside them? If the answer is that you would have to rebuild it, or that you are not sure you could fully recover it, then the knowledge that has become a strategic asset is being held as someone else’s, and the time to change that is before the cost grows any further.
MultipleWorks helps organisations think through where their AI knowledge should live and how to keep control of it as the tools change. Score is an open standard, free to use and build on. Read more at multipleworks.com.hk/score or get in touch at hello@multipleworks.com.hk.