Someone asks a plain question: how many customers did we add in September? The warehouse has four tables that could answer it. users is a login. accounts is the company that pays. billing_contacts is a person on an invoice. crm_people is whoever sales typed in this quarter. All four have a date column, and three of them have "customer" somewhere in a comment or a foreign key.
The assistant picks users.created_at, counts the rows, and returns a number with a short explanation of the SQL. The number is arithmetically right and commercially wrong. Product wanted people who signed up. Finance wanted accounts with a paid invoice. Sales wanted companies that have an open opportunity. The answer does not say which of those it chose. The wrong definition is invisible inside a confident sentence.
That is the hard part of using AI on business data. The model does not arrive knowing what "customer" means in your company. It knows what the word means in general, and it can see column names. It will pick a likely one.
The definition is the missing input
A schema tells you the shape. users.id is an integer, accounts.id is an integer, and invoices.account_id points at accounts. Nothing in that shape says which row a "customer" is when the board asks for a count. The meaning lives in the way finance closes the month, in a footnote on a slide, or in the head of the person who built the first dashboard. An assistant that only sees tables does not see any of those.
The failure mode is quiet. A query that joins the wrong table often errors, and someone notices. A query that counts the wrong entity returns a tidy integer. People forward tidy integers. By the time the argument starts, the original question has been forgotten and two teams are defending two counts.
The same collision happens with "order" (placed, paid, shipped, or returned), "active" (logged in, billed, or not cancelled), and "last month" (calendar, fiscal, or trailing thirty days). The model will choose. It will not show the choices it discarded unless you read the query. A larger model can be fluent about invoices and still not know that a billing contact is never the customer you count.
Why the usual tools leave the meaning on the floor
A SQL client will run the right query once you know which table is the customer. It will not store the sentence that says so, and it will not stop the next person from counting users because that table is first in the sidebar. The knowledge stays with the person who already had it.
A BI tool can hold a measure called Customers, and a good semantic model is exactly this sentence made queryable. Many teams do not have that model. They have a workbook per analyst. Each workbook picks a column. The names match. The filters do not. When an assistant is pointed at the warehouse instead of at the model, it never sees the measure. It sees the tables the measure was supposed to hide.
A spreadsheet makes the column header do the job of a definition. "New customers" in row 1 is whatever was pasted underneath. Next month someone pastes users because the export was easier to pull. The header stays. Excel will not argue.
A text-to-SQL chat on one database is fluent and under-informed. It reads names. customer_id looks like the answer even when your company uses account_id for the paying relationship and customer_id for a legacy import that nobody has dropped. The chat has no place, unless you built one, to read "for revenue questions, customer means an account with a paid invoice." If that sentence exists only in a wiki the assistant was not given, the assistant will answer without it and sound finished. A client runs SQL. A chart shows a measure someone already defined. A sheet calculates a range. None of those tools are required to know what your company means by customer.
Write the sentence down, then make the assistant use it
Pick the ten words that cause arguments. Customer, order, active, revenue, churn, and the date you mean by "last month" are enough to start. For each one, write a sentence a new teammate can apply:
Customer, for a revenue question, means a row in accounts with at least one paid invoice. A user is a login. A billing contact is a person named on the invoice and is not a customer count.
Put the grain in the same sentence. One row per account, not per user and not per contact. Say which date decides "added in September": the invoice's paid date, the account's created date, or the first paid invoice's date. Those are three different counts, and all three are defensible until you pick one.
Keep the sentence next to the schema, in a file the team already opens. A markdown file beside the migrations is a fine place. A wiki page nobody links from the repo will lose. When you ask an assistant, put the sentence in the question: "Count accounts with a paid invoice in September. Do not count users." The sentence in the question is the check you can see.
MeaningGraph is an open registry for shared data definitions. People keep them in a Git repository, reuse a definition another project already wrote, and contribute a change the same way they contribute code. A "customer" that your whole company agrees on can live there as a meaning with a source revision, so the next project does not invent a fourth one. That registry is useful on its own. datatug.app's knowledge-graph page marks the DataTug integration with MeaningGraph as planned, so do not treat a definition on meaninggraph.io as something DataTug already reads for you. Write it, point the assistant at it, and read the query.
When two people disagree, compare the sentences before the numbers. Most of the time the tables are fine and the word was doing two jobs.
Where DataTug fits
DataTug does not add a business glossary on the page the product shows today. What it does show is the path from the question to the evidence. In AI chat it plans the query, runs it, and shows the query and the rows behind the answer, on the databases and REST APIs the project opens. The sources marked as working today are SQLite, PostgreSQL, MySQL, Oracle, SQL Server, BigQuery, inGitDB, and REST APIs. You can do that from the web app, the terminal UI and CLI, or the chat.
That is enough to catch the September mistake, if you look. The planned query names users or it names accounts. The rows are logins or they are paid accounts. You still have to know which one you meant. The sentence you wrote is how you know. The product shows you what it used.
If you want to see that pattern before you connect your own data, the demo opens without an account. Personal and public projects are free. Bring the definition of customer with you. The model still will not arrive with it.
Pain pointsNext: A renamed column, and no list of what breaks