Reliable Natural-Language Analytics

A validation-first architecture for asking questions about public-sector analytical data in natural language.

In my current work, I develop an internal applied AI system for querying public-sector analytical data in natural language. I describe only the non-confidential architecture and engineering principles here; I do not include private schemas, data, URLs, screenshots, or performance claims.

  1. Natural-language question
  2. Ontology and schema grounding
  3. LLM-generated candidate SQL
  4. Structural and schema validation
  5. Restricted read-only execution
  6. Validated result and visualization

Problem

Syntactically valid SQL is not sufficient. A generated query can reference the wrong concepts, violate access rules, exceed operational bounds, or produce a misleading presentation.

Why it matters

The system connects model behavior, data semantics, database permissions, and user interpretation. Each of these layers can introduce a failure, so I treat reliability as a property of the whole path rather than of a single prompt or model response.

Approach

I ground each question in an ontology and the available schema before the model proposes a structured query. Independent checks examine the SQL structure and schema references. A restricted read-only role executes the validated query within defined bounds. Visualization selection is deterministic or validated separately.

Evaluation and evidence

I use reproducible test cases, provider comparisons, failure analysis, and regression tests. Structured outputs and deterministic fallbacks reduce ambiguity in parts of the system that do not require model flexibility.

Engineering principle: treat model-generated output as untrusted until it has been independently validated.

Technical implementation

My work spans stakeholder requirements, data ingestion, PostgreSQL modeling, ontology and schema grounding, Text-to-SQL, FastAPI and Pydantic services, REST APIs and WebSockets, Metabase and frontend integration, containerized deployment, testing, security controls, and operational support.

Technologies used across the system may include PostgreSQL, pgvector, SQLGlot, Gemini, Ollama, Redis or Valkey, Docker Compose, Nginx, and GitHub Actions. Their roles are architectural, not a claim about scale, certification, uptime, or guaranteed correctness.

Engineering principle

I treat model-generated output as untrusted until the surrounding system has grounded, validated, and constrained it. Permissions, execution bounds, fallbacks, and regression tests are part of the AI feature rather than supporting details.