Signed in as:
filler@godaddy.com
What Is a Reference Architecture?
A reference architecture is not the architecture of one particular system.
It provides a reusable architectural foundation for a class of systems.
A concrete architecture applies that foundation to a particular organisational context.
This distinction is important.
The Reference Architecture does not dictate how every organisation must organise its knowledge.
It establishes the architectural concepts and constraints within which appropriate implementations can be created.
Architectural Context
The Reference Architecture sits between Knowledge Management principles and concrete technology implementations.
Each layer has a different responsibility.
Research provides conceptual foundations.
Standards and specifications provide formal models and interoperability.
The Reference Architecture translates those foundations into architectural decisions.
Technology implements them.
Optional Workspace
Some Knowledge Lakes benefit from maintaining working material close to the durable knowledge environment.
For those environments, the Reference Architecture permits:
workspace/
For example:
workspace/
├── inbox/
├── meetings/
├── initiatives/
└── scratch/
These directories are conventions rather than universal requirements.
Workspace artefacts are non-authoritative by default.
They may still be searched, analysed or supplied to an AI system when appropriate.
Curation is possible.
Mandatory promotion is not required.
Knowledge may also be created directly within knowledge/.
The Complete Logical Model
This is the logical architecture.
A concrete implementation can distribute these concerns across different technologies while retaining the same conceptual model.
Canonical Knowledge and Derived Infrastructure
One of the most important architectural distinctions is between canonical knowledge and derived infrastructure.
The Knowledge Lake contains the durable knowledge assets.
Systems can derive specialised representations from those assets.
KNOWLEDGE LAKE
│
Canonical Knowledge
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
SEARCH INDEX VECTOR INDEX GRAPH DATABASE
│ │ │
└─────────────────┼──────────────────┘
│
▼
APPLICATIONS & AI
Search indexes can be rebuilt.
Embeddings can be regenerated.
Vector databases can be replaced.
Graph technologies can change.
AI models can change.
The organisation should not lose its canonical knowledge because a derived technology was replaced.
This is a central principle of the Reference Architecture.
Knowledge Representation
Portability requires a representation model.
Acta Laurel currently uses the Open Knowledge Format (OKF) for the knowledge layer.
OKF provides concepts such as:
Concept
An addressable unit of knowledge.
Concept ID
Stable concept identity within a Knowledge Bundle.
Knowledge Bundle
A portable collection of related Knowledge Concepts.
Source
Material from which a concept derives.
Provenance
Source information associated with the concept.
Status
Lifecycle information such as draft, stable or deprecated.
These terms should be inherited from OKF rather than independently redefined by the Reference Architecture.
This reduces unnecessary invention and improves interoperability.
Provenance
The Reference Architecture requires knowledge and source material to be capable of remaining connected.
At the baseline:
SOURCE ARTEFACT
│
│ derives / supports
▼
KNOWLEDGE CONCEPT
OKF provides a lightweight mechanism for recording sources.
Some enterprise environments require richer lineage:
ENTITY
│
▼
ACTIVITY ◄──────── AGENT
│
▼
ENTITY
For those environments, the architecture can adopt provenance aligned with W3C PROV.
This creates a deliberate maturity path:
Source Reference
│
▼
Source Provenance
│
▼
Activity Lineage
│
▼
Rich Provenance Model
Not every Knowledge Lake needs the most sophisticated model.
Architectural Boundaries
The Reference Architecture does not assume that all knowledge belongs in one repository.
A Knowledge Lake should represent a meaningful ownership, governance or security boundary.
For example:
ENTERPRISE
│
├── Corporate Knowledge Lake
│
├── Research Knowledge Lake
│
└── Engagement Knowledge Lakes
├── Client A
├── Client B
└── Client C
The appropriate boundary depends on factors including:
- ownership;
- confidentiality;
- legal entity;
- contractual restrictions;
- regulatory requirements;
- administrative responsibility;
- lifecycle;
- portability requirements.
This is particularly important for consulting organisations managing client knowledge.
A client's knowledge should not become inseparably mixed with the consultancy's corporate knowledge simply because both use the same tooling.
Security Model
The Reference Architecture separates classification from authorisation.
Metadata may describe:
classification: confidential
but that metadata does not enforce access.
Actual security belongs to the hosting and distribution environment.
KNOWLEDGE METADATA
│
▼
describes classification
│
HOSTING ENVIRONMENT
│
▼
enforces authorisation
│
┌─────────┼─────────┐
▼ ▼ ▼
IAM ACLs Encryption
This allows the architecture to work across different technology environments while maintaining a clear security principle.
Where security boundaries differ materially, separate Knowledge Lakes may be preferable.
Deployment Profiles
The Reference Architecture defines a common core.
Profiles adapt that core to different operating contexts.
Acta Laurel currently identifies three primary profiles.
Personal Profile
The Personal Profile applies the architecture to Personal Knowledge Management.
For example:
Personal/
│
├── lake.yaml
├── sources/
├── knowledge/
│ ├── index.md
│ ├── life/
│ ├── people/
│ ├── interests/
│ └── decisions/
│
└── workspace/
├── inbox/
├── daily/
├── projects/
└── scratch/
The categories shown are implementation choices.
They are not part of the normative Reference Architecture.
A person's classification system should reflect how that individual works.
The architecture supplies the foundation without prescribing a lifestyle methodology.
Enterprise Profile
The Enterprise Profile introduces stronger concerns around stewardship, shared terminology, organisational domains and governance.
A possible implementation is:
Enterprise/
│
├── lake.yaml
├── sources/
│
├── knowledge/
│ ├── index.md
│ │
│ ├── shared/
│ │ ├── glossary/
│ │ ├── people/
│ │ ├── systems/
│ │ ├── policies/
│ │ └── standards/
│ │
│ └── domains/
│ ├── strategy/
│ ├── finance/
│ ├── operations/
│ ├── technology/
│ └── data-ai/
│
├── vocabulary/
│
└── workspace/
The distinction between shared/ and domains/ is an Acta Laurel Enterprise Profile convention.
It is not the definition of a Knowledge Lake.
shared/ contains knowledge intentionally reusable across organisational boundaries.
domains/ provides areas in which stewardship belongs primarily to a particular business domain.
Concrete organisations can adapt the domain model to their operating structure.
Engagement Profile
Consulting, programmes, partnerships and client engagements create a distinct architectural problem.
Knowledge may be produced collaboratively while ownership and access remain bounded.
The Engagement Profile treats that boundary explicitly.
Client-Engagement/
│
├── lake.yaml
├── sources/
├── knowledge/
├── workspace/
└── vocabulary/
The structure may resemble an Enterprise Knowledge Lake.
The difference is primarily its ownership and governance context.
An Engagement Knowledge Lake can therefore remain independently portable.
At engagement completion, the knowledge can be:
- transferred;
- archived;
- retained according to agreement;
- integrated into the client's environment;
- selectively incorporated into reusable consultancy knowledge where permitted.
This avoids treating client knowledge as merely another folder inside an internal consultancy repository.
Profiles Are Not Separate Architectures
The profiles share the same core.
This creates consistency without requiring identical implementations.
Conformance
As the formal specification develops, it is important to distinguish between architectural requirements and recommendations.
The Reference Architecture should eventually use conventional normative language:
MUST
Required for conformance.
SHOULD
Recommended unless a justified reason exists not to follow it.
MAY
Optional.
For example:
- A Knowledge Lake MUST contain a knowledge corpus.
- A Knowledge Lake MAY contain a workspace.
- An Enterprise Profile SHOULD establish explicit stewardship.
This distinction prevents architectural preferences from accidentally becoming universal requirements.
The public website explains the architecture.
A separate formal specification should eventually define exact conformance rules.
What the Reference Architecture Does Not Prescribe
The architecture deliberately avoids prescribing technology unnecessarily.
It does not require:
Git
Git may be an excellent implementation choice for versioning, but version control technology is not part of the conceptual definition.
Obsidian
Obsidian can provide an effective human interface over a file-oriented Knowledge Lake, particularly for Personal Knowledge Management, but it is an implementation tool.
A vector database
Vector retrieval is derived infrastructure.
A graph database
A Knowledge Graph may be derived or maintained where appropriate.
A specific cloud provider
The architecture should remain deployable across local, private-cloud and public-cloud environments.
A mandatory ontology
Controlled vocabulary may be sufficient.
One universal folder taxonomy
Classification should reflect the deployment context.
One central enterprise repository
Knowledge boundaries should follow governance, ownership and security requirements.
This deliberate restraint is what keeps the architecture portable.
Technology Independence
A concrete Knowledge Lake implementation may eventually look like:
Another implementation may use entirely different products.
Both can conform to the same Reference Architecture if they preserve the relevant architectural concepts and constraints.
Relationship to Knowledge Services
The Reference Architecture establishes the persistent foundation.
Additional services operate over it.
This separation prevents the architecture from confusing the knowledge asset with the services used to consume it.