For as long as databases have existed, the thing reading the data has been a person. That stopped being true. The fastest-growing consumer of business data today is software that reasons — an AI agent wired straight to the database, asking questions and acting on the answers it gets back. We're building Rune because that single change breaks an assumption the whole data stack rests on, and almost no one has gone back to repair the foundation.
The assumption was that a human sits in the loop. A database never had to explain itself, because a person could supply the meaning it left out. You knew, from a meeting two quarters ago, that revenue in this table excludes refunds. You knew which of the three tables that mention customers is the one finance actually trusts. You knew to ask someone before reporting a number that looked too good. None of that knowledge lived in the database. It lived in you, and in the people you could turn to. The database stored the data; the organization stored its meaning.
Hand that same database to an agent, and the meaning is simply gone.
A database stores your data, but not what it means
A database records values. It does not record what those values represent, where they came from, or whether you should trust them. A column is named amt. Is that gross or net? Dollars or cents? Booked when the order was placed, or when it shipped? The column doesn't say. For decades that was fine, because the answer was a Slack message away.
An agent has no Slack message to send. It sees amt, rev_adj, and total_v2, three columns that all look like they might be revenue, and it has to pick one. So it picks. It writes confident SQL against the wrong one, returns a clean, plausible number, and moves on. Nothing flags the choice as a guess, because to the database it wasn't a guess — it was a valid query against a real column.
This is worse than a model being wrong. A hallucinated fact often gets caught, because it sounds off. A correct query against the wrong column produces a number that looks exactly right. Nobody reconciles it. It lands in a board deck, and the first time anyone notices is when the quarter doesn't add up — after the decision's already been made on it.
The data was never the problem. The data was always fine. What was missing is the one thing the database never bothered to keep: what the data means.
Meaning belongs inside the data
The conviction behind Rune is simple to state and hard to retrofit: the meaning has to live inside the data, not in a layer beside it, and it has to be mandatory, not optional.
In Rune you cannot put data in without saying what it means. A table's description, its ownership, how fresh it's expected to be, the constraints its values must satisfy, where it came from — these are part of the definition, enforced at the schema level on every write, the same way a type or a NOT NULL is enforced. They are not documentation you're encouraged to keep up to date. They are a condition of the data existing at all.
That one move dissolves the drift, because drift needs two things that can disagree. A separate layer is a second artifact — the data, and a description of it — and keeping the two aligned is a job someone does forever and eventually stops doing. When the meaning is part of the definition, there's only one artifact. It can't fall out of sync with itself: complete, because the system refused anything incomplete; current, because it isn't a copy of the truth — it is the truth, written down as the data goes in.
This is the whole idea. Everything else is a consequence of it: a database forced to carry its own meaning is a database that can finally describe itself, to anyone — human or machine — that asks.
What changes when the database describes itself
That single move pays off in three places. The first is the one we set out to fix. The second comes almost for free. The third is the one most people miss, and it's the one that convinces engineers.
Correctness: the agent stops guessing at the source
An agent connects and asks what exists. It gets back not just column names and types, but what each column means, who owns it, whether it's current, and what it must never contain. It writes the right query because the database told it which one was right, in terms precise enough to act on. The correct answer becomes the easy answer — not because the model got smarter, but because the data finally said what it was.
This is the difference between an agent you can trust and one you have to double-check. When the meaning is in the data, the agent isn't interpreting your schema and hoping. It's reading a description the database guarantees is complete and current. The guessing doesn't get cleaned up downstream. It never starts.
Consolidation: one database instead of a stack of separate tools
Think about what each tool in a modern data stack actually is. A catalog is a description of what your data means. Lineage is a record of where it came from. A freshness monitor is a claim about how current it should be. A metrics layer is an agreed definition of a number. Each is a product today — bought separately, integrated at cost, and each drifting from the data on its own schedule.
But every one of them is just a view of the same underlying thing: the data's enforced description of itself. Once that description exists and cannot drift, you don't need four tools maintaining four shaky copies of it. You need one database that already knows.
This isn't a bundle — four products sold under one invoice. It's a reduction. Most of those tools existed only to compensate for the database's silence, and a database that speaks doesn't need them.
Optimization: the same knowledge serves the engine, not just the reader
An engineer can rightly object here: mandatory annotations sound like a tax. Every table comes with paperwork; every write has to satisfy rules someone wrote down. That's friction, and friction is the thing most data tools spend their lives removing. So why build the opposite?
Because the same knowledge that serves the reader also drives the engine — and that second payoff stays invisible until you look for it.
Take one example. Declare that a column only ever counts upward — an invoice number, a timestamp, a running total — and you've told an agent how to read it. You've also told the storage engine the values are ordered, so it can store the differences between them instead of the full values, and the column gets dramatically smaller on disk. One declaration, two uses. Lineage works the same way: the record that lets a person trace a number to its source is the record that lets the engine recompute only what changed, instead of everything downstream.
Here's the cleanest way to see it, in terms most engineers already carry. Rune's mandatory annotations are to the database what static types are to a compiler. A type is documentation for the human reading the code, and it is also an input the optimizer uses to generate faster output. Nobody calls static types two features. They're one constraint with two payoffs, and the second — the faster program — is the one you don't notice until someone points at it. Rune's mandate has the same shape. We introduced it to make data legible to people and agents. It turns out to be exactly the machine-readable structure an engine needs to optimize itself.
I want to be careful here, because the claim is easy to overstate, and we won't. Most of what that inward-facing structure makes possible, we haven't built yet, and the argument doesn't depend on us having built it. The claim is structural, and it's true today: these are optimizations available to a database that owns a complete, enforced description of its own data, and barred to one that doesn't. A bolt-on catalog or an optional semantic layer can't drive an engine it sits outside of and only partially describes. That's not a feature we're ahead on. It's a door this design leaves open and the others leave closed. The thing an engineer might read as overhead is, structurally, the fuel.
But doesn't a catalog already do this?
A fair question, and the big platforms are betting the answer is yes. Over the last year Snowflake shipped Semantic Views and Databricks shipped Metric Views — both built so an agent stops guessing which number to trust. Meaning matters; on that, everyone now agrees.
But look at where their meaning lives: in a layer beside the data, not inside it. A layer beside the data is optional, so it only ever describes the slice someone modeled. It's separate, so it keeps asserting what was true before the table changed underneath it. And it's bounded to one platform, so it goes blind the moment your data crosses a system boundary.
The problem isn't that they guess — they don't. It's that a description living apart from the data is always partial and always drifting, because nothing forces the two to agree. The gap isn't a bug they'll fix. The gap is the design.
What we refuse to build
Some of what we believe shows up most clearly in what we've decided not to do.
Rune is not an AI product. It does not generate your SQL, translate your questions, or decide anything on your behalf. It provides context, and every answer it gives is deterministic — the same question against the same data returns the same result, every time, with no model in the path to be clever or wrong. The reasoning belongs to your agent. The meaning belongs to the database. We're not interested in blurring that line, because the moment a database starts guessing on your behalf, it has the very problem we built this to solve.
We won't embed a chatbot, either. The obvious move for a company in this space is to bolt a model onto the product and call it intelligence. We think that's backwards. Your own agent — with your context, your history, your choice of model — is already better than anything we'd staple on, and it gets better every month without us lifting a finger. Our job is to feed it the truth, not to compete with it. The advantage we're building isn't a model. It's the meaning underneath, which a model can't manufacture and only a database can enforce.
And we won't relax the mandate to make the first five minutes feel easier. Optional governance is how you end up exactly where everyone already is: a description that covers what someone got to and drifts from the rest. When the annotations feel like friction, the answer is to have agents help write them — never to make them optional. The mandate is the foundation. It is not a rough edge to sand off.
What we're building
A database that understands itself. That's the whole of it.
That self-understanding points two ways, both from the same enforced source. Outward, it gives the people and agents reading the data something a database never offered before: meaning they can trust, complete and current, so the answer comes back right instead of guessed. Inward, that same structure gives the engine what it needs to run itself well. One asset, coupled to the data so it can't drift — trust on the outside, autonomy on the inside.
The reason to build it now is that the cost of not having it just changed. When humans were the only ones asking, a database that stayed silent about its own meaning was survivable, because we filled the silence ourselves. Now the things asking can't. They'll take our silence as permission to guess, and they'll do it fast, at scale, and with total confidence. A database that can finally say what it means isn't a convenience anymore. It's the difference between an agent that's right and an agent that's confidently wrong — and we'd rather build the first one.