From Question to Governed SQL: How SyteRay's Evidence-First Answers Work
Ask a general-purpose AI chatbot a question about your SyteLine database and it will answer confidently, whether or not the answer is true. It will invent table names that sound plausible, join columns that do not exist, and present a fabricated number with perfect fluency. That failure mode is why most ERP AI projects die in the demo stage. SyteRay was built around a different contract, which we call evidence-first: every answer over your live SyteLine data arrives with the exact SQL that was executed and the source tables it read, so any answer can be verified rather than trusted. This post walks through the pipeline that makes the contract enforceable, from schema grounding to query validation to the final rendered answer.
Why Generic Text-to-SQL Fails on SyteLine
SyteLine's database is large and idiosyncratic. The reference deployment's schema pack covers 1,970 tables, many with names that compress decades of naming conventions: co and coitem for customer orders and their lines, item for the item master, po and poitem for purchasing. Column semantics are subtle, statuses are coded characters, quantities live in multiple units of measure, and effective business meanings often depend on joins that are nowhere documented in the schema itself.
A language model prompted with a question and no grounding will pattern-match to generic ERP schemas it saw in training and produce SQL that looks right and runs never, or worse, runs and returns the wrong thing. The failure is structural: the model has no way to know your schema, so it guesses. Any serious system has to remove the guessing, not just prompt the model to be careful.
Step One: Ground Every Question in a Compiled Schema Pack
When SyteRay installs, it self-indexes your database and compiles a schema pack: a structured, queryable description of every table, column, key, and relationship in your SyteLine application database, including site-specific customizations and user-defined fields. On the reference deployment that pack covers 1,970 tables.
At question time, SyteRay does not hand the model the whole schema. It selects the tables and semantic views relevant to the question, along with their real column definitions and relationship paths, and grounds the SQL generation in that selection. Alongside the schema, a library of validated question-to-SQL examples, which we call golden pairs, gives the planner concrete, correct patterns for common SyteLine question shapes, so the model reasons about the shape of the question while the schema facts come from data, not memory.
Step Two: Enforce Before Executing
Generated SQL never runs unchecked. A query enforcer validates each statement against the schema pack before execution: every table must exist, every column must belong to the table it is used with, and joins must follow real relationships. A query that references a phantom table, a hallucinated column, or an unsafe operation is rejected and regenerated with the validation error fed back to the planner.
The enforcer also applies policy. Read queries are the default; anything that would modify data is refused on this path entirely and redirected to SyteRay's separate governed editing flow, which requires preview and explicit confirmation. The result is that the chat surface is structurally incapable of quietly writing to your ERP.
- Every generated statement is validated against the compiled schema before it touches the database.
- Phantom tables and columns are caught at validation time, not discovered by users in wrong answers.
- Write operations are structurally excluded from the question-answering path.
- Failed validations loop back to the planner with the reason, so regeneration is informed rather than random.
Step Three: Prefer Semantic Views for Business Definitions
Some questions are hard not because the SQL is complex but because the definition is contested: what exactly counts as an open order? SyteRay encodes those definitions once, as namespaced SyteRay_ semantic views created at install time, covering business concepts like open orders, bookings, and shipments. When a question maps to one of those concepts, the generated SQL reads the view rather than re-deriving the definition.
This is what keeps answers consistent across surfaces. The chat answer, the dashboard tile, and the Deep Research report all read the same view, so the same question produces the same number everywhere. And because the views are ordinary SQL objects in your database, your DBA can open them and read precisely what the definition is.
Step Four: Show the Evidence
The final answer renders with the number, the supporting rows, and the evidence: the SQL that was executed and the tables it read. This does more than build trust. It changes the failure mode. When something is wrong, the error is inspectable, a controller or developer can look at the query and say the filter should exclude credit holds, and that correction can be encoded back into the semantic layer or the golden-pair library so the whole system improves.
Evidence-first is ultimately a cultural stance as much as a technical one. ERP numbers drive shipments, invoices, and close decisions. A system that asks to be trusted without showing its work does not belong in that loop. A system that shows its work can be audited into becoming trustworthy.
Key Takeaways
- 1Generic text-to-SQL fails on SyteLine because models guess at schemas; SyteRay removes the guessing with a compiled schema pack covering 1,970 tables on the reference deployment.
- 2A query enforcer validates every generated statement against the real schema before execution and structurally excludes writes from the chat path.
- 3Contested business definitions live once, in SyteRay_ semantic views, so chat, dashboards, and reports always agree.
- 4Every answer ships with its SQL and source tables, making wrong answers inspectable and correctable instead of mysterious.
Want to see evidence-first answers against your own SyteLine database? Request a SyteRay demo or evaluation at ajay@netray.co.
More Insights
How SyteRay Classifies Every SyteLine Stored Procedure's Side Effects
A mature SyteLine site runs on thousands of stored procedures that nobody fully remembers. SyteRay crawls the whole catalog, 8,636 procedures on the reference deployment, and classifies what each one reads, writes, and calls, including transitive effects. Here is how and why.
SyteRayWhy We Built Semantic Views for SyteLine: One Source of Truth for Open Orders
When two SyteLine reports disagree about how many orders are open, the root cause is almost never a bug. It is two different definitions. SyteRay's semantic layer encodes each business definition exactly once, as reviewable SQL views, and everything reads from them.
SyteRayGoverned Record Editing in SyteLine: Preview, Confirm, Audit, Undo
Letting an AI read your ERP is easy to accept. Letting it write is where trust is decided. SyteRay's editing flow makes every change previewable before it happens, explicit to confirm, fully audited after, and reversible. Here is the design.