Four Pillars of a Living Knowledge Base: Store, Relate, Trust, Retrieve

Four Pillars of a Living Knowledge Base: Store, Relate, Trust, Retrieve

A Reflection on Building Knowledge Systems That Actually Work

By Jean Louis

After many years of building and maintaining knowledge systems, I have come to understand that knowledge management rests on four irreducible principles. Not ten. Not twenty. Four.

Store. Relate. Trust. Retrieve.

Everything else is implementation. These are the pillars. If any one of them is weak, your knowledge base is not a knowledge base. It is a collection of files with no soul.

The Four Pillars

1. Store — With Integrity

You cannot retrieve what you did not store. But storage alone is not enough. You must store with integrity.

This means:

Deterministic metadata — file size, hash, page count, dimensions, timestamps — extracted by program, not guessed
Immutable source documents — the original remains the original
Version control — every change recorded, every author identified
Permanent identifiers — every object has a unique, permanent address

Without integrity in storage, you have a hoard, not a knowledge base.

2. Relate — With Precision

Knowledge is not isolated facts. Knowledge is connections. A fact without context is trivia. A document without relationships is noise.

To relate with precision, you need:

Typed relationships — not just “this links to that,” but “this supports that,” “this contradicts that,” “this supersedes that”
Strong connections — links that cannot break
Bidirectional awareness — every object knows what points to it
Explicit structure — hierarchy, cross-links, compound objects

Without precision in relationships, you have a pile, not a network.

3. Trust — With Provenance

A knowledge base that you cannot trust is worse than no knowledge base at all. Wrong answers delivered confidently are dangerous.

Trust requires:

Provenance — every fact knows its source
Permissions — not everyone should see everything
Audit trails — who changed what, when, and why
Verification — signatures that cannot be forged
Human judgment — a person in the loop, deciding what to keep

Without trust, you have opinions, not knowledge.

4. Retrieve — With Speed and Precision

Storage without retrieval is a tomb. Relationships without retrieval are a labyrinth. Trust without retrieval is irrelevant.

Retrieval requires:

Multiple dimensions — search by name, text, metadata, relationships, categories, dates, people, projects
Indexes — full-text, vector, keyword, fuzzy
Query capability — not hunting and hoping, but structured questions that return exact answers
Granularity — paragraph-level, not document-level

Without retrieval, you have a library with no catalog.

The CODIAK Process

Douglas Engelbart’s CODIAK framework — Concurrent Development, Integration, and Application of Knowledge — describes how organizations can achieve high performance by continuously analyzing, digesting, integrating, collaborating, developing, applying, and re-using knowledge.

These are human actions. A computer can assist. A computer cannot replace.

The four pillars support CODIAK:

Store enables knowledge accumulation
Relate enables knowledge integration
Trust enables knowledge application
Retrieve enables knowledge re-use

Without all four, the CODIAK process collapses. Without all four, you are not augmenting human intellect. You are just moving information around.

The Open Hyperdocument System

In 1998, Engelbart and his colleagues published the Technology Template Project — a hierarchy of characteristics for an Open Hyperdocument System. It specified:

Elementary objects of arbitrary types — text, graphics, equations, tables, images, video, sound, code
Object identifiers with timestamps — automatic creation and modification records
Personal signatures — cryptographic verification of authenticity
Global, human-understandable object addresses
Back-links — every object knows what links to it
Access control down to the object level
Mixed-object documents — arbitrary combinations of elementary objects
A Journal system — permanent catalog numbers with guaranteed access

This is not speculation. This is a specification. It was published in 1998. It remains the most complete vision for knowledge work ever articulated.

The four pillars — Store, Relate, Trust, Retrieve — are the practical expression of Engelbart’s vision. They are the method. The OHS is the architecture.

What This Means for Practice

If you are building a knowledge base, ask yourself four questions:

Store — Are your objects stored with integrity? Do you have deterministic metadata? Permanent identifiers? Version control?
Relate — Are your relationships typed and enforced? Do links break silently? Do you know what points to what?
Trust — Do you have provenance? Permissions? Audit trails? Is a human in the loop?
Retrieve — Can you find what you need across multiple dimensions? Quickly? Precisely?

If you answer “no” to any of these, you do not have a knowledge base. You have a collection of files.

The Next Article

In the next article, I will describe the Open Hyperdocument System — not as theory, but as implementation. I will show how the four pillars map to Engelbart’s OHS framework, and how a Dynamic Knowledge Repository can be built on relational databases, foreign keys, version control, and deterministic programs.

I will show why, after many years, my DKR is still alive — because it was built on bedrock, not on sand.

References

Engelbart, D. C. (1998). Technology Template Project - OHS Framework. Doug Engelbart Institute.
https://www.dougengelbart.org/content/view/110/460/

Engelbart, D. C. (1992). The CODIAK Process Cluster: Best Strategic Application Candidate. Doug Engelbart Institute.
https://www.dougengelbart.org/content/view/116/

Engelbart, D. C. (1962). Augmenting Human Intellect: A Conceptual Framework. Stanford Research Institute.

Keep your hands on the wheel. The computer is a tool. You are the curator. 🧙🐘