The Three Layers
When you work with a database, meaning does not live in one place. It is distributed across three things that are related but not the same, and I was instinctively aware of this distribution long before any AI tool existed to reason across it.
The first is the schema. This approximates what logicians would call the formal intensionThe defined meaning of a term or relation, i.e. what it is supposed to mean, rather than which specific cases currently fall under it.: the specified meaning of the relation, expressed partly through its structure and constraints, although not exhausted by them. C.J. Date and Hugh Darwen stated that a relation (table) in a relational database should be understood as a predicate statementIn relational theory, the claim a table is making about the world, i.e. what must be true for a row to belong there. rather than a container. A table called ACCOUNT_PAYOUTS with a column payout_amount FLOAT is a claim: for every row in this table, there exists an account for which a payout of this amount was calculated under these conditions. That last part, calculated under these conditions, is not in the schema. The schema says payout_amount FLOAT; the predicate supplies the meaning, and the schema is the contract. It defines not just what values are permitted, but what the data is permitted to mean, even if it does not fully embody that meaning on its own.
The second is the data itself. This is the extensionThe actual set of cases that currently fall under a term or relation, i.e. the records that exist right now.: the actual population of records, the values that exist right now. The data tells you what the system currently treats as true about the world, under the closed world assumption, where what is absent from the database is taken to be false rather than merely unknown.
The third is the query history, and this is where Wittgenstein becomes relevant. He would tell us that meaning is not in definitions; it is in use. The schema tells you what a term is permitted to mean, as encoded in the intension. The data tells you what values exist. But the actual meaning of a field in practice, how it was calculated, what business logic produced it, what it implies for a decision, is often clarified only by how the system has been used over time. The query history is the record of that use, and in my experience it is often closer to the practical meaning of a field than either the schema or the data alone.
This is also why the phrase "semantic layer," as it is commonly used in the data industry, only gets you partway there. A semantic layer typically captures intension well, and it gives a cleaner view of the data than the raw schema does, but it misses the third layer, where meaning lives in practice. Going beyond the semantic layer means reasoning over how the data was actually produced and used, not just how it was defined.
Why the Schema Is Not the Meaning
I have watched this play out directly in troubleshooting work. A metric that reconciles cleanly on paper can fail to add up across two systems that both claim to compute it, and the explanation is rarely visible in either schema. It tends to surface only once you trace how each system actually populated the field over time, which fallback logic ran when a required input was missing, which upstream change quietly altered what a column had meant for the previous six months. The meaning was never encoded anywhere a schema diagram would show it. It was in the query history and the transformation lineageThe record of how data was produced or changed across queries, models, or pipelines., which is exactly the kind of evidence Wittgenstein's account would predict matters most and that a purely structural view of the data would miss entirely.
I have also seen the opposite problem: a tool or a person reasoning from incomplete evidence toward the most plausible explanation rather than deducing an exact answer from exact inputs. A single mistyped digit in an account number, with no exact match anywhere in the data, can still be resolved correctly if something in the system forms a hypothesis about what was probably meant rather than simply failing. That is closer to what Charles Sanders Peirce called abductionInference to the most plausible explanation or hypothesis from incomplete evidence., reasoning to the most plausible explanation, than to the deductive reasoning a query engine performs by default. It is worth naming as a distinct mode of reasoning, because more of the useful behavior in database work, human or automated, looks like abduction than most discussions of "querying data" assume.
The Closed World Assumption
Databases operate under what logicians call the closed world assumption. If something is not in the database, it is not true for the purposes of the system. This is what makes reconciliation possible at all: you can declare a gap closed, say the numbers add up, and trust absence to mean something rather than nothing.
That closure is always relative to what the system was built to know about, not to the world at large, and this shows up clearly whenever two systems have no natural awareness of each other. Neither billing system's absence of a record about the other counts as evidence of anything, because neither was ever in a position to know; each is closed correctly over its own domain, and neither domain includes the other. Closing that kind of gap requires two things: a technical path connecting the two systems, and someone who understands the organizational landscape well enough to know the second system exists and is relevant in the first place. The technical path closes the access gap; a human closes the knowledge gap.
Conclusion
Meaning in a database is not a property of any single artifact. The schema states an incomplete intension; the data supplies an extension that is only ever complete relative to what the system was built to know about; and the query history carries the use that Wittgenstein's account says constitutes meaning in practice, often more reliably than either of the other two layers on its own. A system, or a person, that reasons across all three is doing something closer to how an experienced practitioner actually comes to understand a database than either a schema browser or a query tool does by itself, and it is worth having language for that distinction, since most conversations about "understanding your data" still stop at the first layer or the second.
References
- Date, C.J. and Darwen, H. Databases, Types, and the Relational Model: The Third Manifesto. 3rd ed. Addison-Wesley, 2006. Source for the claim that a relation variable represents a predicate, its intended interpretation, and that this intension is not fully captured by the schema's structural constraints alone.
- Wittgenstein, L. Philosophical Investigations. Blackwell, 1953. Translated by G.E.M. Anscombe. The source for the meaning-as-use argument, at §43, with the qualification that it applies to a large class of cases rather than all of them.
- Peirce, C.S. "How to Make Our Ideas Clear." Popular Science Monthly, 12 (1878), pp. 286-302. Source for the pragmatic maxim and the broader account of abduction as reasoning to the most plausible explanation from incomplete evidence.
- Date, C.J. Logic and Relational Theory (unpublished manuscript, referenced chapter on the Closed World Assumption). Source for the closed world assumption as it applies to relational databases, and for the distinction between a closed world over a defined predicate and a claim about the completeness of reality itself.