There are only three kinds of data

Knowledge, entities and events. Everything a system stores is one of the three, whether it is a CRM, a data warehouse or the memory of an AI agent. Not five kinds, not twenty. Three, and two questions tell them apart.

Why it is worth the thought

Most data problems do not look like data problems. A search that returns everything except the record you wanted. A customer with two phone numbers and no way to tell which is current. A log table nobody dares to prune, slowing every query that touches it. A private note that turns up in a shared workspace. Each is usually the same mistake: one kind of data stored with the rules of another.

It matters more now that software reads our data for us. A language model handed a customer record full of appended notes cannot tell this year's phone number from last year's, and a retrieval system that embeds every log line returns old events as if they were lasting facts. An agent is only as good as what it is given, and what it is given depends on how the data was sorted when it was written.

What we learned sorting our own

Klarhimmel is run by one person and a team of AI agents, and the agents share a memory: what they have learned, the people and projects they work on, and what has happened. We did not start with three kinds. We found them by looking at what had piled up and noticing that it behaved in three different ways. Three lessons came out of it.

Search everything and you find less. The requests the agents were given were saved as knowledge and embedded, so they competed in meaning search with the rules and decisions the agents actually needed. A health check found more than a thousand saved requests with no retrieval value. Once they were stored as events, which skip the embedding step, our records put the saving at 38% of the database.

Privacy follows from the kind. Knowledge is copied into shared stores and entities are merged into them, but the shared stores have no place for events at all. What one person asked on one day stays in their own store, because there is nowhere else for it to go, and no rule anyone has to remember.

Old plans are events too. When we moved our own task board this week, the old plans came along as live tasks, side by side with the work that was current. A plan that is no longer current is a record of what we meant at the time, not an entity to keep updating. We took a backup, deleted the old plans and wrote new ones. As I put it to the agents: better to rewrite the plans than to patch broken data.

Knowledge, entities and events

Knowledge is written once and lasts: facts, rules, decisions, patterns. It is appended, never edited in place, and a better rule supersedes the old one rather than overwriting it. It is found by meaning, which makes it the part of a system that semantic search is for. A warranty policy, a deployment checklist and the reason you stopped using a supplier are knowledge.

An entity has an identity and a state that changes: a customer, a product, a project, an account. It is upserted on a key, so there is exactly one record per thing, and it is found by that key first and by meaning second. When a customer moves, you do not insert a second customer. You update the one you have.

An event is written once and fades: an order, a sign-in, a support message, a prompt. It is appended with a timestamp and never changed, it is found by time window, and it can be archived or expired once its window has closed.

Two questions, four boxes, three kinds

The two questions are whether a record is written once or updated in place, and whether its value lasts or decays.

Written once and lasting is knowledge. Written once and decaying is an event. Updated in place is an entity.

Two questions make four boxes, so one is left: updated in place, and decaying. A session, a free trial, a discount code. Each of those is an entity with an expiry date, not a fourth kind, and the fourth box stays empty. If a new kind of data ever seems to need a fourth box, the model is wrong.

The category decides behaviour: how a record is written, keyed, retrieved, expired and shared. Anything finer, whether a record is an invoice, a note or a meeting summary, is a label inside a category, useful for filtering and irrelevant for routing. A further split earns its place only when the two sides need different handling.

One customer, three ways

Take one customer in a bike shop's system and follow her through the three kinds.

Her address is an entity. It is updated on her customer key, so there is only ever one, looked up by that key, kept while she is a customer, and shared by merging: if two systems each hold a copy of her, they should end up as one record, not two.

Her repair last spring is an event. It is appended once, with a timestamp, and left alone. It is queried by time, as in what did we do to her bike in April, and it can be archived once the warranty has run out. It is also the private part, a record of what one person had done on one day, which is exactly what should never be copied into a shared space.

The shop's returns policy is knowledge. It is superseded as a whole, not edited until nobody remembers what it said. It is found by meaning, as in what do we do when someone brings a part back, kept until it is wrong, and shared by copying as widely as possible, because a rule only one person knows is a risk.

A system that never lets go of its events slowly buries everything else under them.

When something fits none of them

Something that seems to fit none of the three is usually two of them stuck together. A notes field on a customer record is the classic case: events, the calls and quotes and complaints, appended into an entity. A stricter rule about writing notes does not fix it. An event log keyed to the customer, beside a record that holds only her current state, does.

An email about a support ticket is the same mix, an event that refers to an entity. Store the email as an event with a reference to the ticket, instead of copying its contents into the ticket's description.

A task description often holds all three at once: the conditions for calling it done, which are the task's state; findings added as the work goes on, which are events; and the background, which is knowledge. They age at different speeds in one text field, so the field slowly stops making sense.

Sort these

Try the two questions on six records, and pick a kind for each.