They made semantic search practical.

They made it possible to retrieve information based on meaning rather than exact keywords.

And they became one of the foundations of modern Retrieval-Augmented Generation, or RAG.

Today, when someone wants to build an AI application that can answer questions about documents, the architecture is often straightforward:

1. Collect documents.

2. Split them into chunks.

3. Generate embeddings.

4. Store those embeddings.

5. Retrieve the most relevant chunks.

6. Give them to an LLM.

For many applications, this works extremely well.

So a fair question is:

«Why build anything beyond a vector database?»

It is a question I have been asking myself while building AIKOQL.

And the answer is not:

«"Vector databases are bad."»

They are not.

The answer is also not:

«"AIKOQL should replace vector databases."»

That is not the goal either.

The more interesting question is:

«What happens when an AI system needs more than semantic retrieval?»

That is where I believe another layer of infrastructure may become useful.

Vector databases are excellent at what they do

Before discussing the limitations, it is important to acknowledge why vector databases became so popular.

They solve a real and important problem.

Traditional search often relies heavily on:

• Keywords

• Exact matches

• Text indexes

• Filters

Vector search adds another capability:

«Semantic similarity.»

Instead of searching only for identical words, the system can retrieve information that is conceptually related to a query.

For example:

«"How do users authenticate?"»

might retrieve a document containing:

«"The platform uses OAuth 2.0 for identity verification."»

Even though the query does not contain the exact words OAuth or identity verification.

That is extremely useful.

Vector databases are particularly strong for:

• Semantic search

• Document retrieval

• Similarity search

• RAG applications

• Recommendation systems

• Unstructured information

For many AI applications, that is enough.

And it should be enough.

«Not every AI application needs a new database.»

If your problem is:

«"Find the most relevant information for this question."»

Vector search may be exactly the right tool.

Where RAG works extremely well

Consider a customer support assistant.

The company has:

• Product documentation

• FAQs

• Help articles

• Troubleshooting guides

A user asks:

«"How do I reset my account password?"»

The system searches the documentation and retrieves the relevant instructions.

The LLM generates a helpful response.

This is a perfect use case for RAG.

The information is relatively straightforward.

The primary problem is retrieval.

The system needs to answer:

«Which documents are relevant to this question?»

A vector database can solve that efficiently.

There is no need to create a complicated knowledge infrastructure when simple retrieval already solves the problem.

This distinction matters.

AIKOQL should not exist just because a different technology can be built.

It should exist only if it solves a different problem.

The problem starts when retrieval becomes memory

Now imagine a different type of AI system.

Instead of a customer support assistant, imagine an AI agent operating over a long period of time.

The agent interacts with:

• Documents

• APIs

• Source code

• Logs

• Databases

• Other agents

• Users

Over time, the agent learns things.

For example:

«The Payment Service depends on the Authentication Service.»

Later:

«The Authentication Service was migrated to a new cluster.»

Then:

«The Payment Service experienced latency after the migration.»

Later still:

«Investigation showed that the migration was unrelated to the latency.»

Now the AI system has accumulated information over time.

Some of that information is:

• Current

• Historical

• Verified

• Unverified

• Contradicted

• Invalidated

This is where semantic retrieval alone begins to face a different problem.

The question is no longer simply:

«Which information is similar to my query?»

The AI system may need to ask:

«What do I currently know?»

And:

«Which of that knowledge should I trust?»

Similarity does not understand truth

Consider two pieces of information.

Knowledge A

«The Payment Service uses PostgreSQL.»

Source: Architecture document Date: January 2026 State: Superseded

Knowledge B

«The Payment Service uses CockroachDB.»

Source: Production configuration Date: August 2026 State: Verified

Now imagine the query:

«What database does the Payment Service use?»

Both pieces of information are highly relevant.

In fact, the older information may be more semantically similar to the wording of the query.

A vector search engine is doing exactly what it was designed to do.

It finds similar content.

But semantic similarity does not automatically understand:

• Which information is current

• Which information was superseded

• Which source is authoritative

• Which claim has stronger evidence

Those decisions are usually handled somewhere else.

And that "somewhere else" is where application complexity starts growing.

The application layer starts doing the hard work

A modern RAG system can quickly evolve into something like this:

Step 1: Search for semantically relevant chunks.

Step 2: Filter by metadata.

Step 3: Check timestamps.

Step 4: Remove outdated information.

Step 5: Look up relationships.

Step 6: Retrieve supporting documents.

Step 7: Rank sources.

Step 8: Build context for the LLM.

None of these steps are inherently wrong.

In fact, they are common engineering patterns.

But as the system becomes more sophisticated, an interesting question emerges:

«Should every AI application independently rebuild knowledge management logic?»

Or could some of those concepts become infrastructure primitives?

This is one of the questions behind AIKOQL.

Vector search answers a different question

A simplified way to think about vector search is:

«What information is most similar to this query?»

That is a powerful question.

But persistent AI systems may also need to ask:

«What do we know about this entity?»

«What knowledge is currently valid?»

«What evidence supports this claim?»

«What changed after this event?»

«What conclusions were invalidated?»

«What knowledge depends on this source?»

«What information contradicts this claim?»

These are not necessarily better questions.

They are different questions.

And they require different primitives.

That distinction is important.

«AIKOQL is not trying to make semantic retrieval obsolete.»

It is exploring what happens when semantic retrieval is only one part of a broader knowledge system.

A chunk is not the same as knowledge

This distinction became clearer to me while exploring document ingestion.

Consider a chunk of text:

«The Payment Service uses PostgreSQL as its primary database. It depends on the Authentication Service for identity verification.»

A vector database can store this chunk and retrieve it effectively.

But inside that chunk are multiple pieces of knowledge.

• Payment Service uses PostgreSQL.

• Payment Service depends on Authentication Service.

Those are relationships.

They can potentially be queried independently.

The same information could appear in other documents.

A new document might say:

«Payment Service migrated from PostgreSQL to CockroachDB.»

Now the system has a temporal relationship between pieces of knowledge.

The problem is no longer simply storing text.

The system needs to understand that:

• PostgreSQL was previously used.

• CockroachDB is currently used.

• A migration occurred.

• The new knowledge may supersede the old knowledge.

This is where the idea of a Knowledge Object begins to differ from a chunk.

AIKOQL is exploring knowledge as a first-class object

A chunk is usually optimized for retrieval.

A Knowledge Object is intended to represent something the system knows.

Conceptually, a Knowledge Object may include:

• Identity

• Content

• Relationships

• Evidence

• Provenance

• Time

• Knowledge state

For example:

«Knowledge: Payment Service uses CockroachDB.»

The system may also understand:

State: Verified

Valid From: August 2026

Evidence: Production configuration

Source: Infrastructure repository

Previous Knowledge: Payment Service uses PostgreSQL

This allows the information to participate in different types of queries.

Not just:

«Find text similar to this.»

But potentially:

«What database does the Payment Service currently use?»

Or:

«What database did it use before August 2026?»

Or:

«Why do we believe the current database is CockroachDB?»

Or:

«Show me the evidence.»

That is the difference I am exploring.

The difficult problem is knowledge evolution

Information changes constantly.

This is one of the biggest differences between static document retrieval and long-running knowledge systems.

Imagine a company updates its architecture.

An old document says:

«PostgreSQL»

A newer document says:

«CockroachDB»

A naive system might simply store both documents.

The AI retrieves whichever one appears most relevant.

A more sophisticated RAG system might add metadata filters.

That helps.

But the deeper question remains:

«What is the relationship between these two pieces of information?»

One possibility is:

«The newer information supersedes the older information.»

That relationship itself is knowledge.

Now the system can preserve history without confusing current retrieval.

The old information does not need to disappear.

It simply has a different state.

«Historical knowledge can remain useful without being treated as current knowledge.»

This is a core concept behind AIKOQL's exploration.

What vector databases are not designed to solve

This needs to be stated carefully.

Vector databases can support metadata.

They can work alongside other databases.

They can be part of sophisticated knowledge architectures.

So this is not a claim that vector databases cannot participate in these systems.

The question is about their primary abstraction.

Vector databases are primarily designed around:

«Representing and retrieving high-dimensional vectors efficiently.»

That makes them excellent at similarity search.

But a persistent knowledge system may also need first-class concepts for:

• Knowledge identity

• Evidence

• Provenance

• Temporal validity

• Contradiction

• Supersession

• Relationships

• Lifecycle

These capabilities can absolutely be built around a vector database.

The question AIKOQL is exploring is:

«What if those concepts were part of the infrastructure itself?»

That is a different architectural direction.

The goal is not one database to rule everything

There is a temptation in infrastructure projects to claim:

«"This replaces everything."»

That is rarely realistic.

AIKOQL does not need to replace:

• PostgreSQL

• ClickHouse

• Neo4j

• Elasticsearch

• Vector databases

These systems solve different problems and have years of engineering behind them.

A more realistic architecture may eventually look like a combination of specialized systems.

For example:

Relational databases for transactional application data.

Vector indexes for semantic similarity.

Search engines for text retrieval.

Graph capabilities for complex relationships.

AIKOQL for managing persistent knowledge objects and their lifecycle.

The important question is not:

«Which database wins?»

The question is:

«Which layer should own which responsibility?»

That is a much healthier way to think about infrastructure.

AIKOQL may use semantic search too

Another important point.

Semantic retrieval is useful.

There is no reason knowledge infrastructure should ignore it.

Imagine an AI agent asking:

«What do we know about the authentication migration?»

The system may need semantic search to discover relevant knowledge.

But once relevant knowledge is discovered, other dimensions can influence what is returned.

For example:

1. Find semantically related knowledge.

2. Prefer currently valid information.

3. Prioritize verified claims.

4. Include supporting evidence.

5. Exclude invalidated conclusions.

6. Preserve historical context when requested.

Semantic similarity becomes one signal.

Not the only signal.

This is the architectural direction I find interesting.

Retrieval and knowledge can work together

I increasingly think the comparison should not be:

«Vector Database vs AIKOQL»

A more useful model may be:

«Semantic Retrieval + Knowledge Infrastructure»

One layer helps answer:

«What information might be relevant?»

Another layer helps answer:

«What does the system know about it?»

These responsibilities can complement each other.

For example:

Semantic retrieval

Finds relevant information about an entity or concept.

Knowledge layer

Understands:

• Identity

• State

• Relationships

• Evidence

• Time

• History

AI agent

Uses the resulting knowledge to reason and act.

The agent does not need to manually reconstruct all of this context every time.

At least, that is one of the hypotheses AIKOQL is exploring.

Where vector databases may be enough

It is equally important to understand where AIKOQL may not be necessary.

You probably do not need a persistent knowledge infrastructure when:

• Your data is mostly static.

• You only need semantic search.

• Documents do not significantly contradict each other.

• Historical state does not matter.

• The application does not require knowledge lineage.

• You are building a straightforward RAG assistant.

For example:

«"Answer questions from our product documentation."»

A vector database may be perfect.

Simple architecture is often better architecture.

There is no prize for adding unnecessary infrastructure.

When the problem starts becoming more complex

AIKOQL becomes more interesting when the system needs to deal with:

Knowledge that changes

Information can become outdated or superseded.

Knowledge from multiple sources

Different systems may provide conflicting information.

Long-running AI agents

Agents accumulate observations and experience over time.

Evidence and provenance

The system needs to explain why it believes something.

Historical questions

The answer depends on a particular point in time.

Contradictions

The system needs to represent disagreement explicitly.

Relationships

Information is connected across entities and sources.

At that point, retrieval alone may no longer be the complete problem.

The application is starting to manage knowledge.

And that is the infrastructure layer AIKOQL is exploring.

The real challenge is trust

The deeper I go into this project, the more I think the problem is ultimately about trust.

An AI system can retrieve information.

But can it understand:

«Why should I trust this information?»

A useful answer may depend on:

• Where the information came from

• When it was created

• Whether it was verified

• Whether newer information replaced it

• Whether evidence supports it

• Whether other knowledge contradicts it

This is not a problem that semantic similarity can solve by itself.

Similarity tells us:

«These pieces of information are related.»

Knowledge infrastructure may need to answer:

«Which one should influence a decision?»

That is a much harder problem.

And I believe it will become increasingly important as AI systems become more autonomous.

RAG is not the end of the architecture

RAG was a major step forward.

It gave AI systems access to information beyond their training data.

But I don't think RAG is necessarily the final architecture for AI knowledge.

A typical RAG system answers:

«What relevant information can we retrieve right now?»

Persistent AI systems may eventually need to answer:

«What have we learned over time?»

«What changed?»

«What was proven wrong?»

«What evidence supports our current understanding?»

«What knowledge should survive beyond a single conversation?»

These questions suggest that AI memory and AI knowledge may eventually require deeper infrastructure.

Not necessarily instead of RAG.

But beyond RAG.

What AIKOQL is actually trying to explore

I want to be clear about the scope.

AIKOQL is not claiming to have solved all of these problems.

The project is exploring a set of questions:

«Can knowledge become a first-class storage primitive?»

«Can AI systems explicitly represent knowledge state?»

«Can evidence and provenance become queryable infrastructure?»

«Can historical knowledge coexist with current knowledge?»

«Can contradictions become explicit instead of remaining hidden inside documents?»

«Can semantic retrieval become one part of a broader knowledge query system?»

These are engineering questions.

And they need to be tested through implementation.

Benchmarks.

Failures.

Real workloads.

That is ultimately what will determine whether the abstractions are useful.

The way I currently see the landscape

I don't see the future as a battle between databases.

I see a growing infrastructure stack.

At one level:

«Data»

Transactional systems and analytical databases.

At another:

«Information»

Documents, search indexes, files, and APIs.

At another:

«Semantic retrieval»

Embeddings and vector search.

And potentially another layer:

«Persistent knowledge»

Where information can have:

• Identity

• Context

• Evidence

• Relationships

• Time

• State

• History

AIKOQL is exploring that last layer.

Not as a replacement for everything below it.

But as infrastructure for problems that emerge above them.

The biggest question

The most important question may not be:

«"Can we build another database?"»

The question is:

«As AI systems become more persistent, what kind of memory will they need?»

A collection of documents?

A vector store?

A graph?

A database?

Probably some combination.

But perhaps there is also room for a new abstraction.

One designed specifically around the lifecycle of knowledge.

That is the space AIKOQL is exploring.

And I think the answer will come from building, testing, and discovering where the abstraction actually helps.

Final thoughts

Vector databases changed what AI applications can do.

They made semantic retrieval practical at scale.

RAG made it easier to ground AI responses in external information.

Those are significant achievements.

But as AI systems evolve from:

«Answering questions»

to:

«Remembering information»

to:

«Maintaining long-term context»

to:

«Making decisions»

the infrastructure requirements may also evolve.

Retrieval is important.

But retrieval alone does not tell us:

«What is true?»

«What changed?»

«What was replaced?»

«What evidence supports this?»

«What should the AI trust?»

AIKOQL is exploring whether knowledge itself should become an infrastructure layer.

Not instead of vector databases.

Not instead of RAG.

But for the problems that begin when retrieval is no longer enough.

«Vector databases help AI find information.»

«AIKOQL is exploring how AI systems can maintain what they know.»

That distinction is the foundation of the project.

What comes next?

The next post will move from concepts into something more practical:

Can AIKOQL Work Alongside PostgreSQL, Vector Databases, and Knowledge Graphs?

Rather than comparing technologies as competitors, I want to explore a realistic AI infrastructure stack.

Where should:

• PostgreSQL live?

• Where does vector search fit?

• When are graph relationships useful?

• What role could AIKOQL play?

Because I believe the future of AI infrastructure is unlikely to be one database replacing everything.

It will probably be about better boundaries between different systems.

And knowing which layer should own which responsibility.

AIKOQL is an evolving open project exploring persistent, structured, and context-aware knowledge infrastructure for AI systems. The ideas discussed here represent the current direction of exploration and will continue to evolve through implementation, testing, benchmarking, and real-world workloads.

What do you think?

«Is semantic retrieval enough for long-running AI systems, or do you think AI applications will eventually need a dedicated knowledge layer that understands evidence, history, relationships, and change?»

PDFs.

Markdown files.

Wiki pages.

GitHub repositories.

Support tickets.

Logs.

Architecture documents.

Chat conversations.

The usual pipeline looks familiar:

«Upload documents → Split them into chunks → Create embeddings → Store vectors → Retrieve relevant chunks»

This approach has made RAG practical.

And for many applications, it works well.

But while building AIKOQL, I keep coming back to a question:

«When does information inside a document become knowledge?»

A document is not knowledge.

A chunk is not knowledge.

An embedding is not knowledge.

They are all representations of information.

Knowledge, at least in the direction I am exploring with AIKOQL, needs something more.

It needs identity.

Context.

Relationships.

Evidence.

Time.

And eventually, a lifecycle.

This post explores what that transformation could look like.

A document is not a knowledge base

Consider a simple architecture document.

It contains the following sentence:

«The Payment Service uses PostgreSQL as its primary database.»

A traditional RAG pipeline might process it like this:

1. Read the document.

2. Split it into chunks.

3. Generate embeddings.

4. Store the chunks.

5. Retrieve them when someone asks about the Payment Service.

The stored representation might conceptually look like this:

Chunk #4821

Content: "The Payment Service uses PostgreSQL as its primary database."

Source: architecture.md

Embedding: [0.018, -0.42, ...]

This is useful.

If someone asks:

«What database does the Payment Service use?»

Semantic search may retrieve the chunk.

The LLM can generate an answer.

But now consider what the system actually knows.

Does it know:

• What the Payment Service is?

• What PostgreSQL represents?

• Whether this information is still current?

• When this statement became valid?

• Whether another document contradicts it?

• Which source supports it?

• Whether the information was verified?

Not necessarily.

The system has information.

But it may not yet have structured knowledge.

The problem with chunks

Chunks are primarily created for retrieval efficiency.

They are not necessarily meaningful units of knowledge.

For example, imagine this document:

«The Payment Service processes transactions. It depends on the Authentication Service for identity verification. Transaction data is stored in PostgreSQL. The service was migrated from MongoDB in June 2026.»

Depending on chunking strategy, the system may create:

Chunk 1

«The Payment Service processes transactions. It depends on the Authentication Service for identity verification.»

Chunk 2

«Transaction data is stored in PostgreSQL. The service was migrated from MongoDB in June 2026.»

The information has now been divided based on size, token limits, or chunking rules.

But knowledge does not necessarily follow chunk boundaries.

There are multiple distinct pieces of knowledge here:

• Payment Service processes transactions.

• Payment Service depends on Authentication Service.

• Payment Service stores transaction data in PostgreSQL.

• The service previously used MongoDB.

• A migration occurred in June 2026.

A chunk may contain several knowledge statements.

Or one knowledge statement may span multiple chunks.

This is one reason I think:

«Chunks are a retrieval strategy, not a knowledge model.»

The first transformation: identifying a knowledge claim

The first step in transforming information into knowledge may be identifying meaningful claims.

Consider this sentence:

«The Payment Service uses PostgreSQL as its primary database.»

The system can identify a claim:

Subject: Payment Service

Relationship: USES

Object: PostgreSQL

Now the information is no longer simply text.

It has structure.

We can ask:

«What does the Payment Service use?»

Or:

«Which services use PostgreSQL?»

Or:

«What databases are connected to the Payment Service?»

The same information can now participate in structured queries and relationships.

This is an important transition.

From:

«Text containing information»

To:

«A representation of a claim about something»

Knowledge extraction is not the same as summarization

AI systems are already good at summarizing documents.

But summarization and knowledge extraction are different.

A summary might say:

«The Payment Service handles transactions and relies on PostgreSQL for storage.»

That is useful for a human.

But the system may still not understand the underlying structure.

Knowledge extraction attempts to identify the individual concepts and relationships.

For example:

Knowledge Claim 1

Payment Service

"PROCESSES"

Transactions

Knowledge Claim 2

Payment Service

"USES"

PostgreSQL

Knowledge Claim 3

Payment Service

"DEPENDS_ON"

Authentication Service

Each claim can now become independently addressable.

This is where the idea of a Knowledge Object becomes interesting.

What is a Knowledge Object?

The simplest way I currently think about a Knowledge Object is:

«A persistent representation of something the system knows, along with the context needed to understand that knowledge.»

A Knowledge Object may contain:

• The knowledge itself

• Identity

• Relationships

• Evidence

• Provenance

• Time

• State

For example:

Knowledge Object

Statement: Payment Service uses PostgreSQL

Relationship: Payment Service → USES → PostgreSQL

State: Observed

Source: Architecture Document

Evidence: Section 3.2

Observed At: 2026-09-03

This is much richer than a chunk.

But it is important not to confuse richer representation with truth.

The system has extracted a claim.

That does not automatically mean the claim is correct.

This is where knowledge state becomes important.

Extraction should create observations, not instant truth

Imagine an AI model processes a document and extracts:

«The Payment Service uses PostgreSQL.»

Should the system immediately mark this as verified knowledge?

Probably not.

The model may have:

• Misinterpreted the document.

• Read outdated information.

• Extracted an ambiguous statement.

• Confused a planned architecture with the current architecture.

A safer approach may be:

«Extraction creates an observation or assertion.»

For example:

Knowledge: Payment Service uses PostgreSQL

State: Observed

Source: Architecture Document

The system can then evolve the knowledge based on additional information.

This distinction becomes particularly important when AI agents generate knowledge automatically.

«AI-generated information should not automatically become AI-trusted knowledge.»

Evidence should stay connected to knowledge

One of the biggest problems with extracted information is losing the original context.

Imagine an AI system stores:

«The Payment Service uses PostgreSQL.»

Six months later, someone asks:

«Where did this information come from?»

If the answer is simply:

«We extracted it from a document.»

That is not very useful.

A better system should preserve the evidence.

For example:

Knowledge: Payment Service uses PostgreSQL

Supported By: Architecture Document

Location: Database Architecture section

Source Version: v1.8

Extracted At: September 2026

Now the system can potentially trace the claim back to its origin.

This becomes important when:

• The source changes.

• The source is deleted.

• A new document contradicts it.

• Someone questions the claim.

• The AI needs to explain its answer.

Evidence gives knowledge something information retrieval alone often loses:

«Traceability.»

Provenance answers: where did this come from?

Evidence tells us what supports a claim.

Provenance tells us where the knowledge came from.

Imagine the following chain:

Architecture Document

    ↓

Section: Database Layer

    ↓

Extracted Claim

    ↓

Knowledge Object

The system can preserve this lineage.

Now imagine the original document is updated.

The architecture section changes from:

«PostgreSQL»

to:

«CockroachDB»

The system can identify knowledge that originated from the old version.

That creates an interesting possibility.

Instead of treating knowledge as permanent, the system can ask:

«Which Knowledge Objects may be affected by this source change?»

This is where persistent knowledge starts becoming dynamic infrastructure.

A source change should not simply overwrite knowledge

Suppose an architecture document is updated.

Yesterday:

«The Payment Service uses PostgreSQL.»

Today:

«The Payment Service uses CockroachDB.»

A simple ingestion system might delete the old chunk and insert the new chunk.

But something valuable is lost.

The old information may still be historically correct.

A knowledge-aware system could instead preserve the evolution.

Previous Knowledge

«Payment Service uses PostgreSQL.»

State:

Superseded

Current Knowledge

«Payment Service uses CockroachDB.»

State:

Current

The relationship between the two is also meaningful.

The new knowledge may:

«SUPERSEDE»

the previous knowledge.

This is where document ingestion connects directly to knowledge lifecycle.

From extraction to knowledge requires identity

One of the challenges with documents is that the same concept can appear in many different forms.

For example:

«Payment Service»

«Payment API»

«Payments Platform»

«Transaction Processing Service»

Are these different systems?

Or different names for the same system?

A knowledge system eventually needs to deal with identity.

Consider two documents.

Document A says:

«Payment Service uses PostgreSQL.»

Document B says:

«Payments Platform migrated to CockroachDB.»

Before deciding whether these statements contradict each other, the system may need to determine:

«Are Payment Service and Payments Platform the same entity?»

Identity resolution becomes important.

Without it, the knowledge base may become a collection of disconnected facts.

With identity, information can start accumulating around entities.

For example:

Payment Service

Known As: Payment API Payments Platform

Relationships: Uses → PostgreSQL Uses → CockroachDB Depends On → Authentication Service Processes → Transactions

Now the system can begin understanding that different pieces of information refer to the same thing.

Relationships are discovered during ingestion

Documents often contain hidden relationships.

Consider:

«The Payment Service depends on the Authentication Service.»

This sentence contains at least two entities.

• Payment Service

• Authentication Service

And a relationship:

«DEPENDS_ON»

Once extracted, that relationship becomes queryable.

Later, another document might say:

«The Authentication Service depends on Redis.»

Now the system can connect the information.

An AI agent asking:

«What infrastructure does the Payment Service depend on?»

may eventually discover:

• Authentication Service

• Redis

The answer requires more than retrieving one chunk.

It requires relationships between pieces of knowledge.

This is one of the reasons I see ingestion as more than:

«Upload → Embed → Store»

It may eventually become:

«Extract → Identify → Connect → Preserve → Evolve»

Not every piece of information deserves to become knowledge

This is another question I think is important.

Should everything extracted from a document become a persistent Knowledge Object?

Probably not.

Consider a sentence like:

«This document was last updated on Tuesday.»

Or:

«The author prefers dark mode.»

Or:

«Please review this section before publication.»

Some information may be:

• Temporary

• Irrelevant

• Context-specific

• Low value

• Procedural

A knowledge system needs some notion of selection.

This could involve:

• Extraction rules

• Confidence

• Source importance

• Entity relevance

• Application context

The goal is not necessarily to store everything as permanent knowledge.

Otherwise, the system may create a different problem:

«An enormous collection of information with no meaningful structure.»

Knowledge infrastructure should ideally help reduce noise, not preserve it forever.

Confidence is useful, but confidence is not truth

AI extraction systems often produce confidence scores.

For example:

Claim: Payment Service uses PostgreSQL

Confidence: 0.94

That can be useful.

But confidence should not be confused with correctness.

The model may be very confident and completely wrong.

This is why I think confidence should be only one part of the knowledge model.

Other dimensions may include:

• Source authority

• Evidence quality

• Independent confirmation

• Temporal validity

• Contradiction

• Verification state

A better question may not be:

«How confident was the model?»

But:

«Why should the system believe this information?»

That is a much more difficult problem.

And it cannot be solved with a single score.

Multiple sources can strengthen knowledge

Imagine three independent sources.

Architecture Document

«Payment Service uses CockroachDB.»

Deployment Configuration

«Database engine: CockroachDB»

Production Monitoring

«CockroachDB connection metrics detected.»

Individually, each source provides evidence.

Together, they create stronger support.

A Knowledge Object might now have:

Knowledge: Payment Service uses CockroachDB

Evidence: 3 independent sources

State: Verified

This creates another interesting possibility.

Knowledge can become stronger as supporting evidence accumulates.

The system does not simply store a fact.

It stores the history of why that fact is believed.

Contradictions should trigger investigation

Now imagine a new document appears.

«Payment Service uses PostgreSQL.»

But the existing verified knowledge says:

«Payment Service uses CockroachDB.»

A simple retrieval system stores both.

A knowledge-aware ingestion process could detect a potential conflict.

But detecting a contradiction does not mean immediately rejecting the new information.

The new document may be:

• Historical

• Outdated

• Referring to another environment

• Incorrect

• More recent than existing information

The system needs context.

For example:

Claim A: Payment Service uses PostgreSQL

Source Date: March 2026

Claim B: Payment Service uses CockroachDB

Source Date: August 2026

Now the contradiction may actually represent evolution.

Time resolves the conflict.

This is why ingestion, identity, relationships, time, and lifecycle cannot really be treated as isolated features.

They influence each other.

The transformation is iterative

One mistake would be to imagine a perfect pipeline.

Something like:

«Document → Knowledge»

In reality, the transformation is likely iterative.

A more realistic process may look like this:

1. Information is discovered

A document, event, conversation, repository, or API produces information.

1. Potential claims are extracted

The system identifies statements that may represent useful knowledge.

1. Entities are identified

The system attempts to understand what the information refers to.

1. Relationships are extracted

Connections between entities and knowledge are identified.

1. Evidence is preserved

The system retains the original context and source.

1. Knowledge is compared

The new information is compared with existing knowledge.

1. State evolves

The knowledge may remain observed, become verified, be contradicted, or supersede existing knowledge.

This is not a one-time operation.

Knowledge continues to evolve.

The same information can produce different knowledge

Context matters.

Consider this sentence:

«PostgreSQL is the primary database for the Payment Service.»

In one context, this might represent:

«Current production architecture.»

In another:

«Historical architecture documentation.»

In another:

«A planned but never deployed design.»

The text may look almost identical.

The meaning is different.

This is why extracting text alone is not enough.

The system needs to understand context such as:

• Source

• Time

• Environment

• Document version

• Surrounding information

The same sentence can represent different knowledge depending on where and when it was observed.

Knowledge ingestion is a systems problem

At this point, document ingestion begins to look less like a simple AI pipeline.

It becomes an infrastructure problem.

The system may need to manage:

• Large numbers of sources

• Duplicate information

• Conflicting claims

• Entity resolution

• Source versions

• Evidence relationships

• Knowledge updates

• Historical knowledge

• Concurrent ingestion

This is one reason AIKOQL is interesting to me as a systems project.

The challenge is not simply:

«Can an LLM extract information from a document?»

We already know that it can.

The harder question is:

«What happens after extraction?»

Where does that information live?

How is it identified?

How is it connected?

How does it evolve?

How does it remain trustworthy over time?

That is where persistent knowledge infrastructure begins.

From documents to knowledge infrastructure

The transformation I am exploring can be summarized simply:

«Documents contain information.»

«Extraction identifies potential knowledge.»

«Knowledge Objects preserve that information with context.»

«Evidence explains why the knowledge exists.»

«Relationships connect knowledge.»

«Time explains when it was relevant.»

«Lifecycle explains how it evolved.»

The final goal is not simply a smarter document store.

The goal is to explore whether information can become part of a persistent knowledge system.

A system where an AI agent can eventually ask:

«What do we know about this?»

And receive more than similar chunks.

It could receive knowledge with:

• Context

• Evidence

• State

• History

• Relationships

That is the direction I believe is worth exploring.

What this means for AI agents

This becomes particularly interesting when AI agents are involved.

An agent may continuously receive information from:

• APIs

• Logs

• Documents

• Conversations

• Other agents

• Tools

Without structure, the agent's memory can quickly become a large collection of disconnected observations.

The agent may remember:

«Something happened.»

But not necessarily:

«What happened?»

«Why did we believe it?»

«Did anything later contradict it?»

«Is it still relevant?»

Persistent knowledge infrastructure could potentially give agents a more disciplined memory model.

Instead of simply storing:

«Information I encountered»

the agent can build:

«Knowledge I observed, tested, supported, rejected, and evolved.»

That distinction may become increasingly important as agents operate for longer periods.

The question I am exploring with AIKOQL

The document-to-knowledge pipeline raises a fundamental question.

«Should AI infrastructure treat documents as the final unit of knowledge?»

Or are documents simply one source from which knowledge can emerge?

I believe the second possibility is worth exploring.

Documents are important.

Chunks are useful.

Embeddings are powerful.

Vector search is valuable.

But none of them alone answer:

«What does the system actually know?»

That question requires another layer.

A layer where information can become:

• Identified

• Connected

• Supported

• Time-aware

• State-aware

• Persistent

That is the idea behind the Knowledge Object.

And it is one of the core ideas I am continuing to explore with AIKOQL.

What comes next?

So far, this series has explored:

• Why AI-native infrastructure may need new abstractions

• Knowledge Objects

• Knowledge architecture

• Relationships and provenance

• Knowledge lifecycle

• Evidence, contradiction, and time

• Querying knowledge

• Transforming documents into knowledge

The next question is unavoidable:

«How does AIKOQL actually compare with the tools we already use?»

Because AIKOQL does not exist in isolation.

We already have:

• Relational databases

• Document databases

• Graph databases

• Vector databases

• Search engines

• RAG frameworks

The next post will explore:

Why Not Just Use a Vector Database? The Case for Knowledge Infrastructure Beyond RAG

I want to look honestly at where vector databases are excellent, where RAG is enough, and where a more persistent knowledge model may become useful.

Because the goal is not to replace every database.

The goal is to understand which problems existing systems already solve well — and which problems still need new infrastructure.

AIKOQL is an evolving open project exploring persistent and context-aware knowledge infrastructure for AI systems. The concepts discussed in this article represent the current direction of exploration and will continue to evolve through implementation, testing, and real-world workloads.

What do you think?

«When an AI system reads a document, should it primarily remember the document itself — or should it extract and maintain the knowledge contained inside it?»

But there is an obvious next question.

«If knowledge has its own structure, state, history, and relationships — how should we query it?»

This question is becoming increasingly interesting to me as AIKOQL evolves.

We already have powerful ways to query data.

SQL changed how applications interact with structured data.

Graph query languages made relationships easier to explore.

Search engines made text discoverable.

Vector search introduced semantic similarity as another retrieval primitive.

Each solves an important problem.

But AI applications are increasingly asking questions that sit somewhere between all of them.

For example:

«What do we currently know about this system?»

«What evidence supports this conclusion?»

«Is this information still valid?»

«What changed after the last deployment?»

«Show me knowledge derived from this document.»

«Are there conflicting claims about this component?»

These are not purely SQL questions.

They are not purely graph questions.

And semantic similarity alone cannot answer them reliably.

This is the problem I am exploring with AIKOQL.

Data queries and knowledge queries are not always the same

Consider a traditional database query.

SELECT name, database FROM services WHERE name = 'payment-service';

The database returns the current value.

Simple.

Predictable.

Powerful.

Now consider an AI agent asking:

«What database does the Payment Service use?»

At first glance, this appears to be the same question.

But now imagine the system has accumulated knowledge over several years.

It may know that:

• The service previously used PostgreSQL.

• A migration to another database was planned.

• The migration was completed.

• An old architecture document still references PostgreSQL.

• A newer document references the current system.

• One source was later invalidated.

Suddenly, the question becomes more complicated.

The agent is not simply asking:

«What values exist?»

It may actually be asking:

«What is the most reliable and currently valid knowledge about this?»

That difference is important.

Retrieval is easy. Selecting knowledge is harder.

Modern AI systems are already good at retrieving information.

A typical workflow might look like this:

1. Convert a query into an embedding.

2. Search for similar content.

3. Retrieve the top results.

4. Give those results to an LLM.

This works remarkably well for many use cases.

But semantic similarity does not understand whether information is:

• Current

• Historical

• Verified

• Contradicted

• Superseded

• Based on strong evidence

Imagine two pieces of knowledge.

Knowledge A

«The Payment Service uses PostgreSQL.»

Status: Superseded Semantic relevance: Very high

Knowledge B

«The Payment Service uses CockroachDB.»

Status: Verified and current Semantic relevance: Slightly lower

A purely semantic system might rank Knowledge A first.

But is that what the AI agent should see?

Probably not.

«The most relevant information is not always the most useful knowledge.»

This is where I think knowledge-aware querying becomes interesting.

What if knowledge itself becomes queryable?

Imagine if an application could express more than:

Find information related to the Payment Service.

What if it could also express:

Find currently valid knowledge about the Payment Service.

Or:

Find verified knowledge about the Payment Service.

Or:

Find knowledge about the Payment Service and show the supporting evidence.

Or:

Find claims that contradict the current architecture.

These queries are not just about finding content.

They are about querying the properties of knowledge.

That is the direction I am exploring with AIKOQL.

A query needs context

One of the interesting things about AI workloads is that the same question can require different answers depending on context.

Consider this question:

«What database does the Payment Service use?»

For a current architecture assistant, the answer should probably be the current database.

But an engineer investigating an incident from last year may need the historical answer.

The query is the same.

The context is different.

This suggests that knowledge queries may need dimensions beyond simple filtering.

For example:

• Current time

• Historical time

• Knowledge state

• Evidence requirements

• Source authority

• Relationship scope

Instead of asking only:

What matches?

The system may need to ask:

What matches in this context?

That is a subtle but important difference.

Time should influence queries

Let's return to our database example.

The Payment Service used PostgreSQL until June 2026.

After a migration, it moved to CockroachDB.

Now consider two queries.

Query 1

«What database does the Payment Service use today?»

The expected answer:

«CockroachDB»

Query 2

«What database did the Payment Service use during an incident in March 2026?»

The expected answer:

«PostgreSQL»

Both answers can be correct.

The difference is time.

A knowledge-aware query system should be able to treat time as part of the query context.

Conceptually:

Find knowledge about: Payment Service database

Valid at: March 2026

versus:

Find knowledge about: Payment Service database

Valid at: Now

The content may be similar.

But the answer should be different.

«For knowledge systems, “when?” can be just as important as “what?”»

Querying by knowledge state

The lifecycle of knowledge creates another interesting query dimension.

Imagine an AI agent researching a production incident.

The knowledge base contains:

• Verified conclusions

• Unverified hypotheses

• Contradicted claims

• Superseded information

The agent may not want all of them.

For example:

Find incident root causes

State: Verified

Or:

Find all hypotheses

State: Asserted

Or:

Find information about the deployment

Include: Contradicted knowledge

The last query is particularly interesting.

Sometimes an AI agent should avoid contradictory information.

Sometimes contradictory information is exactly what it needs.

For example:

«What explanations were investigated and rejected?»

That query could be extremely useful during debugging or investigation.

The important point is that the application should be able to choose.

Evidence should also be queryable

Imagine an AI agent says:

«The migration was successful.»

That statement alone is not enough for every use case.

Someone may ask:

«Why do you believe that?»

The system should ideally be able to retrieve the evidence.

For example:

Knowledge: Migration completed successfully.

Supported by: Deployment records Database metrics Post-migration validation

Now imagine querying:

«Show me the evidence supporting this conclusion.»

Or:

«Find conclusions supported by this document.»

Or:

«Which knowledge depends on this source?»

These are not traditional document retrieval queries.

They involve traversing relationships between:

• Knowledge

• Evidence

• Sources

• Claims

This is where provenance and querying begin to intersect.

Relationships change what a query can mean

Relationships are one of the most interesting parts of knowledge.

Suppose we know:

«Service A depends on Service B.»

And:

«Service B depends on Database C.»

An AI agent might ask:

«What infrastructure does Service A depend on?»

The answer may require traversing multiple relationships.

Or consider:

«Which knowledge was derived from this architecture document?»

Or:

«What knowledge was superseded by this decision?»

Or:

«What conclusions contradict this claim?»

These questions are relationship queries.

But they are not necessarily generic graph queries.

The relationships have meaning.

For example:

• "DEPENDS_ON"

• "DERIVED_FROM"

• "SUPPORTED_BY"

• "CONTRADICTS"

• "SUPERSEDES"

The meaning of the relationship can influence how knowledge is retrieved and interpreted.

That is why I think relationships should become part of the query model rather than remaining hidden inside application logic.

AI applications may need hybrid queries

One of the strongest ideas behind AIKOQL is that a useful knowledge query may combine multiple retrieval strategies.

Imagine asking:

«What is the current architecture of the Payment Service?»

The system might need to combine:

1. Entity lookup

2. Relationship traversal

3. Temporal filtering

4. Knowledge state filtering

5. Semantic relevance

6. Evidence ranking

That is not a single query primitive.

It is a composition.

Conceptually, the system might reason like this:

Find knowledge about Payment Service

↓

Prefer current knowledge

↓

Exclude invalidated information

↓

Prefer verified claims

↓

Follow architecture relationships

↓

Rank by relevance and evidence

This is where query planning becomes interesting.

The user may express intent at a high level.

The engine eventually needs to decide how to execute it efficiently.

The application should not have to do everything

Today, many applications handle knowledge logic themselves.

The application may need to:

1. Search a vector database.

2. Filter results.

3. Check metadata.

4. Look up relationships.

5. Retrieve source documents.

6. Remove outdated information.

7. Build context for the LLM.

This often leads to increasingly complicated application code.

Something like:

Search

↓

Filter metadata

↓

Check timestamps

↓

Check state

↓

Follow relationships

↓

Retrieve evidence

↓

Build context

The more intelligence required around knowledge, the more this logic grows.

One of the questions AIKOQL is exploring is:

«Can some of this logic move closer to the knowledge infrastructure itself?»

Instead of every AI application independently deciding how to handle:

• Validity

• Evidence

• State

• History

• Relationships

could these become first-class query primitives?

That could allow applications to focus more on what they want to know.

Rather than how to assemble knowledge manually.

Query intent may matter more than query syntax

When we talk about query languages, we often immediately think about syntax.

SQL has syntax.

Graph query languages have syntax.

Search engines have query syntax.

But I think the more important question for AIKOQL is:

«What should a knowledge query be able to express?»

Syntax can evolve.

The primitives are more important.

Some of the concepts I believe an AI-native knowledge query system may need include:

Identity

Find a specific Knowledge Object or entity.

Relationships

Traverse meaningful connections between knowledge.

Time

Query knowledge as it existed at a particular point.

State

Filter based on verification, supersession, contradiction, or validity.

Evidence

Retrieve and evaluate supporting information.

Provenance

Understand where knowledge came from.

Relevance

Find conceptually related information.

The challenge is bringing these dimensions together without creating an unnecessarily complicated query language.

A query language should not expose the complexity of the storage engine

There is another important principle here.

AI applications should not necessarily need to understand:

• Index structures

• Storage layouts

• Internal object representations

• Relationship indexes

• Temporal indexes

Those are implementation concerns.

The application should ideally express intent.

For example:

«Find the current verified knowledge about the Payment Service.»

The engine can then decide:

• Which indexes to use

• How to filter knowledge states

• Whether temporal filtering is required

• Whether relationships should be traversed

• How to rank results

This is similar to one of the most powerful ideas behind declarative databases.

The user says:

«What do I want?»

The engine decides:

«How should I get it?»

I believe this principle remains valuable for AI-native systems.

Could natural language become part of the query interface?

AI introduces another interesting possibility.

An AI agent may not need to write a formal query language directly.

It could express intent in natural language.

For example:

«Show me everything we currently know about this service, but only include information supported by reliable evidence.»

A query system could potentially transform that into a structured query representation.

Conceptually:

Natural Language Request

↓

Structured Knowledge Query

↓

Query Planning

↓

Execution

↓

Knowledge Results

But there is an important distinction here.

Natural language is useful for expressing intent.

The internal query should still become structured.

Why?

Because knowledge infrastructure needs:

• Predictability

• Validation

• Optimization

• Security

• Explainability

An AI agent should not be directly generating arbitrary storage operations without structure.

This suggests an interesting architecture.

«Natural language may be the interface. Structured knowledge queries may be the execution model.»

That is an area I believe deserves much more experimentation.

Explainable queries could matter for AI

Another interesting challenge is explainability.

Suppose an AI agent asks:

«Why did you retrieve this information?»

A traditional retrieval system may simply return a relevance score.

But a knowledge-aware query system could potentially provide more context.

For example:

Selected because:

✓ Semantically relevant

✓ Currently valid

✓ Verified

✓ Supported by recent evidence

Or:

Excluded because:

✕ Superseded

✕ Historical only

✕ Source no longer valid

This could make AI retrieval more transparent.

The agent does not simply receive information.

It receives some understanding of why the information was selected.

That may become increasingly important as AI systems make more autonomous decisions.

Querying knowledge is also a trust problem

The deeper I explore this area, the more I think querying knowledge is not only a retrieval problem.

It is also a trust problem.

Imagine two pieces of information.

Both are highly relevant.

But one comes from:

• A verified production system

• A recent architecture document

• Multiple supporting sources

The other comes from:

• An old document

• An unverified AI-generated inference

• A source that was later invalidated

Should both be ranked equally?

Probably not.

This suggests that a query engine may eventually need to consider something like knowledge quality.

Not necessarily as a single magic score.

But as multiple dimensions.

For example:

• Evidence strength

• Source authority

• Recency

• Knowledge state

• Contradiction

• Temporal validity

This is where knowledge querying becomes much more interesting than simply retrieving the top 10 results.

The difficult part is not creating a language

Designing query syntax is relatively easy.

The difficult part is deciding what semantics should mean.

For example:

«What does “current knowledge” actually mean?»

Does it mean:

• Most recently created?

• Most recently verified?

• Currently valid?

• Not superseded?

• Highest confidence?

Those are different things.

Similarly:

«What does “reliable knowledge” mean?»

Does it mean:

• Verified?

• Supported by multiple sources?

• From an authoritative source?

• Not contradicted?

Again, different interpretations.

This is why I believe the first step is not inventing syntax.

The first step is defining the semantics of knowledge.

The query language should emerge from those semantics.

AIKOQL is exploring the primitives first

At this stage, my focus is not on declaring that AIKOQL has discovered the perfect query language.

It hasn't.

The project is exploring the underlying primitives that a knowledge system may need.

Questions such as:

• What is a Knowledge Object?

• How should knowledge state work?

• How should relationships be represented?

• How should evidence connect to knowledge?

• How should time influence retrieval?

• How should historical knowledge coexist with current knowledge?

• How should query planning work across these dimensions?

The answers to these questions will eventually influence the query model.

And those answers need to be tested against real workloads.

The bigger idea

Traditional databases gave us a powerful abstraction:

«Store data and query it.»

AI-native infrastructure may need another abstraction:

«Store knowledge and query it in context.»

The word context is important.

Because knowledge is rarely useful in isolation.

Its meaning can depend on:

• Time

• Evidence

• Relationships

• Source

• State

• History

An AI system that retrieves information without these dimensions may still work.

But it may not understand what the information represents.

And that difference could become increasingly important as AI systems move from answering questions to making decisions.

What I am trying to learn with AIKOQL

AIKOQL is ultimately an exploration.

Can knowledge become a first-class infrastructure primitive?

Can applications query more than documents and vectors?

Can a system understand that some knowledge is:

• Current

• Historical

• Verified

• Contradicted

• Derived

• Supported

Can those properties influence retrieval?

Can AI agents spend less time assembling context and more time reasoning with it?

I don't think the industry has fully answered these questions yet.

And I certainly don't believe AIKOQL has all the answers.

But I think the questions are worth building toward.

Because as AI systems become more persistent and autonomous, the problem may shift from:

«How do we give an AI model information?»

to:

«How do we manage what an AI system knows?»

And eventually:

«How does an AI system know what it should trust?»

That is where knowledge infrastructure becomes interesting.

What comes next

So far, this series has explored:

• Why AI-native infrastructure may need new abstractions

• Knowledge Objects

• Knowledge architecture

• Relationships and provenance

• Knowledge lifecycle

• Evidence, contradiction, and time

• Querying knowledge in context

The next step should be more practical.

In the next post, I want to explore:

From Documents to Knowledge: How Information Becomes a Knowledge Object

A document is not automatically knowledge.

An embedding is not automatically understanding.

And a chunk of text is not necessarily something an AI agent should remember forever.

The next article will explore the journey from:

Raw Information → Extraction → Knowledge Object → Evidence → Relationships → Persistent Knowledge

And more importantly:

«What should happen when that information changes?»

AIKOQL is an evolving open project exploring the infrastructure needed for persistent, structured, and context-aware knowledge. The query concepts discussed here are part of the project's design exploration and will continue to evolve through implementation, testing, and real-world workloads.

What do you think?

«Should AI applications continue assembling knowledge through separate databases, vector stores, graphs, and application logic — or do you think knowledge itself should eventually become a first-class query primitive?»

A database record is inserted.

Then it is updated.

Eventually, it may be deleted.

But knowledge behaves differently.

A piece of knowledge can be correct at one point in time and incorrect at another.

It can be supported by evidence.

It can be challenged by new information.

It can be replaced by something more accurate.

It can remain historically important even after it is no longer valid.

For AI systems, this distinction matters.

Because an AI agent does not simply need information.

It needs to understand:

«What should I believe right now?»

That question is much harder than retrieving the most relevant document.

And it leads to one of the ideas I believe is central to AI-native knowledge infrastructure:

«Knowledge has a lifecycle.»

This is the direction AIKOQL is exploring.

Data changes. Knowledge evolves.

Consider a traditional database record.

Production Database

engine = PostgreSQL

Later, the company migrates.

UPDATE database SET engine = 'CockroachDB'

The current state is now:

Production Database

engine = CockroachDB

For many applications, this is exactly what we want.

But imagine an AI agent investigating an incident from six months ago.

It asks:

«What database was the Payment Service using when this incident occurred?»

The current record cannot answer that question.

The answer requires history.

Now imagine another question:

«Why did the organization migrate away from PostgreSQL?»

That requires more than history.

It may require:

• Architecture decisions

• Performance measurements

• Migration plans

• Incident reports

• Evidence

• Relationships between decisions and events

The information is no longer simply a changing value.

It has become knowledge with a history.

Knowledge does not simply disappear

Suppose we have this statement:

«The Payment Service uses PostgreSQL.»

At one point, this may be true.

Later, the system migrates.

Now:

«The Payment Service uses CockroachDB.»

The first statement is no longer current.

But should it be deleted?

Probably not.

It may still be useful for:

• Historical analysis

• Incident investigation

• Auditing

• Understanding migrations

• Explaining old decisions

• Reconstructing system state

The better representation may be:

Knowledge #1

Statement: Payment Service uses PostgreSQL

Valid: January 2025 → June 2026

State: Superseded

And:

Knowledge #2

Statement: Payment Service uses CockroachDB

Valid: June 2026 → Present

State: Current

The old knowledge was not necessarily wrong.

It was simply no longer the current representation of reality.

This is an important distinction.

«Superseded does not mean false.»

It means something newer has replaced it for the relevant context.

The lifecycle of knowledge

One of the models I am exploring for AIKOQL looks something like this:

            OBSERVED

                │

                ▼

            ASSERTED

                │

                ▼

            VERIFIED

          ┌─────┴─────┐
          │           │
          ▼           ▼

     CONTRADICTED   SUPERSEDED

          │           │
          └─────┬─────┘
                │
                ▼

            INVALIDATED

This is not necessarily a rigid state machine.

Real knowledge can be more complicated.

But these states help describe something that traditional data models often leave to the application layer.

Let's explore each one.

1. Observed: Something was detected

Knowledge often begins with an observation.

For example:

CPU utilization reached 95%.

This might come from:

• A monitoring system

• A log

• A sensor

• An event

• A document

• An AI agent

At this stage, the system knows that something was observed.

But observation does not automatically mean interpretation.

Consider:

Observed:

CPU utilization reached 95%.

We have not yet concluded:

«The system is unhealthy.»

That is an interpretation.

The distinction matters.

An observation might be:

Event: Deployment completed

Timestamp: 10:30 AM

Source: CI/CD System

The system has captured an event.

It has not yet decided what the event means.

1. Asserted: Someone makes a claim

The next stage might be an assertion.

For example:

«The deployment caused the increase in CPU utilization.»

This is different from the observation.

We now have:

Observation:

CPU utilization increased to 95%.

Assertion:

The deployment caused the increase.

The assertion may come from:

• A human engineer

• An AI agent

• An automated rule

• Another system

But the fact that someone asserted something does not make it true.

This is important for AI systems.

LLMs are very good at generating assertions.

They are not automatically evidence.

An AI agent might conclude:

«The database is the root cause.»

That should not immediately become verified knowledge.

Instead:

Knowledge State:

Asserted

The claim exists.

Its status is explicit.

1. Verified: Knowledge supported by evidence

A claim becomes more useful when it is supported.

For example:

Assertion:

The deployment caused the CPU spike.

Now the system finds:

Evidence:

CPU increased immediately after deployment.

AND

Rollback restored normal CPU utilization.

The knowledge may now move toward:

State:

Verified

But verification itself can be contextual.

Who verified it?

What evidence was used?

How authoritative was the evidence?

Was it independently confirmed?

A useful knowledge representation might look like:

Knowledge:

Deployment caused CPU spike.

State:

Verified

Evidence:

Monitoring metrics Deployment event Rollback event

Verified By:

Operations Team

Verified At:

2026-09-02

The important idea is not simply storing a boolean:

verified = true

The system should ideally understand:

«Why is this knowledge considered verified?»

Evidence is part of the knowledge.

Evidence should be connected, not copied

Imagine a Knowledge Object:

Knowledge:

The Payment Service has a 99.9% SLA.

The system could simply store:

evidence = "Architecture Document"

But that loses detail.

A stronger model may connect knowledge to specific evidence.

Knowledge Object

  │

  ▼

SUPPORTED_BY

  │

  ▼

Evidence Object

  │

  ├── Source Document
  │
  ├── Section
  │
  ├── Table
  │
  └── Timestamp

This allows questions such as:

«What evidence supports this?»

«Is the evidence still current?»

«Has the source changed?»

«Does another source disagree?»

The evidence itself can therefore have a lifecycle.

This is where knowledge infrastructure becomes recursive.

Knowledge is connected to evidence.

Evidence has provenance.

Provenance can change.

Sources can become outdated.

The system needs to preserve those relationships.

1. Contradicted: Knowledge meets conflicting information

One of the most important states for AI systems may be contradiction.

Imagine two sources.

Source A:

«The Payment Service uses PostgreSQL.»

Source B:

«The Payment Service uses CockroachDB.»

A naive retrieval system may simply return both documents.

The LLM receives conflicting context.

Then we hope the model resolves it correctly.

But the system itself knows something important:

«These statements conflict.»

That conflict should potentially become explicit.

Knowledge A

Payment Service USES PostgreSQL

    │

    │ CONTRADICTS

    ▼

Knowledge B

Payment Service USES CockroachDB

Now contradiction is not hidden inside retrieved text.

It becomes part of the knowledge model.

This allows an AI agent to ask:

«Is there conflicting knowledge about this entity?»

Or:

«What information challenges this conclusion?»

That is a much stronger capability than simply retrieving similar chunks.

Contradictions are not always errors

This is important.

A contradiction does not necessarily mean one source is wrong.

Consider:

Document A:

Production database is PostgreSQL.

Date: January 2026

And:

Document B:

Production database is CockroachDB.

Date: August 2026

These statements appear contradictory.

But they may both be historically correct.

The missing dimension is time.

This is why:

«Contradiction without temporal context can be misleading.»

The system needs to ask:

What was true?

When was it true?

A knowledge model that understands only content may treat these statements as conflicting.

A temporal knowledge model can understand:

January 2026:

PostgreSQL

and:

August 2026:

CockroachDB

as an evolution.

This is where contradiction and time become deeply connected.

1. Superseded: New knowledge replaces old knowledge

Supersession is different from contradiction.

Consider:

Knowledge A:

Payment Service uses PostgreSQL.

Later:

Knowledge B:

Payment Service uses CockroachDB.

If Knowledge B represents a migration that replaced the previous state:

Knowledge B

  │

  │ SUPERSEDES

  ▼

Knowledge A

The old knowledge remains historically useful.

But retrieval for current context should prefer:

Knowledge B

This creates an important rule for AI systems.

«Current relevance is not the same as semantic relevance.»

A vector search might consider both statements highly relevant.

But a knowledge-aware system should be able to distinguish:

Current Knowledge

from:

Historical Knowledge

The relationship between the two matters.

1. Invalidated: Knowledge is determined to be false or unusable

Superseded knowledge may still have been correct.

Invalidated knowledge is different.

For example:

Assertion:

Database migration completed successfully.

Later, investigation reveals:

The migration did not complete.

The monitoring event was incorrect.

The original assertion may now become:

State:

Invalidated

The knowledge is preserved.

But it should not be used as reliable context.

This distinction is especially important for AI-generated knowledge.

An AI system may infer something incorrectly.

Instead of silently deleting the inference, we can preserve:

Knowledge:

Deployment caused database failure.

State:

Invalidated

Reason:

Root cause investigation found configuration error.

This creates historical traceability.

The system can understand:

«What was previously believed?»

and:

«Why was that belief rejected?»

That can become extremely valuable for long-running AI systems.

Time is not metadata

One of the biggest ideas behind knowledge lifecycle is that time should not always be treated as an optional metadata field.

Consider:

created_at updated_at

These fields tell us when a database record changed.

But knowledge may require different time dimensions.

For example:

Observed At

When was this information observed?

Asserted At

When was the claim made?

Valid From

When did this knowledge become valid?

Valid Until

When did it stop being valid?

Verified At

When was it verified?

These timestamps describe different events.

Consider:

Knowledge:

Production database is CockroachDB.

Observed:

August 10

Asserted:

August 11

Verified:

August 15

Valid From:

August 1

The knowledge was verified after it became valid.

This is completely possible.

A database record's "updated_at" field cannot represent this distinction alone.

Knowledge exists in time

A useful way to think about a Knowledge Object is:

Knowledge

  +

Time

  +

Context

Without time, the system might ask:

«Is this true?»

With time, it can ask:

«Was this true at the time relevant to my decision?»

That is a fundamentally better question.

For AI agents, this matters enormously.

Imagine an agent investigating:

Incident:

July 15

The agent should not necessarily retrieve:

Current Infrastructure

It should retrieve:

Infrastructure Valid On July 15

This changes the meaning of retrieval.

Knowledge retrieval should be lifecycle-aware

Traditional retrieval might look like:

Query

↓

Semantic Search

↓

Top K Results

A lifecycle-aware retrieval model could become:

Query

↓

Semantic Relevance

Knowledge State

Temporal Validity

Evidence

Authority

↓

Contextually Relevant Knowledge

Now imagine a query:

«What database does the Payment Service use?»

The system might find:

Knowledge A

PostgreSQL

State: Superseded

Relevance: 0.97

And:

Knowledge B

CockroachDB

State: Verified

Current: Yes

Relevance: 0.92

Pure semantic ranking might prefer Knowledge A.

Lifecycle-aware retrieval should probably prefer Knowledge B.

This is one of the central reasons I believe knowledge state should be operational.

Knowledge state should influence AI reasoning

Imagine an AI agent receives three pieces of information.

Knowledge A

State: Verified

Knowledge B

State: Asserted

Knowledge C

State: Contradicted

The agent should not treat them equally.

This does not necessarily mean:

Verified = absolute truth

But it does mean the system can communicate epistemic context.

The agent can reason:

Knowledge A:

Strongly supported.

Knowledge B:

Possible but unverified.

Knowledge C:

Conflicting information exists.

This is much more useful than giving the model three paragraphs and asking it to figure everything out.

The lifecycle creates lineage

Once knowledge has states and transitions, history becomes valuable.

For example:

Observed

│

▼

Asserted

│

▼

Verified

│

▼

Superseded

Each transition can answer:

Who changed the state?

Why?

Based on what evidence?

When?

This creates knowledge lineage.

Knowledge Object

   │

   ▼

Lifecycle History

   │

┌─────┼─────┬─────┐ │ │ │ │

Observed Asserted Verified Superseded

An AI agent can potentially understand not only:

«What do we currently know?»

But:

«How did we arrive at this knowledge?»

That is a very different capability.

Knowledge can have competing states

Real systems are rarely clean.

Imagine two teams independently investigating an incident.

Team A concludes:

Root Cause:

Database overload

Team B concludes:

Root Cause:

Configuration error

Both claims may exist.

Neither may be verified yet.

A knowledge system should not necessarily force one answer immediately.

Instead:

Claim A

State: Asserted

Claim B

State: Asserted

Relationship:

Potentially Contradictory

The system can preserve uncertainty.

Later evidence may verify one claim.

Or both may be partially correct.

This is another reason a knowledge lifecycle cannot always be a simple linear state machine.

Knowledge may branch.

It may conflict.

It may converge.

It may remain uncertain.

AI systems need infrastructure that can represent this.

The lifecycle of AI-generated knowledge

This becomes particularly important when AI agents create knowledge.

Imagine an autonomous agent.

Agent

↓

Observes Logs

↓

Finds Pattern

↓

Creates Hypothesis

↓

Tests Hypothesis

↓

Records Result

The resulting knowledge might move through:

OBSERVED

The CPU increased.

Then:

ASSERTED

The deployment caused the increase.

Then:

VERIFIED

Rollback reduced CPU utilization.

Or:

INVALIDATED

Rollback did not affect CPU.

This creates a memory system that is different from chat history.

The agent is not simply storing messages.

It is storing:

• Observations

• Hypotheses

• Evidence

• Conclusions

• Failed conclusions

That history can help the agent make better decisions in the future.

Failed knowledge is still useful

This is an idea I find particularly interesting.

If an agent tries something and it fails, should the information disappear?

Suppose an agent concludes:

Restarting Service X fixes the issue.

It tries.

The issue remains.

The conclusion becomes:

Invalidated

But that failed knowledge is valuable.

The agent now knows:

«This approach was tried.»

«It did not solve the problem.»

Future reasoning can avoid repeating the same mistake.

This is how experience becomes useful.

A long-running AI system may need to remember:

What worked.

But also:

What did not work.

Knowledge lifecycle can help preserve both.

From static memory to evolving knowledge

Traditional AI memory often focuses on persistence.

Conversation

↓

Store Memory

↓

Retrieve Memory

But persistent memory alone is not enough.

The memory may become outdated.

Incorrect.

Contradicted.

Irrelevant.

A knowledge lifecycle introduces another layer.

Experience

↓

Observation

↓

Assertion

↓

Evidence

↓

Verification

↓

Knowledge

↓

Supersession or Invalidation

The system does not simply remember.

It learns how its knowledge changes.

That is a much more difficult problem.

But it may also be a more useful one.

The architecture implication

Once lifecycle becomes a first-class concept, it affects the entire system.

             KNOWLEDGE OBJECT

                     │

    ┌────────────────┼────────────────┐
    │                │                │

    ▼                ▼                ▼

 CONTENT          EVIDENCE          STATE

    │                │                │

    └────────────────┼────────────────┘
                     │

                     ▼

                   TIME

                     │

                     ▼

               LINEAGE

This means lifecycle cannot simply be added later as:

status = "verified"

It influences:

• Storage

• Indexing

• Queries

• Retrieval

• Relationships

• Transactions

• History

• Agent reasoning

That is why I see knowledge lifecycle as infrastructure.

The AIKOQL question

The question I am exploring is:

«What happens when knowledge state becomes a first-class primitive instead of application metadata?»

Can retrieval improve?

Can AI agents make better decisions?

Can historical context become easier to query?

Can contradictions become visible?

Can evidence influence reasoning?

Can invalidated knowledge prevent repeated mistakes?

Can superseded knowledge preserve history without contaminating current answers?

These are the questions that AIKOQL needs to answer through implementation and testing.

Knowledge is dynamic

The core idea behind this post is simple:

«Knowledge is not static.»

It is:

Observed.

Then interpreted.

Then asserted.

Then supported.

Then challenged.

Then replaced.

Or invalidated.

A knowledge system that only stores the latest answer loses part of the story.

But for AI systems, the story may matter.

Because an AI agent needs more than:

«What do we know?»

It may need to ask:

«Why do we know it?»

«How certain are we?»

«What supports it?»

«What challenges it?»

«Was it true before?»

«Is it true now?»

«What replaced it?»

Those questions define the lifecycle of knowledge.

And they are a central part of what I am exploring with AIKOQL.

What comes next

The next challenge is to make this lifecycle practical.

It is easy to define states conceptually.

It is much harder to design a system that can efficiently answer:

«What knowledge is currently valid?»

«What changed after this event?»

«Which conclusions depend on this source?»

«What evidence supports this claim?»

«Which knowledge was superseded?»

«What should an AI agent retrieve right now?»

So in the next post, I want to go deeper into a practical question:

Querying Knowledge: What Should an AI-Native Query Language Look Like?

Because once we have Knowledge Objects with:

• State

• Evidence

• Time

• Relationships

• Provenance

we need a way to query them.

Traditional SQL is powerful.

Graph queries are powerful.

Vector search is powerful.

But can a query language directly express:

«Find the currently valid knowledge.»

«Show me evidence for this claim.»

«Exclude superseded information.»

«Traverse derived knowledge.»

«Prefer verified sources.»

That is the next part of the AIKOQL journey.

AIKOQL is an evolving open project. The lifecycle concepts discussed here represent an architectural direction being explored and tested. The exact state model, transitions, and storage semantics may evolve as the project encounters real workloads and implementation constraints.

If you work with AI agents, databases, knowledge graphs, RAG systems, or long-running autonomous systems, I would love your perspective.

«Should AI systems explicitly model the lifecycle of knowledge, or should evidence, contradictions, and temporal validity remain the responsibility of the application layer?»

But an idea is only useful if it can survive implementation.

Eventually, every abstraction reaches the same set of questions:

«How is it stored?»

«How is it indexed?»

«How is it queried?»

«How does it behave under concurrent workloads?»

«How does it recover from failure?»

«How does it evolve without losing existing data?»

For AIKOQL, those questions are particularly important.

A knowledge system cannot simply be a collection of objects in memory.

If AI agents are going to depend on knowledge, that knowledge needs to be:

• Durable

• Queryable

• Concurrent

• Traceable

• Evolvable

• Efficient to retrieve

That is why I chose to explore AIKOQL as a systems project built in Rust.

This post looks at the architectural direction behind AIKOQL and the principles shaping its implementation.

Why Rust?

Choosing Rust was not primarily about following a trend.

AIKOQL sits in an interesting space between:

• Database systems

• Storage engines

• Query engines

• Knowledge infrastructure

• AI applications

Those systems tend to care deeply about:

• Memory usage

• Concurrency

• Latency

• Reliability

• Data safety

Rust provides a strong foundation for exploring these requirements.

Its ownership model makes memory safety a first-class concern without requiring garbage collection.

Its concurrency model makes it possible to build highly concurrent systems while reducing classes of data races that traditionally require careful discipline in systems programming.

And its performance characteristics make it suitable for workloads involving:

• Persistent storage

• Indexing

• Query execution

• Concurrent reads and writes

• Streaming

• Data processing

For AIKOQL, Rust is not simply an implementation language.

It influences how the system is designed.

The goal is to build a knowledge engine that can eventually handle knowledge as a long-lived infrastructure concern rather than as temporary context passed between AI calls.

AIKOQL is a systems problem

It is tempting to think of an AI knowledge system as:

Document ↓ Embedding ↓ Vector Database ↓ LLM

But the problem becomes significantly more complicated when knowledge has its own lifecycle.

Consider a single piece of knowledge.

The Payment Service depends on the Transaction Database.

If AIKOQL stores this as a Knowledge Object, several additional questions emerge.

Knowledge Object

Content: Payment Service depends on Transaction Database

      +

Identity

      +

Relationships

      +

Provenance

      +

Evidence

      +

Temporal Context

      +

Knowledge State

      +

Lineage

Now the system must potentially support queries such as:

«What does the Payment Service currently depend on?»

«Show me the source supporting this relationship.»

«Was this relationship ever invalidated?»

«What knowledge was derived from this source?»

«What other knowledge contradicts it?»

«Which knowledge became outdated after a system migration?»

This is no longer simply a document retrieval problem.

It becomes a storage and query architecture problem.

The architectural direction

At a high level, I think of AIKOQL as several cooperating layers.

                CLIENTS & AI AGENTS

                       │

                       ▼

                 AIKOQL QUERY LAYER
                       │
                       ▼
                QUERY PARSING & PLANNING
                       │
                       ▼
                  EXECUTION ENGINE
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼

   KNOWLEDGE       INDEXING       TRANSACTION
    OPERATIONS      OPERATIONS      OPERATIONS

        │              │              │
        └──────────────┼──────────────┘
                       │
                       ▼

               STORAGE & DURABILITY
                       │
                       ▼

                 RUST FOUNDATION

This is a conceptual architecture rather than a claim that every layer is complete.

The implementation is evolving.

But these layers represent the engineering direction I believe AIKOQL needs.

Layer 1: The Knowledge Model

At the center of AIKOQL is the Knowledge Object.

A traditional storage engine might focus primarily on records.

A document store might focus on documents.

A graph database might focus on nodes and edges.

AIKOQL is exploring a different first-class abstraction:

«The Knowledge Object.»

Conceptually:

                KNOWLEDGE OBJECT

              ┌─────────────────┐
              │                 │
              │     Identity    │
              │                 │
              ├─────────────────┤
              │     Content     │
              ├─────────────────┤
              │  Relationships  │
              ├─────────────────┤
              │   Provenance    │
              ├─────────────────┤
              │    Evidence     │
              ├─────────────────┤
              │ Temporal Context│
              ├─────────────────┤
              │ Knowledge State │
              ├─────────────────┤
              │     Lineage     │
              │                 │
              └─────────────────┘

The important architectural question is:

«How do we store these dimensions efficiently without forcing every query to understand every piece of metadata?»

A query for a Knowledge Object's identity should not necessarily require a deep traversal through provenance.

A relationship query should not need to scan unrelated content.

A temporal query should be able to operate on temporal information directly.

This is why the storage and indexing architecture becomes important.

Knowledge is multidimensional

One of the reasons AIKOQL is technically interesting is that Knowledge Objects are not naturally one-dimensional.

A single Knowledge Object may need to participate in several access patterns.

For example:

Knowledge Object │ ├── Lookup by ID │ ├── Lookup by entity │ ├── Traverse relationships │ ├── Search by time │ ├── Retrieve provenance │ ├── Filter by state │ └── Search semantically

A single storage structure is unlikely to optimize all of these operations equally well.

This creates a familiar systems problem.

«How should the data be represented for the primary access patterns of the system?»

The answer may involve multiple indexes and specialized representations.

Conceptually:

                KNOWLEDGE OBJECT
                       │
      ┌────────────────┼────────────────┐
      │                │                │
      ▼                ▼                ▼

  Object Index    Relationship Index   Temporal Index

      │                │                │

      └────────────────┼────────────────┘
                       │
                Additional Indexes
                       │
         ┌─────────────┼─────────────┐
         │             │             │
         ▼             ▼             ▼

     State Index   Provenance     Semantic
                     Index         Index

The goal is not to create an index for every possible query.

The challenge is to understand which access patterns are fundamental to knowledge workloads.

Storage is more than persistence

At the lowest level, AIKOQL needs a reliable way to persist knowledge.

But storage is not simply:

Write bytes to disk.

A database-like system must eventually consider:

• Durability

• Atomicity

• Recovery

• Consistency

• Crash safety

• Snapshots

• Historical state

Imagine an AI agent creates a new piece of knowledge.

The operation might involve more than one update.

Create Knowledge Object

    │

    ├── Persist Object
    │
    ├── Update Object Index
    │
    ├── Create Relationships
    │
    ├── Update Relationship Index
    │
    └── Record Provenance

What happens if the system crashes halfway through?

We do not want:

Knowledge Object: EXISTS

Relationship: MISSING

Provenance: MISSING

when those pieces are expected to form a consistent operation.

This is where transaction semantics become important.

Transactions and knowledge consistency

Knowledge systems can have complicated relationships.

Consider:

Knowledge A

  │

  ▼

DERIVED_FROM

  │

  ▼

Knowledge B

Now imagine a transaction creates both objects and the relationship between them.

Ideally:

BEGIN

Create Knowledge A

Create Knowledge B

Create Relationship

COMMIT

The system should not expose a partially completed state as if it were valid knowledge.

This is one reason I believe database principles remain important for AI-native infrastructure.

AI workloads may be new.

But:

• Atomicity

• Consistency

• Isolation

• Durability

are still valuable properties.

AI does not eliminate the need for reliable systems.

In many cases, it makes reliability even more important.

Concurrency is fundamental

AIKOQL is also being designed with concurrent workloads in mind.

Imagine an enterprise knowledge system receiving:

• New documents

• Knowledge updates

• Agent experiences

• User queries

• Background indexing operations

• Relationship updates

at the same time.

Conceptually:

            ┌──────────────┐
            │   AI Agent   │
            └──────┬───────┘
                   │
                   ▼

            ┌──────────────┐
            │    Query     │
            └──────┬───────┘
                   │
                   │

┌───────────────┐ ▼ ┌────────────────┐ │ Ingestion │ ──▶ AIKOQL ◀── Knowledge API │ └───────────────┘ │ └────────────────┘ │ ▼

            ┌──────────────┐
            │   Storage    │
            └──────────────┘

Multiple operations may be interacting with the same knowledge.

One process may be:

• Reading an object

while another is:

• Updating its state

while another is:

• Adding a relationship

while another is:

• Building an index

Concurrency therefore cannot be treated as an afterthought.

It needs to influence the architecture from the beginning.

Rust provides useful primitives for building this safely, but language safety alone does not solve database consistency.

The architecture still needs to answer:

«What can happen concurrently?»

«What needs isolation?»

«What can be eventually consistent?»

«What operations require atomicity?»

These are systems design questions, not language questions.

Querying knowledge requires a query model

Storage is only useful if applications can access what they store.

For AIKOQL, that leads to another interesting challenge.

What should a query language for knowledge look like?

Traditional SQL is excellent at querying structured data.

Graph query languages are optimized around traversals.

Search engines optimize relevance.

Vector systems optimize similarity.

Knowledge workloads may require combinations.

For example:

Find knowledge about:

Payment Service

WHERE:

State = Verified

AND:

Valid At = Current Time

AND:

Source Authority >= High

ORDER BY:

Relevance

Or:

Find all knowledge:

DERIVED_FROM

this Architecture Document

WHERE:

Knowledge State != Superseded

Or:

Find semantically related knowledge

BUT:

Exclude Contradicted Knowledge

AND:

Prefer Verified Evidence

This is where AIKOQL's query model becomes interesting.

The goal is not necessarily to replace existing query languages.

The question is:

«Can knowledge concepts become first-class query primitives?»

Instead of manually joining multiple metadata structures in the application layer, could a query directly express:

• Knowledge state

• Temporal validity

• Provenance

• Evidence

• Relationships

• Semantic relevance

That is one of the architectural directions I am exploring.

From query to execution

A query is only the beginning.

Internally, the system needs to transform a request into operations.

Conceptually:

            AIKOQL QUERY

                 │

                 ▼

               PARSER

                 │

                 ▼

             QUERY MODEL

                 │

                 ▼

                PLANNER

                 │

      ┌──────────┼──────────┐
      │          │          │
      ▼          ▼          ▼

  Object      Relationship  Temporal
  Lookup       Traversal    Filtering

      │          │          │

      └──────────┼──────────┘
                 │

                 ▼

             EXECUTION

                 │

                 ▼

               RESULTS

The planner eventually becomes responsible for deciding:

«Which indexes should be used?»

«Which operations should happen first?»

«Can filters be pushed down?»

«Can the system avoid unnecessary traversal?»

«Can multiple operations execute efficiently?»

These are classic query engine problems.

But the workload is shaped by the Knowledge Object model.

Relationships are not an afterthought

One architectural principle behind AIKOQL is that relationships should be treated as operational data.

Consider:

Knowledge A

 │

 ├── DERIVED_FROM ───▶ Knowledge B
 │
 ├── CONTRADICTS ────▶ Knowledge C
 │
 └── SUPERSEDES ─────▶ Knowledge D

These are not all equivalent relationships.

Each relationship has different semantics.

For example:

DERIVED_FROM

This can establish lineage.

CONTRADICTS

This can influence knowledge state and retrieval.

SUPERSEDES

This can influence temporal interpretation.

A relationship-aware architecture therefore needs to preserve more than:

Node A → Node B

It may need:

Relationship

Type: SUPERSEDES

Source: Knowledge A

Target: Knowledge B

Created At: Timestamp

Evidence: Reference

State: Active

That makes relationship storage and indexing an important architectural concern.

Temporal knowledge changes the storage problem

One of the most interesting aspects of knowledge infrastructure is time.

Consider these two statements:

January 2025:

The production database is PostgreSQL.

and:

June 2026:

The production database is CockroachDB.

Both statements may be historically correct.

The question becomes:

«Which one is true now?»

A traditional storage system might simply update the record.

Before:

PostgreSQL

    ↓

UPDATE

    ↓

CockroachDB

But if the historical information matters, the system needs to preserve more context.

Knowledge 1

Value: PostgreSQL

Valid: January 2025 → June 2026

State: Superseded

Knowledge 2

Value: CockroachDB

Valid: June 2026 → Present

State: Current

Now queries can become temporal.

What was the production database in March 2026?

and:

What is the production database now?

may legitimately return different answers.

This is one reason temporal indexes and historical state become architectural concerns rather than simple metadata fields.

Provenance is also infrastructure

Provenance is often treated as metadata.

But for AIKOQL, I believe provenance can become part of the operational model.

Consider:

Knowledge Object

  │

  ▼

Derived From

  │

  ▼

Document Fragment

  │

  ▼

Document Section

  │

  ▼

Original Source

This lineage allows the system to answer:

«Where did this knowledge come from?»

But it also creates additional possibilities.

If the source changes:

Original Source Updated

      │

      ▼

Find Derived Knowledge

      │

      ▼

Re-evaluate Knowledge

If a source is invalidated:

Source Invalidated

      │

      ▼

Find Dependent Knowledge

      │

      ▼

Mark for Review

This makes provenance useful beyond explainability.

It becomes part of knowledge maintenance.

And that means provenance needs efficient representation and traversal.

Knowledge state is a systems concern

AI systems often operate with uncertainty.

A piece of extracted information may be:

Observed

but not:

Verified

A previously verified statement may later become:

Superseded

Or:

Contradicted

Or:

Invalidated

This creates a lifecycle.

         OBSERVED

             │

             ▼

         ASSERTED

             │

             ▼

         VERIFIED

             │

      ┌──────┴──────┐
      │             │
      ▼             ▼

 SUPERSEDED    CONTRADICTED

      │             │
      └──────┬──────┘
             │
             ▼

        HISTORICAL

The exact state model is still evolving.

But the important architectural principle is this:

«Knowledge state should influence how knowledge is stored, queried, and retrieved.»

An AI system asking:

What is the current verified architecture?

should not receive superseded information simply because it happens to be semantically similar.

That requires state-aware retrieval.

Durability and recovery

A knowledge system that cannot recover reliably is not useful infrastructure.

Eventually, AIKOQL needs mechanisms for dealing with:

• Process crashes

• Partial writes

• Corruption

• Recovery

• Restart

• Historical state

Conceptually, this leads to familiar database techniques:

Write Operation

   │

   ▼

Durable Record

   │

   ▼

Apply Changes

   │

   ▼

Checkpoint

   │

   ▼

Recover if Required

The exact implementation and mechanisms can evolve.

But the principle is clear.

A Knowledge Object should not disappear because an application process restarts.

If AI agents are going to build long-term knowledge, persistence must be a fundamental capability.

Why the architecture needs layers

One reason I am deliberately thinking about AIKOQL in layers is extensibility.

AI knowledge infrastructure is still evolving rapidly.

New requirements will emerge.

New AI workloads will appear.

New retrieval methods will become useful.

A tightly coupled architecture makes experimentation difficult.

A layered architecture allows the system to evolve.

Conceptually:

    APPLICATIONS & AGENTS
             │
             ▼
          AIKOQL API
             │
             ▼
         QUERY ENGINE
             │
             ▼
      KNOWLEDGE OPERATIONS
             │
    ┌────────┼────────┐
    │        │        │
    ▼        ▼        ▼

  Objects  Relations  Time

    │        │        │
    └────────┼────────┘
             │
             ▼

         STORAGE CORE
             │
             ▼

        RUST RUNTIME

Each layer should ideally have clear responsibilities.

That makes it easier to evolve:

• Storage implementations

• Indexes

• Query operators

• Knowledge representations

• Ingestion systems

• APIs

without rewriting everything above them.

Performance is not just about speed

When people talk about systems programming, performance often means:

«How many operations per second?»

That matters.

But for AIKOQL, performance also means:

Predictability

Can the system behave consistently under load?

Efficiency

Can knowledge be stored without excessive duplication?

Concurrency

Can multiple agents and applications interact safely?

Scalability

Can the architecture grow beyond a single workload?

Latency

Can relevant knowledge be retrieved quickly enough for AI applications?

Recovery

Can the system return to a consistent state after failure?

These properties are interconnected.

A fast system that loses knowledge during a crash is not reliable.

A strongly consistent system that cannot support concurrent workloads may not scale.

A flexible system that requires scanning everything for every query will eventually hit performance limits.

Architecture is about balancing these constraints.

AIKOQL is being built through experimentation

I do not want to present the architecture as finished.

It is not.

AIKOQL is an evolving systems project.

Some ideas will survive implementation.

Others will change when tested against:

• Real workloads

• Concurrency

• Storage constraints

• Query performance

• Memory pressure

• Failure scenarios

That is exactly why implementation and testing are important.

An architecture diagram is easy to draw.

A storage engine is much harder to build.

A query language is easy to design.

An optimizer is much harder.

A Knowledge Object model can look elegant conceptually.

But it needs to prove itself against real data.

The engineering journey is therefore not about defending an initial design.

It is about testing assumptions.

The role of benchmarking

As AIKOQL evolves, I believe benchmarking will become an important part of the project.

Not simply:

«How fast is AIKOQL?»

But:

«Which workloads is AIKOQL actually good at?»

For example:

Object lookup

How efficiently can the system retrieve Knowledge Objects?

Relationship traversal

How does it perform when traversing knowledge relationships?

Temporal queries

How efficiently can historical knowledge be queried?

Concurrent workloads

How does the system behave under simultaneous reads and writes?

Ingestion

How efficiently can knowledge be created from incoming information?

Storage growth

How does storage behave as knowledge history increases?

These tests will help separate:

Interesting architecture

from:

Useful infrastructure

And that distinction matters.

The bigger architectural idea

At its core, AIKOQL is exploring whether AI systems need a different kind of infrastructure layer.

Not simply:

Storage

but:

Persistent Knowledge Infrastructure

A system that can eventually understand:

What do we know?

Where did we learn it?

Why do we believe it?

When was it valid?

What contradicts it?

What replaced it?

What was derived from it?

That is a more complicated problem than storing documents.

It is also a more complicated problem than vector search.

And it is a more complicated problem than graph traversal alone.

The architecture of AIKOQL is an attempt to bring these dimensions together into a system that AI applications can query and build upon.

Where Rust fits into that vision

Rust provides the systems foundation.

                AIKOQL

                   │

                   ▼

            Knowledge Engine

                   │

      ┌────────────┼────────────┐
      │            │            │
      ▼            ▼            ▼

   Storage       Querying    Concurrency

      │            │            │

      └────────────┼────────────┘
                   │
                   ▼

                 RUST

Rust does not automatically make AIKOQL:

• Fast

• Correct

• Scalable

• Durable

Architecture still determines those properties.

But Rust provides a strong environment for exploring them.

Its focus on:

• Memory safety

• Concurrency safety

• Zero-cost abstractions

• Explicit ownership

• Performance

aligns well with the kind of infrastructure AIKOQL is trying to become.

The road ahead

The architecture is only one part of the project.

The next challenge is proving that these abstractions create real value.

That means testing AIKOQL against actual workloads.

Not just asking:

«Does the API work?»

But:

«Does the Knowledge Object model make certain problems easier?»

«Can knowledge state improve retrieval?»

«Can provenance improve trust and explainability?»

«Can relationships improve AI reasoning?»

«Can historical knowledge be managed efficiently?»

«Can the system support real concurrent workloads?»

Those are the questions that will determine whether AIKOQL becomes useful infrastructure.

And those answers cannot come from architecture diagrams.

They have to come from implementation.

Testing.

Failures.

Iteration.

And real workloads.

What comes next

In the next post, I want to move into one of the most interesting problems for AI systems:

Knowledge Has a Lifecycle: Evidence, Contradiction, Supersession, and Time

Most databases store the current state of data.

But knowledge is different.

Something can be:

• True today

• False tomorrow

• Valid historically

• Contradicted by new evidence

• Superseded by better information

For AI agents, understanding those differences may be essential.

Because retrieving information is one problem.

Knowing whether that information is still valid is another.

And that is where the lifecycle of knowledge becomes important.

AIKOQL is an evolving open project. The architectural concepts discussed here reflect the current engineering direction and are being continuously tested and refined as the implementation develops. The goal is not to claim that every component is complete, but to openly explore what infrastructure an AI-native knowledge system may require.

If you build databases, storage engines, AI infrastructure, query engines, or agent systems, I would love your perspective.

«What do you think is the hardest systems problem in building persistent knowledge infrastructure for AI: storage, querying, consistency, provenance, or something else entirely?»

But there is a practical question behind all of this:

Where do Knowledge Objects come from?

For most AI systems today, the answer starts with ingestion.

Documents are uploaded.

Text is extracted.

The content is split into chunks.

Embeddings are generated.

The chunks are stored in a vector database.

And when a user asks a question, the system retrieves the most similar chunks.

This approach has made Retrieval-Augmented Generation possible at scale.

It is also useful.

But I believe there is an important problem hiding inside this pipeline.

A document is not just text.

And if we destroy its structure during ingestion, we may also destroy some of the meaning required to turn information into knowledge.

That is one of the problems AIKOQL is exploring.

The traditional AI ingestion pipeline

A simplified ingestion pipeline often looks like this:

Document

   ↓

Extract Text

   ↓

Split Into Chunks

   ↓

Generate Embeddings

   ↓

Vector Database

   ↓

Retrieve Top K Chunks

   ↓

LLM

This approach works surprisingly well for many use cases.

But consider what can happen during the process.

Imagine a technical document containing:

• Headings

• Paragraphs

• Tables

• Diagrams

• Charts

• Images

• Formulas

• Code

• References

• Footnotes

After text extraction and chunking, much of that structure may disappear.

A table becomes text.

A diagram becomes a caption.

A chart becomes an image with little or no semantic representation.

A formula becomes an isolated string.

A heading may become separated from the content it describes.

A relationship between two sections may disappear.

The result is still searchable.

But is it still the same knowledge?

That is the question.

Documents are more than text

Consider a simple architecture document.

It contains the statement:

The Payment Service depends on the Transaction Database.

That statement might appear inside a diagram.

The diagram might show:

Payment Service
       │
       │ DEPENDS ON
       ▼
Transaction Database

If we flatten the document into plain text, we might end up with something like:

Payment Service Transaction Database

The entities survive.

The relationship may not.

Now imagine a table:

If the table is split across chunks, the relationship between:

Payment Service

and:

99.9%

can become ambiguous.

The value still exists.

But its meaning depends on its position inside the table.

This is one of the fundamental problems with treating all documents as flat text.

Meaning often comes from structure.

The problem with arbitrary chunking

Chunking is one of the most common techniques used in AI data ingestion.

But chunk boundaries are often determined by:

• Character limits

• Token limits

• Fixed sizes

• Sliding windows

For example:

Chunk 1
──────────────

The Payment Service handles customer transactions.
It communicates with the Transaction Database.

Chunk 2
──────────────

Database writes are replicated across regions.
The service must retry failed transactions.

This may work.

But now consider:

Chunk 1
──────────────

The Payment Service handles customer transactions.
It communicates with the Transaction...

Chunk 2
──────────────

Database. Writes are replicated across regions.

The semantic boundary has been broken.

The chunking algorithm successfully created two chunks.

But it may have failed to preserve knowledge.

This is the distinction I think is important:

Chunking optimizes for retrieval size. Knowledge extraction should optimize for meaning.

Those are not always the same thing.

AIKOQL starts with structure

The direction I am exploring in AIKOQL is to treat ingestion as a process of progressively understanding the source.

Instead of:

Document
   ↓
Text
   ↓
Chunks

The conceptual pipeline becomes:

Source
   ↓
Structured Parsing
   ↓
Knowledge Fragments
   ↓
Semantic Analysis
   ↓
Knowledge Candidates
   ↓
Knowledge Objects

The important difference is that the system should try to preserve structure before deciding how information should be represented for retrieval or reasoning.

Step 1: Understand the source

AI systems do not receive information from only one format.

Knowledge may exist in:

• PDF documents

• DOCX files

• Markdown

• HTML pages

• Tables

• Images

• Diagrams

• Charts

• Formulas

• APIs

• Databases

• Events

• Logs

• External systems

These sources have different structures.

A table is not a paragraph.

A chart is not an image.

A diagram is not simply decorative content.

An API response is not the same as a document.

The first question during ingestion should therefore be:

What kind of information are we looking at?

Before extracting meaning, the system should understand the boundaries of the source.

Conceptually:

Source

   ↓

Identify Format

   ├── Document
   ├── Table
   ├── Diagram
   ├── Chart
   ├── Image
   ├── Formula
   ├── API
   └── Event

This is where structured parsing becomes important.

Step 2: Build a structural representation

A document has an internal structure.

For example:

Document
│
├── Title
│
├── Section: Architecture
│   │
│   ├── Paragraph
│   │
│   ├── Diagram
│   │
│   └── Table
│
├── Section: Deployment
│   │
│   ├── Paragraph
│   │
│   └── Configuration
│
└── References

Representing this structure allows the ingestion system to understand boundaries.

This can be thought of as a document tree or an abstract syntax representation of the source.

Conceptually:

Document AST
│
├── Section
│   ├── Paragraph
│   ├── Table
│   └── Diagram
│
├── Section
│   ├── Paragraph
│   └── Formula
│
└── Metadata

The exact implementation can evolve.

But the principle is important:

Do not flatten structure before you understand it.

Once structure is destroyed, it is difficult to reconstruct reliably.

Step 3: Create Knowledge Fragments

After understanding the structure of the source, AIKOQL can treat meaningful parts of the source as different kinds of fragments.

For example:

Knowledge Fragments
│
├── Text Fragment
│
├── Table Fragment
│
├── Diagram Fragment
│
├── Chart Fragment
│
├── Image Fragment
│
└── Formula Fragment

These fragments are not necessarily final Knowledge Objects.

They are meaningful units extracted from the original source.

That distinction is important.

A fragment answers:

What meaningful part of the source did we find?

A Knowledge Object answers:

What knowledge does this information represent?

There may be a transformation between the two.

Text Fragments

A text fragment might contain:

The Payment Service processes customer transactions.

But the fragment should ideally retain context.

For example:

Document:
Payments Architecture

Section:
Transaction Processing

Heading:
Payment Service

Position:
Paragraph 3

Now the system has more than text.

It has context.

The same sentence can mean different things depending on where it appeared.

Table Fragments

Tables contain relationships that are often lost when converted into plain text.

Consider:

A table fragment should preserve:

Table
│
├── Columns
│   ├── Service
│   ├── Owner
│   └── SLA
│
└── Rows
    └── Payment Service
        ├── Payments Team
        └── 99.9%

The relationship between the values is part of the knowledge.

If we only store:

Payment Service
Payments Team
99.9%

the information survives.

But the structure that explains the information may not.

Diagram Fragments

Diagrams are particularly interesting for AI systems.

A diagram can represent:

• Dependencies

• Relationships

• Architecture

• Processes

• Data flows

• Hierarchies

Consider:

Application
     │
     ▼
API Gateway
     │
     ▼
Payment Service
     │
     ▼
Transaction Database

The diagram does not only contain entity names.

It contains relationships.

The knowledge is closer to:

Application
   │
   └── communicates through
           │
           ▼
      API Gateway
           │
           └── routes to
                 │
                 ▼
          Payment Service
                 │
                 └── stores data in
                        │
                        ▼
               Transaction Database

This is a fundamentally richer representation.

For AIKOQL, diagrams are therefore interesting not simply as images to describe, but as potential sources of entities and relationships.

Chart Fragments

Charts contain information that often disappears during traditional text extraction.

A chart may represent:

• Trends

• Changes

• Comparisons

• Thresholds

• Events

• Correlations

Imagine a chart showing:

CPU Usage

90% ────────────────▲
                    │ Deployment
                    │
40% ────────────────┘

The raw image contains information.

But the knowledge may be:

CPU utilization increased significantly after the deployment.

That is not necessarily written anywhere in the document.

It is represented visually.

A knowledge ingestion system should eventually be able to distinguish between:

The image exists.

and:

The image represents information.

This is why multimodal ingestion becomes important.

Formula Fragments

Technical and scientific knowledge often exists inside formulas.

For example:

Revenue = Price × Quantity

A formula is not simply a sequence of characters.

It represents:

• Variables

• Relationships

• Operations

• Constraints

Flattening the formula into plain text may make it searchable.

But semantic understanding requires more.

The same principle applies to:

• Mathematical models

• Engineering formulas

• Financial equations

• Scientific expressions

For AI systems that work with technical knowledge, preserving these structures may become increasingly important.

Step 4: Preserve provenance

One of the principles I consider essential for AIKOQL is provenance.

If an AI system retrieves a piece of knowledge, it should ideally be possible to answer:

Where did this come from?

For a document, provenance might look like:

Knowledge Object

      │

      ▼

Source Document

      │

      ▼

Section

      │

      ▼

Element

      │

      ├── Paragraph
      ├── Table
      ├── Diagram
      └── Chart

      │

      ▼

Knowledge Fragment

      │

      ▼

Knowledge Object

This creates a chain.

Conceptually:

Knowledge Object
      │
      ▼
Knowledge Fragment
      │
      ▼
Source Element
      │
      ▼
Document Section
      │
      ▼
Original Source

This means a piece of knowledge does not become detached from its origin during ingestion.

That is important for several reasons.

Trust

If an AI says:

"The Payment Service has a 99.9% SLA."

We should be able to ask:

Where did that information come from?

Verification

A user should be able to inspect the original source.

Updates

If the original document changes, the system should be able to understand which knowledge may be affected.

Explainability

An AI agent should eventually be able to explain:

I reached this conclusion based on these sources.

Knowledge lineage

Derived knowledge should not become disconnected from the information that produced it.

Step 5: Semantic analysis

After the structure has been preserved, the next challenge is understanding meaning.

This is where semantic analysis begins.

The system can look for:

• Entities

• Concepts

• Relationships

• Events

• Attributes

• Measurements

• Changes

• Dependencies

For example, consider:

The Payment Service depends on the Transaction Database.

Semantic analysis might identify:

Entity:
Payment Service

Relationship:
DEPENDS_ON

Entity:
Transaction Database

Now consider:

The database migration was completed on June 12.

The system may identify:

Event:
Database Migration

Status:
Completed

Time:
June 12

The important point is that semantic analysis should operate on meaningful fragments that still retain their original context.

Otherwise, we risk extracting knowledge from text while losing the structure that explains what the text actually means.

From fragments to Knowledge Objects

At this point, the ingestion pipeline can start producing knowledge candidates.

For example:

Knowledge Candidate

Subject:
Payment Service

Relationship:
DEPENDS_ON

Object:
Transaction Database

Source:
Architecture Document

Evidence:
Diagram

Confidence:
0.87

This is still not necessarily final knowledge.

The system may need to:

• Validate the extraction

• Compare it with other knowledge

• Detect contradictions

• Attach evidence

• Determine authority

• Assign an epistemic state

Eventually, the candidate may become a Knowledge Object.

Conceptually:

Knowledge Fragment

       │

       ▼

Semantic Analysis

       │

       ▼

Knowledge Candidate

       │

       ├── Validate
       ├── Enrich
       ├── Connect
       ├── Compare
       └── Verify

       │

       ▼

Knowledge Object

This distinction is important because AI-generated extraction should not automatically become trusted knowledge.

An LLM may extract something incorrectly.

A source may be outdated.

Two documents may contradict each other.

The ingestion pipeline should preserve uncertainty rather than pretending that extraction is always correct.

Knowledge creation is not the same as text extraction

This is perhaps the most important distinction in the entire pipeline.

Traditional ingestion often asks:

Can we extract the content?

AIKOQL is exploring a different question:

Can we preserve enough structure and context to understand the content as knowledge?

These are not the same problem.

Consider:

Text Extraction

Document
   ↓
Text

Compared with:

Knowledge Extraction

Document
   ↓
Structure
   ↓
Meaningful Fragments
   ↓
Context
   ↓
Semantic Analysis
   ↓
Evidence
   ↓
Knowledge

The second pipeline is more complex.

But knowledge is more complex than text.

Embeddings still matter

This does not mean embeddings or vector databases become irrelevant.

They remain extremely useful.

Embeddings can help with:

• Semantic search

• Similarity

• Clustering

• Retrieval

• Knowledge discovery

But in this model, embeddings become one representation of knowledge rather than the knowledge itself.

Conceptually:

Knowledge Object

      │

      ├── Content
      │
      ├── Provenance
      │
      ├── Relationships
      │
      ├── Temporal Context
      │
      ├── Knowledge State
      │
      └── Semantic Representation
              │
              ▼
           Embedding

This is an important architectural distinction.

A vector can help us find knowledge.

But the Knowledge Object provides the context required to understand what was found.

The ingestion pipeline should preserve meaning

The direction I am exploring can be summarized in one principle:

Preserve meaning before optimizing retrieval.

That means:

Preserve structure

Do not flatten tables, diagrams, and documents too early.

Preserve boundaries

A meaningful section should not necessarily be split because it exceeds an arbitrary token count.

Preserve provenance

Every piece of extracted knowledge should remain connected to its source.

Preserve context

Headings, sections, relationships, and surrounding information may affect meaning.

Preserve modality

Text, tables, diagrams, images, and formulas should not all be treated as identical inputs.

Preserve uncertainty

Extracted information should not automatically be considered verified knowledge.

Why this matters for AI agents

AI agents increasingly need more than search results.

They need context.

Imagine an agent receives:

The Transaction Database is PostgreSQL.

Without context, the agent may assume it is true.

But what if the Knowledge Object tells the agent:

Knowledge:
The Transaction Database is PostgreSQL.

Status:
Superseded

Valid Until:
June 2026

Source:
Architecture Document v1

Replaced By:
Knowledge Object #247

Now the agent can make a better decision.

Similarly:

Knowledge:
The Payment Service depends on the Transaction Database.

Source:
Architecture Diagram

Evidence:
System Design Document

Confidence:
High

Current State:
Verified

The agent has more than text.

It has knowledge with context.

That is the outcome I am exploring with AIKOQL.

The real challenge: knowing what not to flatten

There is no universal rule that says:

Every table should become a Knowledge Object.

Or:

Every paragraph should become a Knowledge Object.

Or:

Every diagram should become a graph.

The ingestion pipeline needs to make decisions.

Some information may become:

• A Knowledge Object

• A Knowledge Fragment

• Evidence

• Metadata

• A semantic representation

• A relationship

• A historical record

This is where the problem becomes difficult.

And interesting.

The ingestion system is not simply converting one format into another.

It is deciding:

What parts of the source represent meaningful knowledge?

That is one of the core engineering challenges behind AIKOQL.

From raw data to knowledge

The complete conceptual pipeline currently looks something like this:

                         RAW DATA

     ┌─────────────────────────────────────┐
     │                                     │
     │  Documents    Tables     Diagrams   │
     │                                     │
     │  Charts       Images     Formulas   │
     │                                     │
     │  APIs         Databases  Events     │
     │                                     │
     └──────────────────┬──────────────────┘
                        │
                        ▼

                  STRUCTURED PARSING

                        │
                        ▼

                 KNOWLEDGE FRAGMENTS

          ┌─────────────┼─────────────┐
          │             │             │
          ▼             ▼             ▼

        Text          Tables       Diagrams

          │             │             │
          └─────────────┼─────────────┘
                        │
                        ▼

                  SEMANTIC ANALYSIS

          ┌─────────────┼─────────────┐
          │             │             │
          ▼             ▼             ▼

       Entities    Relationships    Events

                        │
                        ▼

                 KNOWLEDGE CANDIDATES

                        │
                        ▼

             VALIDATION & ENRICHMENT

                        │
                        ▼

                 KNOWLEDGE OBJECTS

        ┌───────────────┼────────────────┐
        │               │                │
        ▼               ▼                ▼

    Provenance      Relationships      Evidence

        │               │                │

        └───────────────┼────────────────┘
                        │
                        ▼

                 AI-NATIVE KNOWLEDGE

                        │
            ┌───────────┼───────────┐
            │           │           │
            ▼           ▼           ▼

         Retrieval    Reasoning    Agents

This is the bridge I believe AIKOQL is trying to build.

From raw data.

To structured information.

From information.

To contextual knowledge.

And from knowledge.

To AI systems that can reason, retrieve, remember, and explain.

The challenge ahead

Of course, this is not easy.

A pipeline like this introduces difficult questions.

How accurately can we extract relationships from diagrams?

How do we represent ambiguous information?

How should conflicting sources be handled?

When should a Knowledge Candidate become trusted knowledge?

How should confidence be calculated?

How do we preserve provenance without creating excessive storage overhead?

How do we process large documents efficiently?

How do we update knowledge when the original source changes?

How do we prevent an incorrect AI extraction from contaminating the knowledge base?

These are not problems I believe have a single perfect answer.

They are engineering problems that need experimentation, testing, and evidence.

And that is exactly why I am building AIKOQL in the open.

The bigger idea

The traditional AI pipeline often focuses on this:

How quickly can we retrieve relevant text?

AIKOQL is exploring a broader question:

How do we preserve and operate on knowledge without losing the context that makes information meaningful?

That means thinking beyond:

• Chunk size

• Embedding models

• Top K retrieval

And starting to think about:

• Structure

• Meaning

• Provenance

• Evidence

• Context

• Relationships

• Time

• Knowledge state

Because an AI system should not simply retrieve information.

Ideally, it should understand what that information represents.

What comes next

In the next post, I want to go deeper into the infrastructure behind these ideas:

Building AIKOQL in Rust: The Architecture Behind an AI-Native Knowledge Engine

Because a Knowledge Object model and ingestion pipeline are only useful if the underlying system can:

• Store knowledge efficiently

• Preserve history

• Manage relationships

• Support transactions

• Handle concurrent workloads

• Execute queries

• Maintain provenance

• Evolve without losing existing knowledge

That brings us to the systems engineering side of AIKOQL.

The abstractions are important.

But eventually, every abstraction has to survive contact with storage engines, memory, concurrency, transactions, and real workloads.

And that is where the next part of the journey begins.

AIKOQL is an evolving open project. The ingestion architecture and concepts described here are actively being developed and tested. The implementation may evolve as the system encounters real documents, multimodal data, performance constraints, and production workloads.

If you work with RAG, document processing, vector databases, multimodal AI, knowledge graphs, or AI agents, I would love your perspective.

Do you think traditional chunking is sufficient for AI knowledge systems, or do we need ingestion pipelines that preserve structure and provenance as first-class concepts?

But there is an obvious question that follows.

Why do we need another abstraction at all?

We already have relational databases.

We have document databases.

We have vector databases.

We have graph databases.

Each of these technologies solves important problems.

So where exactly does AIKOQL fit?

The short answer is:

AIKOQL is not trying to replace them.

The more interesting answer is that each database abstraction represents data differently because each was designed to solve a different class of problems.

AIKOQL is exploring whether AI systems introduce another set of requirements that existing abstractions do not always represent naturally.

To understand that, let's start with the abstractions we already use.

Different abstractions solve different problems

There is no universally perfect database model.

A relational database is excellent at some things.

A document database is excellent at others.

A vector database solves a different problem.

A graph database provides another perspective.

The mistake is assuming that one model should replace all the others.

Instead, we should ask:

What does each abstraction make easy?

And equally important:

What does each abstraction leave to the application layer?

1. Rows: structure, transactions, and consistency

Relational databases represent information as structured data.

For example:

Users

+----+--------+-------------------+
| ID | Name   | Email             |
+----+--------+-------------------+
| 1  | Alice  | alice@example.com |
| 2  | Bob    | bob@example.com   |
+----+--------+-------------------+

This model is incredibly powerful.

Relational databases are excellent when you need:

• Structured schemas

• Strong consistency

• Transactions

• Constraints

• SQL queries

• Joins

• Reliable business data

For a huge number of applications, a relational database is exactly the right choice.

But imagine asking the database:

Which information about this system is currently valid?

Or:

Which knowledge is supported by the most authoritative evidence?

Or:

What conclusions depend on this piece of information?

Those questions are not impossible to answer with relational databases.

You can build tables for provenance.

You can create temporal models.

You can store confidence scores.

You can create dependency relationships.

But these concepts are not necessarily first-class parts of the data abstraction.

The application has to define what they mean.

2. Documents: flexible and expressive information

Document databases take a different approach.

Instead of forcing information into fixed rows and columns, data can be represented as documents.

For example:

{
  "service": "payments",
  "database": {
    "engine": "PostgreSQL",
    "version": "16"
  },
  "owners": [
    "platform-team"
  ]
}

This is useful for:

• Flexible schemas

• Nested data

• Rapid application development

• Semi-structured information

• Evolving data models

Documents are a natural way to represent rich application data.

But a document still primarily answers:

What information was stored?

It does not automatically represent:

• Whether the information is currently valid

• Where each statement originated

• What evidence supports it

• Whether another source contradicts it

• How authoritative the source is

• What knowledge was derived from it

Again, these things can be added.

But they usually become application-level conventions.

3. Vectors: semantic similarity

Vector databases introduced another important capability.

Instead of retrieving information through exact values, vectors allow systems to retrieve information based on semantic similarity.

For example:

Query:

"How do I restart the payment service?"

        ↓

Vector Search

        ↓

Semantically Similar Documents

This changed how we build retrieval systems.

Vector search is particularly useful for:

• Semantic search

• Retrieval-Augmented Generation

• Similarity search

• Unstructured information

• AI applications

But semantic similarity is not the same thing as knowledge.

Imagine two documents.

Document A:

"The production database runs on PostgreSQL."

Document B:

"The production database previously ran on PostgreSQL."

Semantically, these statements are very similar.

But temporally, they mean very different things.

A vector search may retrieve both.

The application or LLM must then determine:

Which one is current?

Now imagine another statement:

"According to the approved architecture decision, the production database now runs on CockroachDB."

This introduces another dimension.

The system must consider:

• Semantic relevance

• Temporal validity

• Authority

• Evidence

• Knowledge state

Similarity alone is not enough.

This does not make vector databases less useful.

It simply means:

Similarity is one signal. Knowledge requires more context.

4. Graphs: relationships and connected information

Graph databases focus on relationships.

For example:

Service
   │
   ├── DEPENDS_ON ────▶ Database
   │
   ├── OWNED_BY ──────▶ Team
   │
   └── AFFECTED_BY ───▶ Incident

Graphs are extremely powerful when relationships are central to the problem.

They are useful for:

• Relationship traversal

• Network analysis

• Knowledge graphs

• Recommendations

• Dependency analysis

• Connected entities

Graphs answer an important question:

How are things connected?

But a relationship alone does not necessarily tell us:

Is this relationship still valid?

Where did it come from?

Who asserted it?

Is it verified?

Was it superseded?

What evidence supports it?

A graph can represent those concepts.

But once again, the meaning of those concepts often needs to be defined by the application.

The AI problem: combining multiple kinds of context

This is where the architecture of modern AI applications becomes interesting.

A typical AI system may look like this:

                 ┌──────────────────┐
                 │   Relational DB  │
                 │                  │
                 └────────┬─────────┘
                          │
                 ┌────────▼─────────┐
                 │  Document Store  │
                 └────────┬─────────┘
                          │
                 ┌────────▼─────────┐
                 │    Vector DB     │
                 └────────┬─────────┘
                          │
                 ┌────────▼─────────┐
                 │     Graph DB     │
                 └────────┬─────────┘
                          │
                          ▼
                   Application Logic
                          │
                          ▼
                     AI / LLM Agent

The application becomes responsible for combining everything.

It decides:

• Which database to query

• Which results are relevant

• Which information is current

• Which source is authoritative

• Which information should be trusted

• Which relationships matter

• Which historical information should be ignored

• Which contradictions need to be resolved

The LLM then receives the final context.

This works.

But it raises a question:

Should all of this knowledge interpretation live outside the data layer?

That is one of the questions AIKOQL is exploring.

The Knowledge Object: adding meaning to information

AIKOQL introduces the idea of a Knowledge Object as a potential abstraction above raw information.

Conceptually:

Knowledge Object

        Content
           │
           ▼

      +----------+
      | Knowledge|
      |  Object  |
      +----------+
           │
     ┌─────┼──────────────┐
     │     │              │
     ▼     ▼              ▼

Provenance  Time      Relationships
Evidence    State     Derivation
Authority   Confidence Lifecycle

A Knowledge Object is not defined only by its content.

It can also carry context about that content.

For example:

Knowledge:
"The production database runs on PostgreSQL."

Context:

Identity:
production.database.engine

Source:
Architecture Document

Authority:
Approved Architecture Decision

Evidence:
Infrastructure Configuration

Valid From:
January 2025

Valid Until:
June 2026

Current State:
Superseded

Superseded By:
knowledge-object-xyz

Now consider what an AI agent can ask.

Instead of:

Find documents mentioning PostgreSQL.

It could eventually ask:

What is the current production database?

The system now has the opportunity to consider:

• Relevance

• Time

• Knowledge state

• Authority

• Evidence

That is the difference I am exploring.

AIKOQL is not another vector database

This is an important clarification.

AIKOQL is not trying to say:

"Vector search is obsolete."

Vector search remains extremely useful.

But vector search primarily helps answer:

What information is semantically related?

A Knowledge Object explores additional questions:

Is this information current?

Is it verified?

Where did it come from?

What supports it?

What contradicts it?

What knowledge was derived from it?

Can an AI agent reuse it?

Semantic retrieval can be part of a knowledge system.

But semantic retrieval alone does not define knowledge.

AIKOQL is not another graph database

Relationships are also important.

Knowledge Objects can have relationships.

For example:

Knowledge A

    │
    ├── DERIVED_FROM ─────▶ Knowledge B
    │
    ├── CONTRADICTS ──────▶ Knowledge C
    │
    └── SUPERSEDES ───────▶ Knowledge D

But AIKOQL is exploring relationships with additional meaning.

If Knowledge B becomes invalid, what happens to Knowledge A?

If Knowledge D was superseded, should the system return it as current knowledge?

If Knowledge C contradicts another verified statement, should both remain visible?

Relationships become operational.

They are not only used for traversal.

They can influence how knowledge is interpreted.

AIKOQL is not trying to replace relational databases

This is probably the most important point.

AIKOQL does not need to become the system of record for everything.

You should still use the best storage system for the workload.

For example:

Financial transactions
        ↓
Relational Database

Large analytical queries
        ↓
Columnar Database

Application documents
        ↓
Document Store

Semantic similarity
        ↓
Vector Search

Highly connected entities
        ↓
Graph Database

AIKOQL is exploring a different role.

Conceptually:

                 Existing Data Systems
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         ▼               ▼               ▼

     Relational       Documents        Vectors
         │               │               │
         └───────────────┼───────────────┘
                         │
                         ▼

                  Knowledge Layer
                         │
                  ┌──────▼──────┐
                  │   AIKOQL    │
                  │             │
                  │ Knowledge   │
                  │   Objects   │
                  └──────┬──────┘
                         │
              ┌──────────┼──────────┐
              │          │          │
              ▼          ▼          ▼

           Agents     Retrieval   Reasoning

This is the architectural space I find interesting.

AIKOQL does not necessarily need to replace the systems underneath.

It can explore becoming a knowledge-aware layer that gives AI systems richer context.

Where Knowledge Objects fit

The simplest way I currently think about the data ecosystem is this:

Rows answer:

What structured data do we have?

Documents answer:

What information was written or stored?

Vectors answer:

What information is semantically related?

Graphs answer:

How are entities connected?

Knowledge Objects explore:

What does this information mean in context?

And that context can include:

• Identity

• Provenance

• Evidence

• Authority

• Epistemic state

• Temporal validity

• Relationships

• Derivation

• Lineage

• Confidence

• Lifecycle

This is the central hypothesis behind AIKOQL.

A different retrieval question

Traditional retrieval often looks like this:

Query

   ↓

Search

   ↓

Top K Results

   ↓

LLM

But a knowledge-aware system may eventually need something more like:

Query

   ↓

Semantic Relevance

   +

Authority

   +

Temporal Validity

   +

Evidence

   +

Knowledge State

   +

Relationships

   ↓

Contextual Knowledge

   ↓

AI Agent

The difference is subtle but important.

The goal is not simply:

Retrieve the most similar information.

The goal becomes:

Retrieve the most relevant knowledge for this decision.

That may eventually require different signals depending on the workload.

A customer support agent might prioritize current information.

A research system might prioritize evidence.

A compliance system might prioritize provenance.

An autonomous agent might need to understand confidence and uncertainty.

This is why I don't think there will be one universal retrieval strategy.

The Knowledge Object can potentially provide the information required to make those decisions.

The role of AIKOQL in an existing architecture

One of the most important design principles for AIKOQL is interoperability.

AIKOQL should not assume that it owns all the data.

Real organizations already have:

• PostgreSQL

• MySQL

• ClickHouse

• Elasticsearch

• Object storage

• Data warehouses

• Vector databases

• APIs

• Documents

• Event streams

Replacing all of this infrastructure is unrealistic.

The more interesting problem is:

How can knowledge be built from information that already exists?

Conceptually:

Existing Data

     │

     ▼

┌───────────────────┐
│ Relational Data   │
├───────────────────┤
│ Documents         │
├───────────────────┤
│ Files             │
├───────────────────┤
│ APIs              │
├───────────────────┤
│ Events            │
└─────────┬─────────┘
          │
          ▼

    Knowledge Extraction

          │
          ▼

    Knowledge Objects

          │
          ▼

   Knowledge-Aware AI

That is a much more realistic position than claiming:

Move everything into AIKOQL.

The goal is to work with existing infrastructure.

Knowledge-aware does not mean knowledge is always correct

Another important distinction.

A Knowledge Object does not mean the system magically knows the truth.

Knowledge can be:

• Incomplete

• Conflicting

• Outdated

• Unverified

• Inferred

• Incorrect

AIKOQL is therefore exploring explicit knowledge state.

For example:

Observed

      ↓

Asserted

      ↓

Verified

Or:

Knowledge

   ├── Contradicted
   │
   ├── Superseded
   │
   └── Invalidated

The goal is not to pretend uncertainty does not exist.

The goal is to make uncertainty visible.

For AI systems, this may be more important than storing another confidence score in a metadata field.

An AI agent should eventually be able to distinguish between:

"This is verified."

and:

"This was observed but has not been verified."

and:

"This information was previously valid but has been superseded."

Those distinctions are part of the Knowledge Object model.

From data to knowledge infrastructure

The direction I am currently exploring looks something like this:

                    DATA
                     │
                     ▼
             ┌───────────────┐
             │     Rows      │
             │   Documents   │
             │    Vectors    │
             │    Graphs     │
             └───────┬───────┘
                     │
                     ▼

               INFORMATION
                     │
                     ▼

             ┌───────────────┐
             │    AIKOQL     │
             │               │
             │   Knowledge   │
             │    Objects    │
             └───────┬───────┘
                     │
                     ▼

                KNOWLEDGE
                     │
          ┌──────────┼──────────┐
          │          │          │
          ▼          ▼          ▼

       Retrieval   Memory   Reasoning
          │          │          │
          └──────────┼──────────┘
                     │
                     ▼

              AI Applications

This is not a finished architecture.

It is a direction.

And like everything else in AIKOQL, it needs to survive real implementation and testing.

Where I think AIKOQL can provide value

I currently see the strongest potential for AIKOQL in workloads where AI systems need more than retrieval.

For example:

AI Agents

Agents need persistent memory.

But memory is not simply a chat history.

An agent may need:

• Facts

• Observations

• Experiences

• Derived conclusions

• Historical knowledge

A Knowledge Object can provide a structured way to represent these different categories.

Enterprise Knowledge Systems

Organizations have information spread across:

• Documents

• Wikis

• Databases

• APIs

• Internal tools

AIKOQL is exploring whether knowledge can preserve:

• Provenance

• Authority

• Evidence

• Temporal validity

while making it available to AI systems.

Long-Running AI Workflows

Autonomous systems may need to remember why they made a decision.

They may need to revisit previous conclusions.

They may need to invalidate conclusions when new information appears.

This requires more than storing messages.

It requires lineage.

Explainable AI Systems

When an AI system produces a conclusion, users increasingly ask:

Why?

Knowledge lineage could potentially help answer:

• What information contributed to this?

• Where did it come from?

• Was it verified?

• What other knowledge did the system rely on?

This is an important direction for AI infrastructure.

The important question is not replacement

The wrong question is:

Can AIKOQL replace PostgreSQL?

Or:

Can AIKOQL replace ClickHouse?

Or:

Can AIKOQL replace a vector database?

Those comparisons may be useful when testing specific workloads, but they are not the central question.

The better question is:

What becomes possible when knowledge itself has a first-class lifecycle?

Can an AI system reason more reliably?

Can it distinguish historical information from current knowledge?

Can it trace derived conclusions?

Can it identify contradictions?

Can it reuse validated experience?

Can it explain why it retrieved something?

Those are the questions I am building AIKOQL to explore.

Where does AIKOQL fit?

My current answer is simple:

AIKOQL is not trying to replace rows, documents, vectors, or graphs.

Each of those abstractions solves a real problem.

AIKOQL is exploring what happens when we add another layer:

Knowledge with context, provenance, state, time, relationships, and lineage.

Rows store structured facts.

Documents store flexible information.

Vectors help discover semantic similarity.

Graphs represent relationships.

Knowledge Objects explore how information can become operational knowledge for AI systems.

That distinction is still being tested.

And I expect my understanding of it to evolve as AIKOQL evolves.

But this is the space I believe is worth exploring.

What comes next

In the next post, I want to move from the abstraction itself to one of the hardest practical problems:

From Documents to Knowledge Objects: Rethinking AI Data Ingestion

Because if Knowledge Objects are going to be useful, we need to answer:

Where do they come from?

Documents are not just text.

They contain:

• Tables

• Diagrams

• Charts

• Images

• Formulas

• Structured sections

• Relationships

Flattening everything into plain text can destroy meaning.

So the next part of the AIKOQL journey will explore how information moves from raw data and multimodal documents toward structured knowledge.

The real challenge is not just storing knowledge.

It is understanding how to create it without losing the context that made the information meaningful in the first place.

AIKOQL is an evolving open project. The architecture and ideas described here are being actively tested and may change as the system encounters real workloads, benchmarks, and engineering constraints.

If you work with databases, vector search, graphs, RAG, AI agents, or knowledge systems, I would love your perspective.

Do you think AI systems need a knowledge-aware layer, or should these capabilities remain in the application layer built on top of existing databases?

What should data infrastructure look like when AI agents become first-class users of that infrastructure?

That question naturally leads to another one.

If AI systems need something more than rows, documents, vectors, and disconnected retrieval results—

What exactly are they operating on?

My current answer is a Knowledge Object.

But a Knowledge Object is not simply a new name for a JSON document.

It is also not just a vector with metadata.

And it is not simply a graph node.

A Knowledge Object is my attempt to represent something that AI systems actually need to work with:

A piece of knowledge together with the information required to understand whether it is valid, where it came from, how it relates to other knowledge, how it changed, and whether an AI system should trust or reuse it.

That distinction is becoming increasingly important as AI applications move from simple retrieval toward persistent memory, reasoning, autonomous workflows, and long-running agents.

The problem with storing information without its knowledge context

Let's start with a simple example.

Imagine a system stores the following fact:

"The production database runs on PostgreSQL."

That looks straightforward.

A traditional database can store it easily.

A document store can store it.

A vector database can embed it.

A graph database can connect it to other entities.

But an AI agent needs to know more.

For example:

• Who made this statement?

• Where did the information come from?

• Is it an observation or an official assertion?

• Is there evidence supporting it?

• When was it true?

• Is it still true?

• Has a newer configuration replaced it?

• Did another source contradict it?

• Was this knowledge derived from other knowledge?

• How confident should the system be?

• What other knowledge depends on this fact?

Now imagine the production database changes from PostgreSQL to another system.

The old statement does not necessarily become meaningless.

It becomes historical knowledge.

An AI agent may still need to understand that:

PostgreSQL was the production database during a particular period.

That is where the difference between data and knowledge becomes interesting.

The content may remain the same.

But its meaning changes depending on:

• time

• evidence

• authority

• relationships

• history

• epistemic state

This is the space I am exploring with Knowledge Objects in AIKOQL.

A Knowledge Object is more than content

At the simplest conceptual level, we can think about a Knowledge Object like this:

Knowledge Object
│
├── Identity
├── Content / Properties
├── Relationships
│
├── Provenance
│   ├── Evidence
│   ├── Source
│   ├── Authority
│   └── Scope
│
├── Knowledge State
│   ├── Epistemic Status
│   ├── Confidence
│   └── Validity
│
├── Lineage
│   ├── Derivation
│   ├── Sources
│   └── Reasoning History
│
└── Lifecycle
    ├── Observe
    ├── Assert
    ├── Verify
    ├── Contradict
    ├── Supersede
    ├── Merge
    └── Invalidate

This is not just a conceptual diagram.

These ideas increasingly reflect the direction of AIKOQL's implementation.

The important point is this:

A Knowledge Object does not only store what is known. It attempts to preserve how that knowledge came to exist and what its current state means.

1. Identity: knowledge needs a stable identity

Every Knowledge Object needs to be addressable.

That sounds obvious, but identity becomes much more important once knowledge evolves.

Consider these statements:

"The API uses version 1."

Later:

"The API uses version 2."

Are these two unrelated pieces of information?

Or are they two points in the lifecycle of the same underlying subject?

AIKOQL needs to distinguish between:

• identity

• versions

• history

• replacement

• relationships

A Knowledge Object should not force an AI system to treat every update as completely unrelated information.

The system should be able to understand continuity.

2. Content is only one part of the object

The obvious part of a Knowledge Object is its content.

For example:

Subject: Production Database
Property: Database Engine
Value: PostgreSQL

Or:

{
  "service": "payments",
  "database": "PostgreSQL"
}

This is familiar territory.

Traditional databases already do this extremely well.

But content alone does not tell us whether the information should be trusted or used.

A row can contain a value.

A document can contain a statement.

A vector can represent semantic similarity.

None of those abstractions automatically answer:

Why should an AI believe this right now?

That is where a Knowledge Object starts becoming more interesting.

3. Evidence: where did this knowledge come from?

Knowledge without provenance is dangerous for AI systems.

Imagine an AI agent retrieves this:

"The deployment was rolled back."

Without provenance, the agent does not know whether this information came from:

• an official incident report

• a production event

• a Slack message

• an old document

• a user comment

• another AI model

• an inferred conclusion

These sources are not equivalent.

AIKOQL is increasingly treating evidence and provenance as first-class parts of knowledge.

The system can preserve information about the source and supporting evidence instead of treating the extracted statement as detached text.

This becomes even more important for document ingestion.

A statement extracted from a table should not necessarily lose the fact that it came from:

Document → Page → Table → Row → Cell

Similarly, information extracted from a diagram, image, formula, or structured document should preserve its origin.

The current direction of AIKOQL's ingestion pipeline reflects this idea.

The system is evolving toward multimodal ingestion that can preserve structured source information, including tables, diagrams, charts, formulas, images, and document fragments.

The goal is not simply:

"Extract text and create embeddings."

The goal is closer to:

Preserve knowledge boundaries and provenance before projecting information into retrieval or reasoning systems.

That distinction matters.

4. Authority: not all knowledge should have equal weight

Imagine two pieces of information.

An engineer writes:

"We might migrate the authentication system next month."

Later, an approved architecture decision states:

"The authentication migration is scheduled for Q4."

Both statements may be relevant.

But they do not carry the same authority.

This is one of the problems that simple retrieval systems often push into application logic.

The retrieval system finds both.

The LLM receives both.

Then the model is expected to decide what to trust.

But what if authority becomes part of the knowledge itself?

A Knowledge Object can carry information about the authority of the source that produced it.

This creates an opportunity for knowledge-aware retrieval.

Instead of simply asking:

"What is semantically similar?"

A system can eventually ask:

"What is relevant, current, supported by evidence, and authoritative enough for this decision?"

That is a fundamentally different retrieval question.

5. Knowledge has an epistemic state

One of the most important ideas currently being developed in AIKOQL is that knowledge should not always be represented as simply:

exists

A statement can exist in different epistemic states.

For example, information may be:

• observed

• asserted

• inferred

• verified

• contradicted

• superseded

The exact lifecycle and legal transitions matter.

Consider these two statements:

"Service A is experiencing latency."

and:

"Service A is experiencing latency."

The text is identical.

But imagine the first statement is:

Observed from telemetry

And the second is:

Verified by an incident engineer

The content may be identical.

The knowledge state is not.

For AI systems, that difference can matter enormously.

A Knowledge Object should allow the system to understand not only:

What is being claimed?

But also:

What is the current epistemic status of that claim?

This is one of the places where I think the Knowledge Object abstraction becomes more useful than simply storing documents or embeddings.

6. Knowledge exists in time

Most databases are good at storing timestamps.

But timestamps alone do not necessarily represent the temporal meaning of knowledge.

Consider:

"The production database is PostgreSQL."

This statement might be valid from:

January 2025 → June 2026

After that, it may be replaced.

The historical statement should not necessarily disappear.

The AI system should be able to answer different questions:

What is the current production database?

What was the production database in March 2026?

How did the database architecture evolve?

These are different questions.

AIKOQL is exploring temporal knowledge as part of the Knowledge Object model.

This means distinguishing between:

• current knowledge

• historical knowledge

• validity intervals

• superseded knowledge

• transaction history

The objective is to make temporal meaning available to the knowledge layer instead of forcing every application to rebuild that interpretation independently.

7. Knowledge can be derived from other knowledge

AI systems do more than store information.

They derive conclusions.

Imagine an agent knows:

CPU utilization is above 95%.

And:

Request latency increased by 300%.

And:

The issue began after a deployment.

The agent may derive:

The latest deployment may be contributing to the production incident.

That conclusion should not simply become another disconnected string.

Ideally, the system should know:

Derived Knowledge
        │
        ├── Premise: CPU utilization
        ├── Premise: Latency increase
        ├── Premise: Deployment event
        │
        └── Derivation
             ├── Operation
             ├── Actor
             ├── Model / Reasoning Context
             ├── Timestamp
             └── Reason

This creates lineage.

Now the system can answer:

Why does the agent believe this?

And potentially:

Which knowledge objects contributed to this conclusion?

This is extremely important for AI systems.

A generated answer is useful.

A generated answer that can trace its knowledge lineage is much more useful.

AIKOQL is therefore evolving toward treating derivation as first-class knowledge structure rather than simply storing a loose graph edge.

8. Confidence should have context

Confidence is often represented as a number.

For example:

0.87

But a number without context can be misleading.

Where did that confidence come from?

Was it:

• calculated from multiple sources?

• inherited from evidence?

• assigned by a model?

• verified by a human?

• updated after new confirmations?

A Knowledge Object can preserve confidence together with context.

For example:

Confidence
│
├── Score
├── Confirmations
└── Last Verified

The important idea is not that AIKOQL has solved confidence.

Confidence is a difficult problem.

The more important principle is:

Confidence should not become detached metadata with no explanation of how the system arrived there.

9. Knowledge changes through operations, not just CRUD

This is perhaps the biggest conceptual shift.

Traditional applications often think about data like this:

Create
Read
Update
Delete

Knowledge behaves differently.

Imagine these operations:

Observe
Assert
Verify
Contradict
Supersede
Merge
Invalidate

These are not just different names for CRUD.

They represent different semantic actions.

For example:

Verify

Verification should not necessarily mean:

UPDATE status = verified

A verification event may need to:

• add evidence

• update confidence

• record who verified the information

• preserve historical state

Contradict

A contradiction should not necessarily destroy either claim.

Two conflicting pieces of knowledge may both need to remain available until a resolution is made.

Supersede

A newer knowledge object may replace an older one while preserving the historical relationship.

Invalidate

Invalidation may also affect knowledge derived from the invalidated object.

This is where knowledge begins to behave more like a lifecycle than a database record.

10. Relationships turn information into a knowledge network

A Knowledge Object should not exist in isolation.

Consider:

Service
   │
   ├── depends on ───────▶ Database
   │
   ├── deployed by ──────▶ Deployment
   │
   └── affected by ──────▶ Incident

Relationships provide structure.

But relationships also create consequences.

Imagine a piece of knowledge is invalidated.

What happens to conclusions derived from it?

If:

A ──DERIVED_FROM──▶ B

And B becomes invalid or stale, the system should at least be able to identify that A may now require attention.

This is one reason lineage and relationships matter together.

Knowledge should not simply form a graph for visualization.

Relationships can become part of the operational behavior of the system.

A Knowledge Object is not a replacement for every database abstraction

It is important to clarify something.

A Knowledge Object does not mean:

Rows are obsolete.

They are not.

Documents are not obsolete.

Vectors are not obsolete.

Graphs are not obsolete.

Each abstraction is useful.

The question AIKOQL is exploring is whether AI systems need an additional layer that can combine several knowledge concerns:

Content
      +
Relationships
      +
Evidence
      +
Authority
      +
Time
      +
Epistemic State
      +
Derivation
      +
Confidence
      +
Lifecycle

The Knowledge Object is an attempt to make these concerns explicit.

Not necessarily to replace existing storage technologies.

But to create a more natural abstraction for knowledge-aware systems.

The ingestion problem: where do Knowledge Objects come from?

One question naturally follows:

If Knowledge Objects are so rich, how do we create them?

This is another area where AIKOQL is evolving.

Documents are not simply text.

A technical document may contain:

• headings

• paragraphs

• tables

• diagrams

• charts

• images

• formulas

• structured relationships

Flattening everything into plain text can destroy useful information.

The current AIKOQL ingestion work is moving toward preserving modality and structure through the pipeline.

Conceptually:

Document
    │
    ▼
Structured AST
    │
    ▼
Knowledge Fragments
    │
    ├── Text
    ├── Tables
    ├── Diagrams
    ├── Charts
    ├── Images
    └── Formulas
    │
    ▼
Semantic Analysis
    │
    ▼
Knowledge Candidates
    │
    ▼
Knowledge Objects

One of the principles here is that retrieval chunks should be projections of meaningful knowledge boundaries rather than arbitrary fragments created purely because a chunk reached a token limit.

A table, for example, should not lose half its structure simply because a retrieval chunker reached its size threshold.

The same principle applies to provenance.

The eventual Knowledge Object should be able to preserve meaningful information about where the knowledge originated.

What about agent memory?

Knowledge Objects also create an interesting opportunity for AI agents.

Agents do not only need factual knowledge.

They accumulate experience.

For example:

"When deploying service X, the migration must run before restarting workers."

That might not be a permanent global fact.

It could be an experience learned by an agent.

The experience may have:

• conditions for reuse

• an outcome

• confidence

• a time-to-live

• sharing constraints

AIKOQL is exploring agent experience as a type of knowledge that can be recorded, matched, and reused.

This is important because agent memory should probably not be treated as one large conversation transcript.

An agent needs to distinguish between:

Facts

Observations

Derived conclusions

Historical knowledge

Reusable experiences

A Knowledge Object model provides one possible foundation for representing these categories.

The real test is not the data model

A Knowledge Object can sound elegant on a whiteboard.

That does not make it useful.

The real question is:

Does this abstraction produce better behavior when an AI system encounters changing, conflicting, incomplete, or long-lived knowledge?

That is where testing becomes important.

The current AIKOQL work is increasingly focused on questions such as:

• Can the system distinguish current knowledge from superseded knowledge?

• Can it preserve historical context?

• Can conflicting knowledge remain visible instead of being silently overwritten?

• Can an agent trace why a conclusion exists?

• Can invalidation propagate through derived knowledge?

• Can provenance help explain the source of an answer?

• Can reusable agent experiences be selected without leaking expired or unauthorized information?

• Can the system admit that knowledge is unknown rather than confidently returning irrelevant context?

These are much more important questions than simply asking:

How fast can we insert another record?

Performance still matters.

But for AI knowledge infrastructure, correctness of knowledge state may matter just as much.

My current definition of a Knowledge Object

After the recent evolution of AIKOQL, this is how I would currently define it:

A Knowledge Object is a persistent representation of knowledge that combines content with its identity, provenance, evidence, authority, temporal validity, epistemic state, relationships, derivation, confidence, and lifecycle.

That definition may evolve.

And that is intentional.

AIKOQL is still being built and tested.

But I believe this direction is becoming clearer.

A row tells us:

What data was stored.

A document tells us:

What information was written.

A vector helps us find:

What information is semantically related.

A graph helps us understand:

How entities are connected.

A Knowledge Object is exploring a different question:

What does this information mean, why should we trust it, when was it valid, where did it come from, and what knowledge depends on it?

For AI systems, I think those questions will become increasingly important.

What comes next

The Knowledge Object is only useful if we can understand how it interacts with the systems that already exist.

So in the next post, I want to explore a question that I expect many engineers will ask:

Rows, Documents, Vectors, Graphs, and Knowledge Objects: Where Does AIKOQL Fit?

Because AIKOQL should not be positioned as:

"Another database that replaces everything."

That is neither realistic nor the goal.

The more interesting question is:

What workloads emerge when an AI system needs knowledge to have memory, provenance, time, evidence, authority, and lifecycle?

That is the problem space I am continuing to explore.

And I am building AIKOQL in the open because I believe the best way to test these ideas is to expose them to engineers who disagree with them.

If you work with databases, AI agents, RAG systems, graphs, knowledge systems, or Rust infrastructure, I would love to hear your perspective.

Do you think AI systems need a first-class Knowledge Object abstraction—or can existing data models solve this problem without introducing a new one?

We now have AI agents that can reason, use tools, generate code, search for information, and interact with applications. But as AI capabilities evolve, I keep coming back to one question:

«Is the data infrastructure we use today designed for the way AI systems need to understand and work with knowledge?»

That question is one of the reasons I started building AIKOQL — AI Knowledge Object Query Language.

This is not a story about replacing PostgreSQL, ClickHouse, or every database that already exists.

It is an exploration.

An exploration into whether the rise of AI agents and intelligent applications will eventually require us to rethink some of the primitives used to store, organize, retrieve, and operate on knowledge.

The problem I keep seeing

Modern AI applications rarely work with just one type of data.

An application might need:

• A relational database for structured data

• Object storage for files

• A vector database for semantic retrieval

• A cache for fast access

• A graph model for relationships

• An LLM for reasoning and interpretation

Each system solves a specific problem.

And that is not necessarily a bad thing.

But when we start building AI agents that need persistent memory, contextual understanding, semantic retrieval, entity relationships, and access to different types of information, the architecture can quickly become fragmented.

The AI system itself becomes responsible for stitching everything together.

The agent retrieves vectors from one system.

Structured information from another.

Documents from somewhere else.

Relationships may need to be reconstructed.

Context needs to be assembled.

Memory needs to be managed.

And then the LLM is asked to make sense of everything.

This made me wonder:

«What if knowledge itself could become a first-class primitive?»

The question behind AIKOQL

AIKOQL started with a simple hypothesis:

«What would a data system look like if it were designed with AI systems and knowledge-oriented workloads as a primary consideration?»

Not just rows.

Not just documents.

Not just vectors.

But something that could potentially represent knowledge as an object with structure, meaning, relationships, metadata, and context.

That is where the idea of the Knowledge Object comes in.

I am still exploring what that abstraction should ultimately look like.

And I think that is an important distinction.

AIKOQL is not being built around the assumption that I already know the final answer.

It is being built around a set of questions that I believe are worth investigating.

For example:

• Can knowledge be represented as a first-class database primitive?

• Can structured, unstructured, and semantic information coexist more naturally?

• Can relationships between pieces of knowledge become easier to model and query?

• Can AI agents interact with persistent knowledge without developers constantly stitching together multiple systems?

• Can retrieval become more contextual and knowledge-oriented?

• Can we design infrastructure that feels native to AI agents rather than being adapted to them?

I don't yet claim to have solved all of these problems.

But I believe they are interesting enough to build and experiment with.

AI-native does not mean traditional databases are obsolete

One thing I want to be clear about from the beginning:

AIKOQL is not an attempt to declare traditional databases obsolete.

Relational databases are incredibly powerful.

Columnar databases are exceptional for analytical workloads.

Search engines solve information retrieval problems extremely well.

Vector databases introduced an important capability for semantic similarity.

Each category exists because different workloads have different requirements.

The question I am exploring is not:

«"Can one database replace everything?"»

The more interesting question is:

«Are there emerging AI workloads that do not fit naturally into the abstractions we use today?»

AI agents are a good example.

An agent may need to remember interactions, understand entities, maintain context, retrieve relevant knowledge, connect related information, and reason over what it finds.

That does not necessarily mean existing databases cannot support these workloads.

Of course they can.

But supporting a workload and being designed around a workload are two different things.

AIKOQL is an attempt to explore that gap.

Why build it in Rust?

AIKOQL is being built in Rust because I want to work at the infrastructure level.

Databases and storage engines require careful control over:

• Memory

• Concurrency

• Data layouts

• Performance

• Reliability

• Storage

• Execution

Rust provides an interesting combination of systems-level control and memory safety.

That does not automatically make AIKOQL fast.

Performance still needs to be proven through architecture, implementation, testing, and benchmarking.

But Rust gives me a strong foundation for experimenting with these ideas.

The goal is not simply to write another database in Rust.

The goal is to understand what the architecture of an AI-native knowledge system should look like.

And Rust gives me the right environment to experiment at that level.

Where AIKOQL is today

AIKOQL is still an evolving project.

The architecture is being tested.

The assumptions are being challenged.

The implementation is growing.

Benchmarks and database-oriented workloads are being explored.

LLM integration and testing are also in progress.

There will probably be things I believe today that I will change my mind about later.

And honestly, I think that is part of the value of building this project publicly.

Infrastructure is full of trade-offs.

A design that looks elegant on paper may fail under real workloads.

A feature that sounds useful may introduce unacceptable complexity.

A benchmark may expose an architectural bottleneck.

A new use case may completely change how the system should be designed.

I want AIKOQL to evolve based on experimentation and evidence rather than assumptions.

Why I am building in the open

Building something like a database or knowledge infrastructure system alone can become an echo chamber.

You can become convinced that your abstraction is brilliant without anyone seriously challenging it.

I don't want that.

That is why I want to document this journey publicly.

I want to share:

• Architecture decisions

• Design experiments

• Benchmarks

• Failures

• Performance problems

• Trade-offs

• Ideas that worked

• Ideas that did not work

My hope is that this attracts conversations with people who are interested in similar problems.

Rust developers.

Database engineers.

AI infrastructure engineers.

Distributed systems engineers.

Researchers.

People building AI agents.

People working on memory systems.

People who simply think the current way we build AI infrastructure can be improved.

I don't expect everyone to agree with the direction.

In fact, disagreement is useful.

Good infrastructure is built by challenging assumptions.

What I want to explore next

Over the coming weeks, I plan to write more about the ideas and engineering decisions behind AIKOQL.

Some of the topics I want to explore include:

• What exactly is a Knowledge Object?

• How should knowledge be represented and stored?

• AI agents and persistent memory

• Structured data versus semantic information

• Where vector databases fit into AI infrastructure

• Storage and execution architecture

• Why I am experimenting with Rust

• Database benchmarking and performance testing

• How AIKOQL compares conceptually with existing database systems

• The architectural decisions that survive testing—and the ones that don't

This project may evolve significantly.

That is intentional.

The goal is not to defend an idea at all costs.

The goal is to find out whether the idea can survive contact with real engineering.

The journey starts here

AIKOQL is my attempt to explore a question that I think will become increasingly important as AI systems become more autonomous:

«What should data infrastructure look like when AI agents are first-class users of that infrastructure?»

I don't know whether the answer will be a new type of database.

A new abstraction.

A layer on top of existing databases.

Or something entirely different.

But I believe the question is worth exploring.

So I am building.

Testing.

Benchmarking.

Breaking things.

Rebuilding them.

And documenting the journey along the way.

If you are interested in databases, Rust, AI infrastructure, agent memory, storage systems, or knowledge representation, I would love to hear your perspective.

What do you think is missing from today's data infrastructure for AI agents?

Let's explore it together.

AIKOQL is an open project under active development. The ideas, architecture, and implementation described in this blog will evolve as the project is tested against real workloads and use cases.