Three rules

First, a model's output is a candidate, not a decision; execution, publication and verdicts happen only after declared contracts and checks pass. Second, execution has boundaries fixed in code: read-only roles, time and cost caps, tenant scope, and a permission recheck at approval time. Third, evidence and unknowns stay with the result: numeric checks, audit trails, approval and correction history, and the state 'unknown' are never deleted.

The three rules the four engines share1 · Candidate → decisionmodel outputchecksExecution, publication andverdicts happen only afterdeclared contracts and checkspass. Output is a candidate.2 · Boundaries in coderead-only rolestime and cost capstenant scopepermission recheck at approvalThe boundaries live in code,not prompts. A changed contextor a revoked grant stops evena prepared query.3 · Evidence stays visibleresultnumeric checksaudit trailapproval, correction history'unknown' kept as a stateNever deleted. Whoever readsthe result sees how far it was verified.
The three rules on one sheet: model output is a candidate, boundaries live in code, evidence and unknowns stay with the result.

One rule set, four implementations

In the Text-to-SQL engine the first rule appears as SQL syntax-tree validation: Insert, Update, Delete, Merge, Create, Drop, Alter, TruncateTable, Command and Copy nodes and unresolved parameters are rejected before execution, and even an accepted query runs only under a read-only account, a statement timeout and an EXPLAIN cost cap. In the controlled-generation engine the database decides reference scenes and the beat plan, the model composes within them, and a draft that fails its checks is not published. The knowledge-publishing engine builds every output from one business-approved snapshot and publishes nothing without proof of site control. The document-reasoning engine's rights-analysis decision function is a rule engine that calls no model at all.

One rule set, four implementationsWhat the model proposesWhat the system decidesText-to-SQLdrafts an SQL candidateAST validation · read-only accountstatement_timeout · EXPLAIN cost capControlled generationcomposes within the referencescenes and beat plan it is giventhe database decides scenes and beatsa draft that fails its checks is not publishedKnowledge publishingAI search stands on the reading sideevery output from one business-approved snapshotnothing published without proof of site controlDocument reasoningexplanatory output only (e.g. narration)rights-analysis decision = a rule enginezero model calls
How the first rule appears in each of the four engines.

Where the model lives

Enterprise data must not cross the customer boundary. Since June 17, 2026 the Text-to-SQL engine supports an on-premise small-LLM provider (OpenAI-compatible API), so model and prompts can stay inside the customer. The controlled-generation engine receives its LLM call as an injected function, so the packet and check layers survive a change of base model. No engine stakes the correctness of its results on the quality of one particular model.

Data adapters and the runtime

The Text-to-SQL collector has adapters for PostgreSQL, MariaDB/MySQL, Microsoft SQL Server, Oracle (including 11g) and SAP HANA. Each adapter records in code and tests what its read-only second line of defence is (for HANA, SET TRANSACTION READ ONLY), whether it supports EXPLAIN, and what protects execution when it does not. Since September 17, 2026 the deployment tool runs acceptance checks before it touches a site.

Data adapters and execution guardsPostgreSQLMariaDB / MySQLSQL ServerOracle (incl. 11g)SAP HANACollector adapters — the read-only second line is recorded in code and testse.g. HANA: SET TRANSACTION READ ONLYWith EXPLAIN: refuse when estimated cost or rows exceed the capWithout EXPLAIN: fall back to timeout and LIMITGuarded executionSince 2026-09-17 the deployment tool runs acceptance checks before it touches a site.
Five adapter families, the read-only second line of defence, and execution guards with or without EXPLAIN.

How failures are handled

All four engines write failures down instead of deleting them: the record of few-shot examples ending with zero improvement across five live checks; the day we stopped after finding 6,460 column descriptions with Korean business terms replaced by English abbreviations; serial episodes rejected for repeated endings; AI-search re-measurements that still showed zero mentions. Those records made the next decisions faster, and they are the source of the boundary sentences on this site's technology pages.