In my previous post, I introduced the question behind AIKOQL:

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?