Use Governed AI to Turn Business Questions Into Reviewable SQL

Why the hard part is meaning, not SQL syntax

Oracle released Private Agent Factory 26.10 on October 26 with Deep NL2SQL, a Business Knowledge Graph and Knowledge Workbench for grounding questions in business definitions, rules, documents, example questions and validated SQL. The release also adds Python and REST integration, reusable ingestion and native observability. Oracle lists installers for Linux x86-64 and ARM 64, including Intel and Apple Silicon Macs; organizations still need to check licensing, database compatibility and support terms with Oracle.

A schema can show where revenue or order status is stored, but it cannot decide whether “top customer” means gross billings, collected cash, margin or something else. Deep NL2SQL is relevant because it treats definitions and ambiguity as part of the query workflow and can ask for clarification before generating SQL.

A focused Firecrawl search on October 27 returned Oracle’s release and fresh independent coverage dated October 26. That is a current-attention signal, not proof of traffic, search volume or ranking. Superpower Daily also stressed the practical constraint: experts must curate the definitions and validated examples, and Oracle’s conditional accuracy claims have not been independently verified.

1. Build the business context with accountable owners

Choose one bounded decision, such as weekly overdue invoices by region, instead of opening an assistant to an entire warehouse. Name the finance or operations owner for each metric, the database owner for each schema and the security owner for access policy.

In the knowledge workbench, record definitions, inclusions, exclusions, effective dates, join rules and representative questions. Pair each question with SQL that a qualified reviewer has already approved. Include counterexamples: refunds, reopened tickets, deleted accounts and late-arriving data often expose hidden assumptions.

Do not let raw user feedback automatically become shared truth. Oracle describes expert curation and tests for proposed knowledge changes. Treat that as a change-controlled artifact with version, reviewer, test results and rollback path.

• Start with one metric and one approved read-only data domain.
• Write the definition in business language and SQL-relevant terms.
• Keep validated examples small enough for a reviewer to understand.

2. Test the knowledge before exposing it to users

Create a regression set of representative, ambiguous and adversarial questions. Each test should specify the expected interpretation, permitted tables, key filters, maximum row count and either approved SQL or an explicit reason no query should run.

Include questions that differ by one word or time period. A reliable system should ask for clarification when “active customer,” “completed order” or “this quarter” is undefined rather than silently choosing a meaning. Compare results to the validated query and source totals, not to prose that merely sounds plausible.

Example prompt for an approved pilot: ‘Use only the supplied business topic and read-only schema. First restate the metric definition and date boundary. If any term is ambiguous, ask one clarification question. Then return proposed SQL, referenced tables, assumptions and validation checks. Do not execute until a named reviewer approves.’

3. Put database safety outside the model

Use a dedicated read-only identity with access only to approved views. Block data-definition and data-modification statements at the database or gateway layer, not through prompt wording. Apply query timeouts, row limits, cost controls and network restrictions. Mask or exclude sensitive columns before they become available to the agent.

Show the generated SQL and bound parameters before execution. Review joins, tenant filters, date logic and aggregations. For higher-risk domains, require a database owner to approve each new query pattern; for established patterns, allow only tested templates or a narrow policy engine to proceed.

Log the question, topic version, generated SQL, reviewer, execution status and answer provenance without copying unnecessary sensitive content into a second telemetry store. A model refusal or timeout should produce an explicit failure, never a guessed answer.

4. Review answers against source evidence

Return the definition used, the SQL, source tables, data timestamp, row count and validation checks with every answer. Require a human to compare a sample against a trusted report or direct query, especially after schema, business-rule or model changes.

Classify failures precisely: incorrect business meaning, invalid SQL, valid but wrong SQL, incomplete data, access denial or presentation error. That taxonomy tells the right owner what to fix and prevents a polished narrative from hiding a data-quality problem.

This article is an implementation guide, not a test of Oracle’s product. DeepSecurity.io did not install Private Agent Factory 26.10 or measure accuracy. The expected output is a reviewable query packet and cited answer, not an autonomous business decision.

5. Pilot with a measurable exit decision

Run the pilot on historical or synthetic data first. Track the share of questions that require clarification, the share that match validated SQL, reviewer time, unsafe-query blocks and failures by category. Do not convert vendor examples into local performance claims.

Before production, document ownership of definitions, test cadence, access recertification, schema-change alerts and incident response. Set a stop condition: repeated wrong-but-valid queries, missing provenance or unexplained access should pause the pilot until the knowledge or control layer is corrected.

The final handoff should include the approved question set, knowledge version, regression results, database role, query limits, telemetry locations, unresolved gaps and a named decision owner.