Mnemiq: From Text-to-SQL to Governed Data Agents

SQL that runs is only part of the answer

Suppose someone asks a data agent for last quarter’s revenue by customer. A query can compile, execute, and return plausible numbers while still being the wrong response. The requester may lack access to customer-level data. “Revenue” may mean bookings to one team and recognized revenue to another. The source may not contain the requested measure at all.

An enterprise deployment needs to decide whether the agent may answer, what the answer means, and what evidence will remain afterward. Generating SQL is one step in that decision.

Mnemiq is Agentic Fabriq’s open-source text-to-SQL engine and the upstream foundation for the independent Enterprise Data Agent Governance project. This article looks at how the two projects relate and how to turn governance requirements into deployment checks.

What Mnemiq provides

Mnemiq makes the path from a question to a database answer inspectable and configurable. Teams can choose models, retrieval settings, semantic enrichment, and verification settings, then evaluate those choices on their own data. The engine is Apache-2.0 licensed and can run in an organization’s own environment.

Governance is already part of that path. Mnemiq separates SQL generation from execution checks. Its read path checks proposed SQL against access policy and query constraints, compiles it for the source dialect, and uses EXPLAIN before execution. Access policy also limits schema retrieval. Answer traces expose the executed SQL, accessed tables, and enrichment version.

These controls need to be understood in the context of the deployed configuration. A query gate does not establish who an upstream application’s user is. A trace is not, by itself, a retention policy. Source credentials and database configuration remain part of the deployment’s control boundary.

Our Mnemiq launch article explains the engine and evaluation approach in more detail. Its central principle applies here too: measure the behavior on your own database before relying on it.

A live, independently maintained governance framework

Enterprise Data Agent Governance is a publicly available, independently maintained open-source governance framework built on Mnemiq. Its reference site organizes governance into testable controls, an evaluation method, and an evidence map connecting selected controls to version-pinned Mnemiq behavior.

The framework explores identity, authorization, meaning, query safety, verification, refusal, lineage, and operations. Its published evaluation material distinguishes questions that can be answered, questions that need a business definition, and requests that should be refused. That makes it useful for asking concrete questions about a deployment and the evidence needed to assess it.

Mnemiq remains the original upstream engine in this relationship. The framework is complementary and separately maintained; it is not an Agentic Fabriq product or a formal partnership. Its public materials are a starting point for evaluation, not evidence that a particular customer deployment is production-ready.

Make each deployment decision explicit

For the revenue question, work through the request in order. The following are deployment checks, not a claim that either project supplies every surrounding service automatically.

Identity and authorization

Establish the agent’s identity and, when it acts for a person, the requesting user’s identity. Bind those identities to the permissions used by the data service. A role supplied in a request is trustworthy only if the application has authenticated and authorized that assignment.

Check that the permitted schema is selected before retrieval and that the execution path enforces the same access boundary. Test with two callers who have different permissions: identical wording should not give them identical access. Repeat after revoking a grant.

Meaning and query safety

Define the measure before accepting its SQL. For revenue, record the governing definition, reporting period, currency, and treatment of refunds. If the request remains ambiguous, ask for clarification instead of silently choosing a convenient interpretation.

At execution, use restricted source credentials alongside query checks. Verify the deployment’s handling of unsupported statements, expensive queries, timeouts, and database-specific behavior. A syntactically read-only statement and a safely configured database are related but separate concerns; the source adapter’s deployment guidance matters.

Verification and refusal

Decide what evidence is required before returning an answer and what happens when that evidence is unavailable. A verifier timeout should not silently become an approval. A source missing the requested revenue measure should not cause the agent to substitute another numeric field.

Record different outcomes for clarification, unsupported data, denied access, execution failure, and failed verification. Give callers enough information to take a useful next step without revealing restricted schema or data.

Auditability

Make it possible to reconstruct the decision. Record the requesting identities, applicable policy version and decision, executed SQL, permitted objects accessed, semantic definition version, verification outcome, and final response status where the deployment supports them. Check which fields the engine already emits and which the surrounding application must add.

Protect those records as data in their own right. An audit log can contain questions and query results that require access controls. Assign responsibility for retention, incident investigation, and changes to policy or business definitions.

Evaluate the whole decision path

Start with a small test set that includes permitted answers and deliberate boundaries. These are illustrative acceptance cases for your application, not reported benchmark results:

Report correct answers, incorrect answers, appropriate refusals, unnecessary refusals, and clarification outcomes separately. A system that refuses every question can avoid wrong answers while being useless. A system that answers everything can conceal serious access and correctness failures behind a high answer rate.

Rerun the cases when the model, schema, retrieval configuration, semantic definitions, permissions, or verifier changes. Keep the configuration and evidence with the result so that differences can be investigated.

Where to start

Choose one database scope, one application entry point, and a small set of real questions. Use Mnemiq to inspect and evaluate the query path. Use the independent framework’s controls to identify what the surrounding deployment must establish and prove.

Mnemiq’s role is the configurable database engine. Enterprise Data Agent Governance contributes an independent framework for examining governed data-agent behavior. Agentic Fabriq’s organization-level Agent IAM platform is a separate product concern: managing agent identities and access across an organization. Keeping those responsibilities explicit makes the next integration decision easier.

The useful milestone is a deployment whose answers, clarifications, and refusals can be explained from retained evidence. Start with the Mnemiq product overview and the launch article, then test that milestone on your own data.

Sources

• Mnemiq repository and README, linked above: engine behavior, configuration, and deployment documentation.
• Enterprise Data Agent Governance reference site, linked above: project relationship, governance domains, evaluation approach, and evidence map.
• Agentic Fabriq’s Mnemiq launch article, linked above: engine design and evaluation context.