Knowledge as an asset

KAPRI Whitepaper - 08/2026

Authors:
Sabine Wax,
Christoph Wax
Organization: inside workspace GmbH
White Paper Version: 1.0
Publication Date: August 26, 2026

Companies are investing heavily in artificial intelligence. They are building data platforms, integrating language models, developing agents, and automating knowledge work. 

This creates a new dependency: AI systems can only operate as reliably as the knowledge bases on which they rely. This is precisely where a previously overlooked weakness of many organizations lies. 

Organizational knowledge is scattered across documents, wikis, databases, tickets, presentations, and the minds of experts. Information can be found. However, it often remains unclear: 

• which organization the information comes from,
• what its status was at the time of publication,
• what scope it is intended for,
• which version is available,
• what it refers to,
• and whether the published version has been modified since then.

People can partially compensate for such gaps through experience, inquiries, and personal networks. Technical systems cannot and should not simply assume these prerequisites.
 
When using AI, therefore, questions about infrastructure arise that go far beyond document management:

How can organizations identify, publish, and share their key knowledge in a way that allows both people and technical systems to work with it reliably?
How can organizations protect their knowledge assets during exchange?

This white paper introduces the concept of the knowledge asset to address these issues.
 
A knowledge asset links a defined object to a documented body of knowledge, organizational responsibility, and a specific scope. This transforms the body of knowledge into a permanently identifiable and versionable management object.
 
The focus is no longer on the individual document, but rather on the body of knowledge that an organization makes available in a specific version for a specific purpose.
 
An interoperable technical representation is required for the cross-organizational and cross-system publication of such a version: the Knowledge Asset Package.
 
The open KAPRI Specification Suite provides a conceptual and technical foundation for this. It links Knowledge Assets with rules for identity, versioning, publication, integrity, interoperability, and decentralized trust.

The current AI discussion is dominated by models. 

Which model is more powerful? How large can the context be? Which agents can perform tasks independently? How do we integrate corporate data? 

These questions primarily concern the processing of information. Another question often remains unanswered: 

What body of knowledge should an AI system use as the basis for its actions? 

A simple example:
 A company has a work instruction for a safety-critical process. The internal system contains the approved work instruction, an older version, a presentation on a planned change, a meeting minutes with open questions, an expert’s personal summary, training materials, and a new version that has not yet been published. 

For an experienced employee, this collection of documents isn’t necessarily a problem. They know the process, the context in which it was developed, and the relevant contacts. When in doubt, they ask for clarification. 

To an AI system, all of this content initially appears to be potentially useful information. 

The problem, therefore, is not just:
Can the AI find the documents? 

But rather:
Can AI determine the source of a piece of information, which version is available, what its status was, and what context it is intended for? 

A powerful model does not automatically solve this upstream question. It can process existing information, but it cannot reliably reconstruct missing organizational and technical context. 

The quality of AI-supported results therefore does not begin with the model. It begins with the knowledge infrastructure.

For decades, we have organized knowledge based on its storage media: documents, pages, files, folders, wiki entries, and datasets. 

These objects are necessary. However, they easily lead to a far-reaching conflation:
 What is stored is confused with the knowledge itself. 

A document is, first and foremost, a representation. The same body of knowledge can be presented as a manual, a website, a training document, a data structure, or a machine-readable interface. 

Conversely, multiple documents can contain different states of knowledge about the same subject. 

KAPRI’s General Asset Model therefore operates on a different level. It distinguishes between: 

Subject → State → Responsibility → Scope → Asset → Version → Representation → Publication 

This sequence distinguishes: 

• the subject under consideration,
• its documented state,
• the organizational responsibility,
• the scope,
• the resulting asset,
• its versions,
• their technical representations,
• and their releases.

An asset is not defined by a single file. It links a defined object to a documented state, organizational responsibility, and a specific scope.
 
For organizational knowledge, this general model is specialized in the Knowledge Asset Reference Model.

Knowledge in an organization is more than just available information. 

Organizations interpret information, link it to experience, test assumptions, make decisions, and develop a specific understanding of a subject based on this. 

Organizational knowledge is constantly emerging and evolving. Nonaka has already described knowledge development as a dynamic process in which individual and organizational knowledge are interconnected.[2] 

New insights emerge. Errors are discovered. Rules change. Experiences are added. Decisions are revised. 

The Knowledge Asset Reference Model defines the documented state of an organization’s understanding of a defined subject at a specific point in time as a “Knowledge State.” 

A “Knowledge State” is not a claim to universal truth. It describes how an organization understands a subject as documented at a specific point in time. 

Responsibility and scope are not part of the Knowledge State itself. They are linked to it within the Knowledge Asset. 

A knowledge asset links: 

• a defined subject,
• a documented knowledge state,
• organizational responsibility
• and a defined scope.

This transforms a documented state of knowledge into a permanently identifiable and versionable management object.
 
The central question is no longer simply: Where is our knowledge?
 
But rather: Which states of knowledge are so relevant to our organization that we want to specifically manage their origin, development, versions, and use?
 
Organizational responsibility does not mean that a body of knowledge remains correct forever. It clarifies which organization is designated as responsible with regarding to a specific body of knowledge and scope. Whether and how this responsibility is fulfilled internally falls outside the scope of technical validation.
 
KAPRI can make this declared assignment technically traceable. However, it does not verify whether internal approval processes were technically appropriate or whether the content is objectively correct.
 
If the documented knowledge state changes, this can result in a new version of the knowledge asset. Previous versions remain identifiable as time-bound knowledge states.
 
Knowledge continues to evolve. An assigned state of knowledge is therefore not an endpoint, but rather a traceable stage within a development process.

Not all information is a strategic asset. 

Organizations invest significant resources in building specific knowledge states. Experts gain experience, teams develop methods, processes are optimized, standards are established, mistakes are analyzed, and decisions are refined over the course of years. 

The resulting body of knowledge is the outcome of cumulative work. 

Its value lies not solely in the information it contains. It lies in an organization’s ability to maintain it, develop it in a targeted manner, protect it, and repeatedly use it to create value. 

A knowledge asset can serve as the basis for: 

• decisions,
• work instructions,
• training,
• quality checks,
• compliance processes,
• software features,
• customer information,
• AI responses
• or actions of autonomous agents.

Investing in a body of knowledge can thus generate benefits and value across many applications.
 
As an asset, such a knowledge base must be actively managed. Its development must remain traceable, its integrity must be protected, and its use must be controllable.
 
Not every meeting minutes or text passage requires this level of management. Knowledge assets become relevant where bodies of knowledge have lasting significance, are used repeatedly, and are intended to be preserved, protected, or specifically developed further.
 
Knowledge management thus becomes a portfolio issue:
What knowledge assets are so valuable to our organization that we should identify, preserve, and develop them in a controlled manner?
 
The term “knowledge asset” conveys that a body of knowledge can fundamentally be regarded as an independent source of value and managed accordingly. Its concrete economic or strategic value arises from its quality, usability, applicability, and significance to the organization.

With AI, the reach of organizational knowledge expands. 

Knowledge is no longer read only by humans. Technical systems can search for, combine, and interpret information and use it as the basis for decisions or actions. 

A single piece of knowledge can be integrated into numerous processes via retrieval systems, language models, and agents. 

This scaling multiplies its potential benefits. However, it also multiplies the impact of outdated statements, unclear sources, and missing context. 

The greater the technical reach of a piece of knowledge, the more important it becomes to determine: 

• which version is being used,
• from which source it originates,
• what its publication status was,
• what scope it is intended for,
• and whether its representation has remained unchanged.

The quality of the knowledge infrastructure thus becomes an integral part of the quality and manageability of AI-supported processes.
 
The NIST AI Risk Management Framework describes governance as an overarching function for managing AI risks.[3]
 Such governance requires more than just rules for models and applications. It also requires transparent foundations for the knowledge bases with which these systems operate.
 
A powerful model cannot transform an unclarified state of knowledge into a responsible state of knowledge solely through processing.

Organizations can develop and maintain knowledge assets internally using various systems and technologies. 

As long as a knowledge state remains within the same organizational and technical context, internal rules can govern its use. 

This is no longer sufficient at system and organizational boundaries. 

It must be possible to represent and publish a version of a knowledge asset in such a way that independent recipients can unambiguously identify, technically verify, and process it. 

The relationship is as follows:
Knowledge Asset → Version → Representation → Publication 

A representation is the concrete technical manifestation of a version. 

A publication makes such a representation available to others as an identifiable and verifiable result. 

For knowledge assets, the knowledge asset package fulfils this role. 

A Knowledge Asset Package represents exactly one published version of a Knowledge Asset. It is not the Knowledge Asset itself, but rather its technical representation in the context of a specific publication. 

At this boundary, technical verification and the recipient’s decisions must remain separate. 

For example, it can be technically determined: 

• whether the package structure is valid,
• whether the intended components are present,
• whether the included package files are unaltered,
• whether the digital signature is valid,
• whether the certificate chain is technically valid,
• and which organization is identified in the signed publication.

Separately, the recipient decides: 

• whether they trust the publisher,
• whether the scope of validity is appropriate for the intended use,
• whether the content is technically appropriate
• and whether the publication is accepted according to their own rules.

Validation establishes technical facts. Trust and acceptance are decisions made by the recipient.

KAPRI does not replace these decisions. It creates a robust technical foundation upon which they can be made.

In doing so, KAPRI addresses issues that are also significant in other contexts. The FAIR Principles emphasize, among other things, the identifiability, interoperability, and reusability of digital resources.[4]
 W3C PROV provides a model for the cross-system representation of provenance information.[5]

KAPRI does not adopt these approaches unchanged. With Knowledge Asset Packages, it addresses its own specific objective: the interoperable publication of defined versions of an organization’s state of knowledge.
 

The KAPRI Specification Suite is an open specification suite for Knowledge Asset Packages.
 It comprises: 

• conceptual asset and knowledge asset models,
• a package architecture,
• common serialization rules,
• common data types,
• standard JSON schemas,
• an executable reference implementation
• and an architecture for conformance and interoperability testing.

KAPRI 0.9.0 – Release Candidate 1 was publicly released on GitHub on August 25, 2026.[1]
 
The General Asset Model defines the general concepts and relationships of Subject, State, Responsibility, Scope, Asset, Version, Representation, and Publication.
 
The Knowledge Asset Reference Model extends this model to organizational knowledge. It defines the Knowledge State as the documented state of organizational understanding and the Knowledge Asset as a specialization of the general asset concept.
 
The Knowledge Asset Package Architecture describes the interoperable technical representation of a published version of a knowledge asset.
 
Common rules for serialization, data types, and specific package schemas make this architecture technically implementable and verifiable.
 
A Knowledge Asset Package contains a few clearly distinct structural components and package files:
 
Package Manifest
The Package Manifest identifies the Knowledge Asset, its version, the publication, and the responsible organization. It also serves as the starting point for signature and integrity verification.

Packing List
The packing list describes the physical inventory of the package files.
Structural package documents such as manifest.json, packing-list.json, and composition documents are not included in this file inventory.

Composition
A composition describes the logical organization of the content items, independent of the physical file structure.

Package Files
Package files contain the concrete technical representations of the published content.
 For encrypted package files, key delivery remains separate from the package. A KAP Key Delivery Message transmits the encrypted file keys required for a specific recipient.
 
The KDM is not part of the Knowledge Asset Package. Package validation and KDM validation remain separate processes.
 
The signed manifest forms the starting point of a verifiable chain of integrity extending to the inventoried package files.
 
KAPRI does not define a new knowledge management application. The specification does not prescribe which tools should be used to develop or maintain knowledge assets internally.
 
It defines common rules at the point where published knowledge crosses the boundaries of independent systems and organizations.

A knowledge management system supports organizations in developing, documenting, finding, and applying knowledge. 

A knowledge infrastructure, in addition, establishes common rules for the publication and exchange of accountable knowledge assets between independent systems and organizations. 

This principle is familiar from other digital infrastructures. 

An email infrastructure does not dictate which editor must be used to write a message. 

The web does not dictate which content management system is used to maintain content. 

A payment infrastructure does not dictate which ERP system was used to generate an invoice. 

What matters are common rules at the boundaries of independent systems.

Such a level has largely been missing for organizational knowledge to date. 

At the boundary of an organization, there is no need to explain that a published body of knowledge is universally true or binding for all recipients. 

It must be clear: 

• which organization published it,
• which knowledge asset it represents,
• which version was published,
• what status and scope it has,
• whether its integrity has been preserved,
• and how it can be processed technically.

Other systems can verify these statements and then decide, based on their own rules, on trust, acceptance, and use.
 
Permanently identifiable knowledge assets can also be explicitly linked to one another. They can reference other bodies of knowledge, depend on them, supplement them, or specialize them.
 
A knowledge network emerges when bodies of knowledge can be exchanged in an interoperable manner across system and organizational boundaries based on common rules. Explicit relationships between knowledge assets can further structure this network.
 
A knowledge network does not require a central consensus.
 
Multiple organizations can publish different knowledge assets on the same subject. Each publication remains independently traceable in terms of origin, version, scope, and integrity.

The shared infrastructure does not determine which body of knowledge is generally correct. It enables participants to evaluate, classify, and use different bodies of knowledge according to their own trust rules.

Knowledge assets transform strategically relevant bodies of knowledge into explicit management objects. 

This gives rise to three key tasks for organizations: 

Portfolio 
Which knowledge items are strategically relevant and should be managed as knowledge assets on a long-term basis? 

Governance
Who is responsible for their development? How are knowledge states reviewed, documented as versions, and published? How are errors, new insights, and changes incorporated into subsequent versions? 

Usage and Trust
Which internal and external knowledge states may people, applications, and AI systems use as the basis for their work? According to which rules are origin, status, scope, and technical validity assessed? 

Knowledge management is thus directly linked to: 

• Governance,
• Enterprise Architecture,
• Information Security,
• quality management,
• compliance,
• Software Development
• and AI Governance.

The role of knowledge management is evolving.

Knowledge management does more than just organize information. It shapes the lifecycle and flow of organizational knowledge.

The discussion about AI often begins with technology. But as soon as AI systems are regularly involved in decisions and processes, the question of their knowledge base becomes unavoidable.

The strategic question is no longer just:
 Which model do we use?
 
But rather:
What body of knowledge do we allow to take effect within our organization?
 
Larger context windows, better search methods, and more powerful models do not answer this question.
 
Organizations must be able to identify their key knowledge bases, develop them in a controlled manner, document them as versions, and publish them for specific use cases.
 
The goal here cannot be to be error-free.
 
Knowledge evolves because assumptions are tested, errors are revealed, and insights are refined. Well-founded bodies of knowledge do not establish a definitive truth. They provide transparent starting points for application, critique, and further development.

Note on the Status of This Document 

This white paper is a conceptual document, not a normative one.
It explains the technical rationale and strategic context of knowledge assets, knowledge asset packages, and KAPRI. For technical implementations, only the KAPRI Specification Suite in the version referenced herein is authoritative.
The technical reference underlying this white paper is KAPRI 0.9.0 – Release Candidate 1.[1]