Knowledge Lake

A persistent foundation for organisational knowledge

Organisations accumulate information faster than they can turn it into reusable knowledge.

Documents become scattered across collaboration platforms. Decisions disappear into meeting notes. Technical knowledge becomes dependent on particular employees. Policies become disconnected from their sources. AI systems are given access to thousands of documents without a reliable way to distinguish established knowledge from working material.

A Knowledge Lake provides an architectural foundation for addressing this problem.

Acta Laurel is developing a file-oriented Knowledge Lake Reference Architecture for managing source artefacts and portable representations of explicit knowledge.

Knoledge Lake purpose is straightforward:

Preserve organisational knowledge as a durable, traceable and portable asset that can be used by people, systems and AI.

The Knowledge Lake Concept

Knowledge Lake is not a term invented by Acta Laurel.

Beheshti, Benatallah, Nouri and Tabebordbar introduced the Knowledge Lake in peer-reviewed research as a contextualised Data Lake.

Their work addressed a fundamental weakness of conventional Data Lakes: storing large quantities of data does not necessarily provide sufficient context to understand and use that data effectively.

Their Knowledge Lake architecture combined data with contextual information and capabilities including curation, indexing, querying, provenance and security.

Acta Laurel builds upon this architectural lineage rather than redefining it.

That question leads to the Acta Laurel Knowledge Lake Reference Architecture.

Our work asks a related but different question:

What would a Knowledge Lake look like if portable explicit knowledge—not only contextualised data—became a primary managed asset?

The Acta Laurel Specialisation

Acta Laurel defines a file-oriented Knowledge Lake Reference Architecture for managing source artefacts and portable explicit knowledge.

The distinction is important.

Traditional information environments typically begin with files or data and build systems around them.

Acta Laurel separates the material an organisation possesses from the explicit knowledge it creates from that material.

The Knowledge Lake therefore becomes a persistent foundation through which organisational knowledge can be created, stored, retrieved, transferred and applied.

What Does a Knowledge Lake Contain?

Source Artefacts

A Source Artefact is material retained because knowledge derives from it, refers to it or depends upon it.

Examples include:

reports;
contracts;
policies;
research papers;
presentations;
database exports;
photographs;
correspondence;
meeting recordings;
spreadsheets;
technical documentation;
external standards.

A source is not automatically evidence.

A source becomes evidence when it is used to substantiate a particular claim, decision or knowledge concept.

Keeping this distinction prevents the architecture from making assumptions about how every stored artefact will eventually be used.

Explicit and Tacit Knowledge

Source Artefacts

A Knowledge Lake cannot contain everything an organisation knows.

Some knowledge remains tacit.

It exists in people's experience, judgement, skills and understanding.

Organisational knowledge becomes directly manageable by an information system when aspects of that knowledge are articulated into explicit representations.

This distinction is grounded in established Knowledge Management research, particularly Nonaka's work on the interaction between tacit and explicit knowledge.

The purpose of a Knowledge Lake is therefore not to claim that every form of human knowledge can be stored.

It is to manage the explicit representations of knowledge that an organisation chooses to preserve.

The Minimal Architecture

One of the central principles of the Acta Laurel architecture is simplicity.

A conforming implementation should not require dozens of infrastructure components merely to preserve knowledge.

The minimal physical architecture is:

knowledge-lake/

│

├── lake.yaml

│

├── sources/

│

└── knowledge/

└── index.md

Only three architectural areas are required.

lake.yaml

Describes the Knowledge Lake itself.

It provides lake-level identity and configuration and can record information such as:

name;
ownership;
purpose;
profile;
version;
governance information.

sources/

Contains source artefacts retained by the Knowledge Lake.

These artefacts may be referenced by Knowledge Concepts and used to establish provenance.

knowledge/

Contains the explicit knowledge corpus.

This directory forms the portable Knowledge Bundle and contains the Knowledge Concepts that constitute the durable knowledge environment.

The minimal architecture is intentionally small.

Complexity should exist where it creates knowledge value—not merely because an architecture permits it.

Workspace

Knowledge creation is rarely tidy.

People take notes.

Teams hold meetings.

Analysts explore ideas.

Architects sketch designs.

AI generates drafts.

Projects produce temporary working material.

The optional workspace/ area provides a location for these activities.

workspace/

├── inbox/

├── meetings/

├── initiatives/

└── scratch/

Workspace material is non-authoritative by default.

That does not mean it cannot be searched or used.

An AI assistant helping someone prepare for today's meeting may legitimately use today's meeting notes.

The important distinction is that working material must not silently be presented as established organisational knowledge.

Curation may move or transform working material into durable knowledge.

But this is not a mandatory lifecycle.

Knowledge can also be created directly within the durable knowledge corpus.

Vocabulary

Different parts of an organisation often describe the same thing differently.

The optional vocabulary/ area allows a Knowledge Lake to establish controlled terminology.

For example:

vocabulary/

├── types.yaml

├── tags.yaml

└── relationships.yaml

This can govern concepts such as:

recognised knowledge types;
terminology;
classifications;
tags;
relationship names.

Acta Laurel deliberately uses the term vocabulary at this stage rather than ontology.

A controlled list of types and relationships does not automatically constitute a formal ontology.

If an organisation later develops formal classes, axioms, semantic constraints and inference models, an ontology may become appropriate.

The architecture allows semantic sophistication to grow with actual requirements.

Portable Knowledge

One of the most important principles of the architecture is that organisational knowledge should not unnecessarily depend on the software currently used to manage it.

Applications change.
Vendors disappear.
Databases are replaced.
Search platforms evolve.
AI models change rapidly.

Knowledge often needs to survive all of them.

Acta Laurel therefore favours knowledge representations that are:

human-readable
machine-readable
portable
versionable
linkable
tool-independent

The architecture currently uses the Open Knowledge Format (OKF) as its primary representation model for Knowledge Concepts and Knowledge Bundles.

OKF uses Markdown documents with structured YAML metadata and deliberately avoids requiring specialised infrastructure merely to read the knowledge.

This creates a useful architectural principle:

Software operates on the knowledge. Software does not own the knowledge.

Knowledge with Provenance

Finding an answer is only part of knowledge management.

Sometimes the more important question is:

Why should I trust this answer?

Knowledge Concepts can retain references to the source artefacts from which they derive.

At the simplest level:

SOURCE

│

│ supports

▼

KNOWLEDGE CONCEPT

More sophisticated environments can record:

SOURCE

│

▼

ACTIVITY

│

├──── performed by ────► ACTOR

│

▼

KNOWLEDGE CONCEPT

│

▼

VERIFICATION

The Open Knowledge Format provides a lightweight source-based provenance mechanism.

Where richer activity-level provenance is required, the architecture can align with the W3C PROV model.

This allows provenance complexity to grow according to business need.

Identity Before Labels

Human-readable titles are important.

They are not reliable identities.

An organisation can legitimately contain:

Data Retention Policy

for different countries, entities, business units or historical contexts.

Likewise, two people can have exactly the same name.

Knowledge therefore requires stable identity independent of its display label.

Within OKF, a Knowledge Concept receives an identity based on its path within a Knowledge Bundle.

This means duplicate titles can be detected as potential governance issues without incorrectly treating every duplicate label as the same concept.

Knowledge Relationships

Knowledge becomes more valuable when relationships can be navigated.

For example:

POLICY

│

├── governs ─────► PROCESS

│

├── applies to ──► BUSINESS UNIT

│

└── references ──► STANDARD

or:

SYSTEM

│

├── supports ────► CAPABILITY

├── produces ────► DATA PRODUCT

└── owned by ────► TEAM

Links between Knowledge Concepts naturally create a concept link graph.

This graph should not automatically be called an Enterprise Knowledge Graph.

A full Knowledge Graph introduces additional concerns around entity identity, semantics, graph models, schemas, validation and potentially inference.

The Knowledge Lake can therefore provide the foundation from which a richer Knowledge Graph is later constructed.

Governance and Security

Metadata does not provide security.

Writing:

classification: confidential

does not prevent unauthorised access to a file.

Classification describes how knowledge should be treated.

Actual authorisation must be enforced by the system hosting or distributing it.

Depending on the implementation, enforcement may include:

filesystem permissions;
repository permissions;
identity and access management;
object-store policies;
encryption;
separate repositories;
separate infrastructure;
separate devices or security environments.

Acta Laurel therefore follows a simple principle:

Classification is descriptive. Authorisation is enforced by the hosting and distribution environment.

One Organisation Does Not Necessarily Mean One Lake

Centralisation is not automatically good architecture.

Knowledge belonging to different legal entities, clients, security domains or ownership boundaries may need to remain separate.

For example:

ORGANISATION

│

├── Corporate Knowledge Lake

│

├── Research Knowledge Lake

│

└── Client Engagements

│

├── Client A Knowledge Lake

├── Client B Knowledge Lake

└── Client C Knowledge Lake

Each Knowledge Lake can use the same Reference Architecture while maintaining independent ownership, access controls and lifecycle.

This supports an established security principle: least privilege.

Knowledge should be available where it is required—not universally accessible merely because it belongs to the same broader organisation.

Knowledge Lake and Data Lake

ke primarily manages data.

The original Knowledge Lake research extends the Data Lake by introducing contextualisation and knowledge-oriented capabilities.

Acta Laurel's specialisation places explicit Knowledge Concepts alongside retained source artefacts at the centre of the architecture.

Conceptually:

DATA LAKE

│

│ contextualisation

▼

KNOWLEDGE LAKE

│

│ explicit representation

▼

KNOWLEDGE CONCEPTS

These architectures can coexist.

An enterprise Data Lake or Lakehouse may remain responsible for large-scale analytical data while a Knowledge Lake manages explicit organisational knowledge about that data, its meaning, ownership, policies, systems and decisions.

Knowledge Lake and Knowledge Warehouse

The Knowledge Lake provides the persistent foundation for source artefacts and explicit knowledge.

A Knowledge Warehouse provides enterprise capabilities for capturing, codifying, organising, retrieving and sharing organisational knowledge.

A simplified relationship is:

PEOPLE · SYSTEMS · AI

│

▼

KNOWLEDGE WAREHOUSE

│

Knowledge Services

│

▼

KNOWLEDGE LAKE

│

▼

PERSISTENT KNOWLEDGE

The Knowledge Warehouse therefore represents capabilities operating over organisational knowledge rather than simply a higher-quality directory inside the lake.

Knowledge Lake and AI

Artificial intelligence makes knowledge architecture more important, not less.

A large language model can read thousands of documents.

That does not tell it:

which document is authoritative;
which information is obsolete;
where a statement originated;
which terminology the organisation recognises;
who owns a concept;
whether working notes should be treated as policy;
which security boundary applies;
whether two similarly named concepts are actually the same thing.

A Knowledge Lake provides structure around those questions.

The AI system can change without requiring the organisation to reconstruct its knowledge every time a new model or platform appears.

What a Knowledge Lake Is Not

A Knowledge Lake is not simply a folder structure.

The folders are one physical implementation of architectural concepts.

It is not a document-management system.

Document management may operate alongside or over it.

It is not a vector database.

Vector indexes are derived retrieval infrastructure and can be rebuilt.

It is not automatically a Knowledge Graph.

Graph representations may be derived from the knowledge corpus.

It is not an AI system.

AI systems consume and create knowledge through governed processes.

It is not a replacement for a Data Lake or Lakehouse.

Those architectures solve different, although related, information-management problems.

And it is not a claim that all human knowledge can be stored in files.

The architecture manages explicit representations of knowledge.

Remember

Clear boundaries are as important as definitions.

Why File-Oriented?

Using files is a deliberate architectural decision.

Files provide several useful characteristics:

Portability

Knowledge can move between environments.

Transparency

Humans can inspect the underlying representation.

Versionability

Standard version-control technologies can track changes.

Tool independence

No proprietary application is required merely to recover the knowledge.

Interoperability

Different applications can consume the same underlying artefacts.

Longevity

Simple textual formats have historically survived generations of software.

File-oriented does not mean file-only.

A production Knowledge Lake can use databases, search indexes, graph stores, vector databases, object storage, APIs and AI services.

The distinction is that these technologies do not necessarily become the sole canonical representation of the knowledge.

Research Foundation

The architecture deliberately separates established research from Acta Laurel design decisions.

Knowledge Lake

Beheshti, S.-M.-R., Benatallah, B., Nouri, R. & Tabebordbar, A. (2018). CoreKG: a Knowledge Lake Service. Proceedings of the VLDB Endowment, 11(12).

DOI: 10.14778/3229863.3236230

This provides the principal academic prior art for the Knowledge Lake concept.

Knowledge Management

Alavi, M. & Leidner, D.E. (2001). Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS Quarterly, 25(1).

DOI: 10.2307/3250961

Provides the knowledge-management process foundation of creation, storage/retrieval, transfer and application.

Tacit and Explicit Knowledge

Nonaka, I. (1994). A Dynamic Theory of Organizational Knowledge Creation. Organization Science, 5(1).

DOI: 10.1287/orsc.5.1.14

Provides an important theoretical foundation for distinguishing tacit and explicit dimensions of organisational knowledge

Reference Architecture

Angelov, S., Trienekens, J.J.M. & Grefen, P. (2012). A framework for analysis and design of software reference architectures. Information and Software Technology, 54(4).

DOI: 10.1016/j.infsof.2011.11.009

Supports the use of a Reference Architecture as the reusable architectural foundation for concrete implementatio

Security

Saltzer, J.H. & Schroeder, M.D. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9).

DOI: 10.1109/PROC.1975.9939

Provides the established least-privilege security principle informing Knowledge Lake boundary decisions.

Standards and Specifications

Research establishes the conceptual foundation.

Technical specifications provide interoperability and implementation models.

The architecture currently draws particularly on:

Open Knowledge Format (OKF)

For portable Knowledge Concepts and Knowledge Bundles.

W3C PROV

For richer provenance where source-level provenance is insufficient.

ISO/IEC/IEEE 42010

For formal architecture-description concepts and terminology.

These sources have a different role from peer-reviewed research and are deliberately identified separately.

Acta Laurel's Contribution

Research does not prescribe a directory named sources/.

It does not prescribe workspace/.

It does not prescribe vocabulary/.

Nor does it prescribe the deployment profiles Acta Laurel proposes.

Those are architectural design decisions.

Acta Laurel's contribution is to bring established principles together into a practical, portable reference architecture for managing explicit knowledge.

The distinction is intentional:

Research supplies principles. Standards provide interoperable models. Architecture turns them into practical systems

The Objective

The long-term value of a Knowledge Lake is not measured by how many documents it contains.

It is measured by whether an organisation can continue to understand and apply its knowledge.

Can people find what the organisation knows?

Can they determine where it came from?

Can they distinguish working material from established knowledge?

Can systems interpret it?

Can AI use it responsibly?

Can the organisation move its knowledge when its technology changes?

Can new knowledge build upon what came before?

A Knowledge Lake provides the persistent architectural foundation for making those capabilities possible.

Technology changes. Organisational knowledge should not disappear with it.

Knowledge Lake

A persistent foundation for organisational knowledge

Knoledge Lake purpose is straightforward:

The Knowledge Lake Concept

Our work asks a related but different question:

The Acta Laurel Specialisation

What Does a Knowledge Lake Contain?

Source Artefacts

Explicit and Tacit Knowledge

Source Artefacts

The Minimal Architecture

lake.yaml

sources/

knowledge/

Optional Architectural Capabilities

Workspace

Vocabulary

Portable Knowledge

Knowledge with Provenance

Identity Before Labels

Knowledge Relationships

Governance and Security

One Organisation Does Not Necessarily Mean One Lake

Knowledge Lake and Data Lake

Knowledge Lake and Knowledge Warehouse

Knowledge Lake and AI

What a Knowledge Lake Is Not

A Knowledge Lake is not simply a folder structure.

Remember

Why File-Oriented?

Portability

Transparency

Versionability

Tool independence

Interoperability

Longevity

From Knowledge Lake to Knowledge Infrastructure

The Knowledge Lake is the foundation

Research Foundation

Knowledge Lake

Knowledge Management

Tacit and Explicit Knowledge

Reference Architecture

Security

Standards and Specifications

Open Knowledge Format (OKF)

W3C PROV

ISO/IEC/IEEE 42010

Acta Laurel's Contribution

The Objective

Your privacy matters