It always ends up
relational.
Every pipeline, lake, bucket, and medallion layer flows into tables, because that's where most business value is obtained. GRAM compiles a table into binary facts, a semantic graph that can govern, conceptualize, and be used to accurately reason over your data. We couple the power of the open-world language interface of A.I. with the self-contained world of your relational database.
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.
Everyone keeps claiming that shaky database foundations are an epidemic that impairs A.I. rollouts and initiatives. However, in our experience, your database is most likely normalized, keyed, constrained, and it has been successfully running your business for years. What was missing is the layer that links the physical data to the business concepts.
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.
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.
The industry is investing in descriptions, synonyms, and verified examples: the layer the model can set aside. We formalized the layer it cannot.
- 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.
Every other semantic layer is documentation somebody maintains. 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.
- 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.
Every semantic layer on the market asks you to define your measures up front. Two quarters of committee work, four hundred YAML definitions, most 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.
Three instruments on one substrate.
Grammar models the graph. Dashboard answers with it. Analyst investigates with it.
Grammar
Connects to any relational database. Select the entities of interest and the compiler produces the graph.
Refinement happens on a visual canvas with plain-English prompts: the conceptual model and the physical schema, reconciled in one place.
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.
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 →