It always ends up
relational.
Get the model right and nobody has to be talked into the dashboard. They come back with the next question. That model is what GRAM builds.
See it work
Three instruments on one substrate.
Grammar models. Dashboard answers. Analyst investigates.
Grammar
Three ways in. Model a domain in sentences before any database exists, reverse-engineer a live one, or import a Power BI template and take every field or only what the report uses.
Refinement happens on a visual canvas with plain-English prompts: the conceptual model and the physical schema, reconciled in one place.
Once a graph is connected, it keeps checking itself against the live schema and shows you what moved.
Dashboard
Ask in plain English, get a chart or table back, pin it to the grid. The board accumulates from the questions your team actually asks.
Mobile-friendly and read-only. Ad hoc answers become live widgets on the spot.
Analyst
Give it a "why" question. It plans query paths, runs SQL against the graph, reads the rows, follows up, and maintains context over long investigations.
When the graph lacks the answer, it says so.
Conceptualization became optional, then it went obsolete.
Somewhere between self-service and the cloud, conceptual data modeling stopped being anyone’s job. The efforts focused on data movement; the meaning was left to take care of itself.
Your database is most likely normalized, keyed, constrained, and it has been running your business for years. The foundation is sound. What was missing is the layer that links the physical data to the business concepts.
That layer went missing for an ordinary reason: nothing in the workflow ever asked for it. Pipelines run without anyone stating what one row means. Reports ship without anyone declaring which customer is the customer. The tools never asked, so the answer was never written down, and a discipline that was once taught quietly stopped being taught.
The work lives on the boundary between the conceptual and the physical. GRAM is a language for that boundary, grounded in Object-Role Modeling and four decades of fact-based modeling research.
Every stack leaves one seat empty.
Storage is solved. Movement is solved. Transformation is solved, versioned, and tested. The seat still empty is the declaration: the place where the business states what the data means and someone signs it.
It stayed empty because the declaration never had an artifact. It lives in tribal knowledge, in a column comment, in the head of whoever wrote the query. GRAM gives it a shape: a closed-world graph with the constraints stated, speaking the database’s native theory of predicates, keys, and functional dependencies.
The keys, the cardinality, and the participation rules are what a hint layer leaves out. Handed the facts instead of the hints, a model reasons to the right query on its own.
And because it is a document, it takes that seat inside whatever you already run. Your pipelines keep their job, your warehouse keeps its job, your assistant keeps its job. The graph is the governed reference their generated context has been missing: the semantic system of record, in git, next to the pipelines it serves.
Facts you can read out loud.
Every relationship in a GRAM graph is a fact type with a natural-language reading: a sentence. The sentence is the model.
This method has deep roots. Fact-based modeling came out of linguistics research in the 1970s and has been compiling conceptual models into production schemas ever since. The sentences were written for humans, but now there are machines that also read.
Here is what our research found when we tested that: the machine does not need the verbs. Replace every predicate with a generic label and the SQL comes out the same, provided the constraints and role names survive. The sentence is how the business checks the model. The constraint is why the query is right.
We tested the harder direction too: a graph built in invented vocabulary, terms no model has ever encountered, with the constraints intact. The queries came back correct. Where a run did fail, the diagnosis pointed every time at a carrier the graph had not yet declared, and each one became a fix. Unfamiliar words were never the problem. Descriptions and synonyms help a model guess; declared structure removes the guess.
- The fact “Each Order is placed by exactly one Customer.”
- What it carries A relationship (Customer to Order), a cardinality (one-to-many), a participation rule (no orphan orders). Uniqueness and mandatoriness, stated in one sentence, held even where the schema is silent.
- What it determines An INNER JOIN, the join key from Customer’s reference scheme, grouping that cannot double-count. Computed from the constraints.
- Who can check it Anyone who knows the business. If the sentence is wrong, the model is wrong, and you can see it without reading SQL.
The model reads the graph, not the schema.
The DDL never reaches the model. The LLM sees the graph layer, the structural contract derived from the schema, and writes SQL only against paths the graph declares. Given the cardinality and the keys, it knows which join to write and what can be null. The model works for the analyst; the graph is what keeps it honest. Accuracy lives in the structure, so it survives every model upgrade.
A tool-using LLM, harness or custom app. Receives the graph layer; never the raw DDL. Writes SQL against paths the graph declares based purely on relational logic.
An open specification, compiled mechanically from a relational schema. Binary facts, cardinality, mandatoriness, role names. The contract every query is bound to. Build it here with Grammar and use it with any LLM or database.
Any relational database, secure and read-only. This is your data warehouse, your operational data, HR data, finance. The database is anonymous to the LLM.
The reading surface between models and relational data.
Coding assistants work because the file system and the type graph are right there to read. Relational data never had that reading surface. GRAM is that surface.
A GRAM graph is a compiler output. Point our flagship app, Grammar, at the database and the structural layer exists in minutes, not quarters: keys, cardinality, and participation read from the schema, ready for the business to check in plain sentences. Documentation drifts. Compilations rerun.
The warehouse still matters. Facts, dimensions, star schemas: the graph puts their design in the non-technical analyst’s hands, drawn with structured visual syntax on a canvas, instead of buried in a pipeline repo.
- Chat experience Plain-English Q&A over the database. Available the moment the graph lands.
- Agentic analyst A tool-using loop that runs queries, evaluates findings, and writes briefings. The Analyst in this stack is one instance of the shape. We proved the seat is real by building a second one from the published API alone, with no access to our internals, and it answers correctly.
- Domain copilot Claims investigator, procurement copilot, store-ops analyst, HR-comp auditor. The loop is the same; the graph underneath changes.
- Self-built dashboard A board whose cards accumulate from the questions a team actually asks.
- Something else A class of app not yet named. The substrate is indifferent to the shape on top; it only requires that the model has a structural surface to read.
The metric you need next quarter has not been defined yet.
Define the measures up front and here is how it goes: two quarters of committee work, four hundred definitions in YAML, most of them never queried. Then the CFO asks the one question nobody anticipated, and the library has no entry for it.
GRAM inverts the order. The graph declares what cannot be inferred: the keys, the cardinality, the participation rules. The measures crystallize when someone asks. A Pareto breakdown, a weighted discount rate, a customer-ramp cohort: nobody defines these in advance. The model derives them live, from the constraints and the conversation, and shows its work.
When a derived measure earns its place, you pin it. The SQL freezes in the widget. Consistency is achieved by ratification, not by pre-agreement.
Your dashboard is the metrics library. It writes itself, one ratified question at a time.
The business takes the meaning back.
A GRAM graph is a deliverable, a diagram, a compiled contract for the AI model, a file for the repo, identical against every engine.
The database is physical storage. It cannot carry every rule the business lives by. The graph can, and it locks them in, whether or not the schema enforces them.
Whether a field may be empty is a business decision. Even the meaning of a join is a business decision. For twenty years those calls have drifted into the engineering backlog; GRAM moves them back, with simple models the business can read and change.
That is governance in its first sense: control of what the data means. The pipelines stay with the engineers. The meaning belongs to the business.
Your data stays where it is.
Every feature that touches the database was built security-first; the constraints below are enforced on every request.
Structural hallucination is unrepresentable
Accuracy scores are measured. We built the other thing. The model cannot name a table that does not exist. The validator will not run a join the graph does not declare. The headline figures are validated against the rows that produced them. Structural hallucination is not rare here: it is unrepresentable. The error surface reduces to interpretation alone, and interpretation is disclosed.
Read-only enforcement
All queries are validated server-side before execution. Write operations are blocked at the application layer. Your data can never be modified through GramSpec Tools.
Encrypted credentials
Database passwords are encrypted at rest. Never sent to the browser, never included in AI prompts, never leave the server unencrypted.
Two-factor authentication
TOTP-based MFA on every account. Pair with any authenticator app. Recovery codes included.
Audit logging
Every query execution is logged with user, timestamp, duration, and result. Full traceability for compliance and troubleshooting.
Rate limiting
Per-user throttling on queries and AI requests prevents abuse and protects your database from excessive load.
AI isolation
The LLM never sees your raw schema, connection strings, or credentials. It only sees the GRAM layer. Nothing else.
Read the spec. Compile a graph.
The specification is the substrate; the reference tools are one expression of it. As far as your analysis goes, the sky is the limit.
Sign In → Read the spec →