Query check
Every query is checked against your real database before it reaches a user.
monthly_revenuePassesregion_revenuePassesgrowth_rateFails Repaired Passes
How Helia works
What Helia puts around a model call: what goes wrong without it, how output is checked, and how it holds up in production.
What goes wrong with a direct API call
Any engineer can call a model API in an afternoon. These are the things that should happen around that call, and don’t when an app calls a model directly.
- The model returns invalid JSONYour UI breaks. That’s a support ticket.
- Generated SQL fails, or worse, runs and liesBad SQL shown to a customer is a trust incident.
- A provider outage takes your feature downDowntime you didn’t cause and can’t fix.
- No record of what was asked or answeredNo answer when a customer asks “why did it say that?”
Helia is the difference between a demo and a product.
The inference-only design
Helia calls the model provider. It never connects to your database. See where Helia sits
No driver, no credentials, nothing to steal
That is the inference-only design. Helia holds no way into your data: it is the layer between your app and the model, and it works across providers.
What it does receive is what your app sends: the brief, the schema and, if you choose, a summary of your columns that includes sample values. Those are logged with the run.
Its output today: complete dashboards, with insights and queries, from a natural-language brief.
- No customer database credentials
- Helia has no way into your database, by design.
- Checked on your side
- Queries are checked against your database by your own application. Your database only ever talks to your app.
- Per-client API keys
- Every request is attributed to a client, and keys can be rotated.
- Every prompt and response logged
- What was asked, what was answered and how long it took: a full audit trail.
From a rough brief to checked output
A messy sentence or a screenshot still gets a good result, a failure is repaired instead of regenerated, and verification never makes the user wait.
Understand
A rough brief, in words or an image, becomes a clear one.
Generate
Helia writes the insights, the queries and the dashboard.
Checkpoint: Query check
Repair
What fails is fixed where it failed, not started over.
Checkpoint: Structure check
Verify
An independent review writes a verdict.
Runs after the response ships
Checks, not opinions
The usual answer to “is the output right?” is to ask another model, which is an opinion. Helia’s checks answer yes or no. A query either runs against your database or it doesn’t.
Structure check
Every dashboard is checked before it is sent. Malformed output never leaves the server.
- The layout is well formed Passes
- Every tile has data behind it Passes
- Nothing points at something missing Passes
What fails is repaired, then checked again. The independent review is a further layer on top, not the foundation.
No waiting for verification
The independent review runs after the response ships, so your users never wait for it.
Repair, not regeneration
One bad query does not mean a whole new run. Only the part that failed is written again.
Operable in production
What a model call needs around it once customers depend on it: something to fall back on, and a record you can replay.
When the model misbehaves, your users mostly don’t notice
Results stream as they are produced, so your interface can show progress while a run is under way.
Primary model
Fallback model
- Normal traffic goes to the primary model.
- The primary starts failing. Helia stops sending it traffic.
- Traffic goes to the fallback until the primary is healthy again.
- The right model for each step
- Each step uses the model that suits it, with another behind it.
- Automatic fallback
- When a provider errors, stalls or throttles, the fallback takes over. Your code does not change.
- Outages contained
- No retry storms against a failing provider: traffic skips it until it recovers.
- Cancellation
- A run can be stopped while it is in flight.
- Load protection
- Limits on simultaneous work keep the service steady under load.
- No repeated work
- A repeated request is recognised and is not run again.
Every run is a story you can replay
When something goes wrong, or right, you can replay it. Debugging, prompt iteration and quality tracking share one record.
understandgeneratequery checkrepairstructure checkverify (after)- The whole run, in order
- Every step and every attempt, with how long it took.
- Verdicts and ratings attached
- Review verdicts, retries and user ratings sit on the run they belong to.
- Versioned prompts
- Prompts change without a redeploy, and every run records the version it used.
- Feedback closes the loop
- Your users can rate a result, and the rating lands on the run that produced it.
Edits and chat, on the same governed path
Editing without regenerating
- Wasteful: the whole dashboard, generated again
- Destructive: users lose work they didn’t ask to lose
- Every query re-validated from scratch
- Only the change is generated
- Everything the user didn’t touch is preserved
- Only what changed is checked again
Rename the fifth chart to “Revenue, 2025”
One tile changed. The other five are exactly as the user left them.
An edit changes what was asked for, and nothing else.
Beyond dashboards: the same path for chat
- Skills. Named assistants set up per client, each for one job.
- A general chat endpoint. The same governed inference path, not a side door.
- Governance inherited. Same keys, logging, fallbacks and audit trail.
The data explorer takes the same path, for questions about your own data.
Build the trust layer into your stack once. Every AI feature after rides the same rails.
From brief to trusted dashboard
Your app, Helia and any model provider.
- Validated output
- No database access
- Full audit
The next step is a live generation on your schema. Send us a schema and a brief, and watch a validated dashboard come back with a full trace behind it.