Why Knowledge Should Survive the LLM

AI can give us answers in seconds.

I ask a question, check the answer, compare it with other sources when necessary, and eventually reach a conclusion I can rely on.

At that point, it becomes part of what I know.

The problem comes later.

A few months from now, I may want to remember why I reached that conclusion.

• Where did the information come from?
• What has changed since then?
• Why is the answer I get today different from the one I accepted before?

In the past, I kept notes from books. Later, Markdown and Git made it much easier to keep track of my work and how it changed.

Git is excellent at showing what changed in a file.

But what I increasingly want to preserve is not just a change in text.

I want to preserve a change in meaning.

Knowledge Changes

Consider how our understanding of the relationship between dinosaurs and birds has changed over time.

An older book and a newer one may describe that relationship differently. A text diff can show which sentences changed, but that is not the most interesting part.

The more important questions are:

• What new evidence appeared?
• Which ideas became more strongly supported?
• How did our understanding change?

That is more than a change in wording. It is a change in knowledge.

For a knowledge system, I want something like a semantic diff.

Not only:

What changed in the text?

but:

What changed in what we know?

Of course, what we know today may later turn out to be incomplete or wrong.

That is not a reason to avoid storing it. It is one reason to store it.

If we preserve what we understood at a particular point in time, together with the evidence behind it, we have a baseline. When new evidence appears, we can see not only that something changed, but how and why it changed.

The goal is not to freeze today’s answer forever.

The goal is to preserve a reference point for tomorrow.

Do Not Make the LLM Rediscover What We Already Know

This is one reason I remain interested in graph databases.

A graph database can store relationships explicitly. In the age of LLMs, that may sound almost too simple.

But useful knowledge is often simple:

• a relationship,
• a definition,
• a rule,
• a conclusion we have already checked.

If we already know something and expect to use it again, there is little value in asking an LLM to rediscover it every time.

We can store it as knowledge and let the LLM use it when it needs to reason about something more complex.

I see the roles this way:

The knowledge system stores what we have already learned.
The LLM reasons over it.

This does not mean storing every conversation with an LLM. That would simply create another information problem.

What matters is extracting and preserving the small, reusable pieces of knowledge that remain useful after the conversation ends.

Physics gives us a useful analogy. Many observations can eventually lead to a compact formula that captures something we can reuse.

The formula does not preserve every step of the discovery process. It captures something we have learned from it.

A knowledge system needs a similar idea.

Preserve what is worth reusing, not everything that happened along the way.

Knowledge Should Outlive the Model

Knowledge should not exist only inside one model or one application.

Today I may use one LLM. Tomorrow I may use another. A person may need the same knowledge, and several AI agents may need it too.

An LLM can help us discover, check, explain, or use knowledge.

But it should not be the only place where that knowledge lives.

Knowledge should exist independently of any particular LLM.

If the model changes, the knowledge should remain.

We should not have to relearn everything simply because we changed tools.

The Same Event Can Have Different Records and Perspectives

I began thinking more seriously about this while working with primary COVID-19 data.

At first, I assumed that primary data would give me one reliable answer.

It did not.

Even primary sources could describe what appeared to be the same situation differently because they used different definitions, reporting times, geographic scopes, aggregation methods, or reporting processes.

I found myself asking a different question.

Instead of only:

Which one is correct?

I began asking:

Why are these two different?

That question was often more useful.

And this is not only about numerical data.

Historical events provide another example.

The same event may be recorded differently in different countries or regions. Different aspects may be emphasized, and the meaning attached to an event may depend on who recorded it, from which perspective, and at what time.

Each record has a context.

If we keep only one account and discard the others, we may also discard the information that helps explain why the differences exist.

A knowledge system should be able to preserve multiple observations, records, and perspectives about the same event, together with their context.

Some differences may later be resolved.

Others may remain because they reflect genuinely different perspectives.

This does not mean that every claim is equally reliable, or that contradictions do not matter.

It means something simpler:

Do not erase the differences before you understand why they exist.

Knowledge Also Has a Flow

Knowledge is not only a collection of facts and relationships.

It also moves through a process:

Observation → Assessment → Decision → Action → Result

Someone observes something. That observation is assessed. A decision follows. Someone takes action, and that action produces a result.

If we preserve only the final result, we may later know what happened but not why.

To understand the path, we may need to know:

• What was known at the time?
• Who made the decision?
• What evidence was used?
• What action followed?
• What happened afterward?

That path is also part of the knowledge.

This becomes especially important as AI agents begin to take actions rather than simply answer questions.

If an agent changes a system, approves something, sends a message, or triggers another process, we will want to know not only what it did, but what knowledge led to that action.

SEPT

I have started organizing these ideas into four principles:

SEPT — Shared, Evolving, Plural, and Traceable.

Shared
Knowledge should not be locked inside one LLM or application. It should be available to different models, people, systems, and agents.

Evolving
Knowledge should have a history. We should be able to see what we understood at a particular point in time and how that understanding changed.

Plural
The same event may have multiple observations, records, or perspectives. Their context should be preserved rather than collapsed into a single answer too early.

Traceable
We should be able to trace where knowledge came from, who created or changed it, and how it contributed to later decisions, actions, and results.

SEPT is not tied to a particular database technology.

Sometimes a relational database may be enough. Sometimes a graph database may be a better fit. Documents, event stores, or a combination of technologies may make sense.

The technology is not the main point.

The real question is:

Can the knowledge survive changes in models, tools, and people?

LLMs will keep changing.

We will use more than one of them. Some will disappear, and new ones will appear.

What we have already learned should not disappear with them.

We do not need to preserve everything an LLM says.

We need to preserve the basic knowledge that is worth reusing.

We should keep it as a reference point without assuming that it will always remain correct. We should preserve meaningful differences when they exist. And we should be able to trace where the knowledge came from, how it changed, and what happened because of it.

Shared. Evolving. Plural. Traceable.

That is what I mean by persistent knowledge.

That is SEPT.