A system and method for generating queries against datasets using large-scale language models and schemas for improved data security.

Abstract

To provide a method for generating queries using natural language input and LLM, designed to preserve the privacy of the datasets on which queries may be executed. [Solution] A computer implementation method that accesses metadata and data specifying permission actions that specify fields of one or more stored datasets from a storage device, and generates a schema that specifies the fields that can be accessed in request response according to the metadata and data. Furthermore, it receives a data request based on the dataset from a client device, transmits the request and the schema to an artificial intelligence engine, and receives a dataset specification that includes a structured, machine-readable representation of the request generated according to the schema. The computer implementation method then compiles the dataset specification into a query according to the schema, and makes the query capable of executing the actions specified in the schema and accessing the data.

Description

Technical Field

[0001] Claim of Priority This application claims priority under 35 U.S.C. § 119(e) to U.S. Patent Application No. 63 / 724,971, filed on November 26, 2024, the entire content of which is incorporated herein by reference.

[0002] This disclosure generally relates to using large language models (LLMs) to generate queries for a dataset.

Background Art

[0003] LLM engines have the ability to write code using simple language to perform everyday tasks such as documentation.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The explosive increase in generative artificial intelligence (AI) has unlocked, among other things, content creation and efficiency improvements. Text-to-query is one of the use cases where generative AI has advanced.

[0005] [[ID=3,2]]Many solutions focus directly on query transformation from text, but this methodology has limitations. Existing query generation tools send user input to LLMs and use these LLMs to directly generate queries. However, running queries directly generated from an LLM against a dataset containing sensitive information can pose privacy and operational risks. Queries directly generated from an LLM may contain incorrect syntax, alter the underlying data, and / or leak personal information.

[0006] To address at least these issues, the disclosed examples provide a method for generating queries using natural language input and LLM, designed to preserve the privacy of datasets on which queries may be executed. This technique automates highly faithful query generation while controlling the risks of malicious querying and information leakage. This is particularly useful when interacting with datasets containing sensitive information, where risks such as Structured Query Language ("SQL") injection or data exposure can lead to serious economic or discriminatory consequences. By deterministically protecting sensitive data during automated query generation, the query generation framework described herein facilitates secure and convenient access to insights from sensitive datasets. [Means for solving the problem]

[0007] The disclosed example generates queries by capturing natural user input and processing it with an LLM to create a dataset specification, thereby guiding programmatic query generation. This ensures high-quality and accurate query behavior while limiting malicious actions. The resulting queries (e.g., SQL) are executed against any dataset, while maintaining strict oversight of acceptable query functions. Furthermore, the method minimizes the risk of information leakage and extends dataset protection by limiting LLM exposure to only essential dataset elements such as schema or metadata. In other words, the underlying data itself is not sent to the LLM. Only the schema (or other information describing the types of underlying data, value types, data structure, relationships between foreign keys and primary keys, etc.) is sent to the LLM, thereby extending data security.

[0008] In some examples, a computer implementation includes generating a schema that specifies which fields are accessible in response to a request, from a hardware storage device, metadata specifying fields of one or more datasets stored in the hardware storage device and data specifying permitted actions, and generating a schema according to the accessed metadata and data, the schema specifying which fields are accessible in response to a request; receiving a request for data based on one or more datasets from a client device by the computer system; sending the request and schema to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into a query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema; and storing the compiled query for execution in the hardware storage device. One or more computer systems may be configured to perform a particular operation or action by having software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform an action during operation. One or more computer programs may be configured to perform a particular operation or action by including instructions that cause the device to perform an action when executed by a data processing device.

[0009] In this example, the dataset specification excludes requested data if the requested data is specified by a field not represented in the schema. The schema is configured to exclude sensitive or personally identifiable information (PII) from the accessible data. The action includes accessing instructions from a hardware storage device that specify that personally identifiable information (PII) or other sensitive data should be excluded from representations in the dataset specification, and the method further includes accessing predefined field names that indicate PII or sensitive data, accessing field names of one or more datasets stored in the hardware storage device, and generating a schema to exclude data associated with field names corresponding to predefined field names that indicate PII or sensitive data from the accessible data. The action is to generate a computer program that performs an operation, the operation is to access from a hardware storage device metadata specifying fields of one or more datasets stored in the hardware storage device and data specifying permitted operations, generate a schema according to the accessed metadata and accessed data, the schema specifying which fields are accessible when responding to a request, generate, receive a request for data based on one or more datasets from a client device by a computer system, send the request and schema to an artificial intelligence engine, receive from the artificial intelligence engine a dataset specification containing a structured, machine-readable representation of the request generated according to the schema, compile the dataset specification into a query according to the schema so that the query is executable to perform the operations specified by the schema and to access the data specified by the schema, and store the compiled query for execution in the hardware storage device, the operation is to generate and execute a computer program that performs an operation, the operation is to access from a hardware storage device,The action includes: accessing metadata specifying fields of one or more datasets stored in a hardware storage device and data specifying permitted actions; generating a schema according to the accessed metadata and accessed data, wherein the schema specifies which fields are accessible when responding to a request; receiving a request for data based on one or more datasets from a client device by a computer system; sending the request and schema to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into a query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema; and storing the compiled query for execution in the hardware storage device. The action includes: verifying the dataset specification to ensure compliance with the schema; verifying the query to ensure compliance with the schema; executing the query; and, based on the execution of the query, retrieving data from the hardware storage device according to the schema.

[0010] Another example includes one or more machine-readable hardware storage devices that store instructions executable by one or more processing devices to perform an operation, the operation being to access metadata from the hardware storage device specifying fields of one or more datasets stored in the hardware storage device and data specifying permitted operations, and to generate a schema according to the accessed metadata and the accessed data, the schema specifying which fields are accessible in response to a request, to receive a request for data based on one or more datasets from a client device by a computer system, to send the request and schema to an artificial intelligence engine, to receive from the artificial intelligence engine a dataset specification containing a structured machine-readable representation of the request generated according to the schema, to compile the dataset specification into a query according to the schema so that the query is executable to perform the operations specified by the schema and to access the data specified by the schema, and to store the compiled query for execution in the hardware storage device.

[0011] In this example, the dataset specification excludes requested data if the requested data is specified by a field not represented in the schema. The schema is configured to exclude sensitive or personally identifiable information (PII) from the accessible data. The operation further includes accessing instructions from a hardware storage device that specify that personally identifiable information (PII) or other sensitive data should be excluded from representations within the dataset specification, and the method further includes accessing predefined field names that indicate PII or sensitive data, accessing field names of one or more datasets stored in the hardware storage device, and generating a schema to exclude data associated with field names corresponding to predefined field names that indicate PII or sensitive data from the accessible data. The operation is to generate a computer program that performs the operation, theExecuting an action includes: accessing metadata specifying fields of one or more datasets stored in a hardware storage device and data specifying permitted actions; generating a schema according to the accessed metadata and accessed data, wherein the schema specifies which fields are accessible in response to a request; receiving a request for data based on one or more datasets from a client device by a computer system; sending the request and schema to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into a query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema; and storing the compiled query for execution in the hardware storage device. The action further includes: verifying the dataset specification to ensure compliance with the schema; verifying the query to ensure compliance with the schema; executing the query and, based on the execution of the query, retrieving data from the hardware storage device according to the schema.

[0012] In yet another example, the system includes one or more processing devices and one or more machine-readable hardware storage devices that store instructions executable by one or more processing devices to perform operations, wherein the operation includes generating a schema that specifies which fields are accessible in response to a request, receiving a request for data based on one or more datasets from a client device by the computer system, sending the request and schema to an artificial intelligence engine, receiving a dataset specification from the artificial intelligence engine that includes a structured, machine-readable representation of the request generated according to the schema, compiling the dataset specification into a query according to the schema so that the query is executable to perform the operations specified by the schema and to access the data specified by the schema, and storing the compiled query for execution in the hardware storage device.

[0013] In this example, the dataset specification excludes requested data if the requested data is specified by a field not represented in the schema. The schema is configured to exclude sensitive or personally identified information (PII) from the accessible data. The operation further includes accessing instructions from a hardware storage device that specify that personally identified information (PII) or other sensitive data should be excluded from representations in the dataset specification, and the method further includes accessing predefined field names that indicate PII or sensitive data, accessing field names of one or more datasets stored in the hardware storage device, and generating a schema to exclude data associated with field names corresponding to predefined field names that indicate PII or sensitive data from the accessible data. Other embodiments of this aspect include a corresponding computer system, a device, and a computer program recorded on one or more computer storage devices, each configured to perform the actions of the method. [Brief explanation of the drawing]

[0014] [Figure 1] A block diagram of a system for generating queries based on natural language analysis. [Figure 2] This is a block diagram showing the query generation system in detail. [Figure 3] This is a block diagram of a feedback generation system designed to provide feedback on user input during query generation. [Figure 4] This illustrates an exemplary process for generating queries based on natural language input. [Figure 5] This is a diagram illustrating an exemplary computer system. [Modes for carrying out the invention]

[0015] Current methods for query generation rely on LLMs to directly translate natural language user input into queries. This approach poses significant risks, particularly when querying sensitive datasets such as clinical trial data. Directly executing queries generated by LLMs can lead to errors, exposure of personal information, and unintended data modification, posing serious privacy and operational risks. Queries generated without safeguards may contain syntax errors, allow unauthorized data access, or alter underlying data, all of which can compromise data integrity and privacy. These risks highlight the need for query generation solutions specifically suited to querying sensitive data—namely, those that provide design-controlled and validated query generation. The technologies described herein address these needs by automatically generating queries from natural language input while enforcing controls to mitigate privacy and security risks (e.g., compared to the privacy and security risks of not implementing these technologies). The features of this solution include (i) protecting sensitive information by eliminating or reducing the need to expose the entire data model to the LLM, (ii) ensuring comprehensive control over acceptable query behavior on the dataset (e.g., enabling privacy-protective query capabilities that enforce logic (e.g., strict business rules)), and (iii) reducing the risk of prompt-based or query injection attacks through design. This approach provides a robust privacy enforcement framework for query generation in environments where data confidentiality and behavioral control are essential.

[0016] The disclosed example shows how natural language user input generates queries in a manner that is captured and processed by the LLM to create a dataset specification, declaratively guiding the programmatic generation of queries. Generally, a dataset specification includes a structured description that defines the contents, organization, format, and constraints of one or more datasets. A dataset specification may include definitions of dataset fields, data types, allowed fields, values ​​or ranges, relationships between fields, primary and foreign key constraints, and metadata describing the dataset schema. A dataset specification may further specify data source requirements, update or refresh rules, ordering or index parameters, and compliance or standardization criteria required for interoperability within the system (e.g., the Clinical Data Exchange Standards Consortium Clinical Trial Data Tabular Model ("CDISC SDTM") or International Organization for Standardization ("ISO") formats). This ensures high-quality and accurate query behavior while limiting malicious actions. The resulting queries (e.g., SQL) are executed on the dataset while maintaining strict oversight of permitted query functions. Furthermore, the method reduces the risk of information leakage and enhances data protection by limiting LLM exposure to only essential data elements such as schema or metadata.

[0017] Given the significant risks posed by LLMs when these models are trained and inadvertently disclose information about the data they are exposed, maintaining data privacy is critical. Current safeguards and guardrails for these models have practical limitations in distinguishing between acceptable actions and the protection of sensitive information, resulting in a non-negligible possibility that sensitive data may be exposed during normal or malicious interactions with LLMs. Given the importance of protecting data privacy and the significant economic and discriminatory consequences of inadvertent disclosure, technologies built using LLMs (particularly those operating on sensitive information, e.g., patient health records) require safety mechanisms that deterministically guarantee restrictions on information and actions. The enclosed methods and systems describe the use of LLMs to generate queries mediated by dataset specifications, which act as constraints that enforce safety mechanisms to ensure (i) sensitive information is not disclosed and (ii) actions performed by the generated queries conform to the dataset specifications within the system.

[0018] Referring to Figure 1, a system 100 is shown for automatically generating a query 150 using natural language user input 120. System 100 receives natural language user input 120 from a user input capture system 110. Natural language user input 120 may include specific instructions in natural language, such as a subset of data ("list data extracted from system X between 2010 and 2020"), a transformation of data ("list the number of unique users in the dataset"), or other expressions ("list the number of users and data points in system X"). The natural language user input 120 is passed to a query generation system 130, which incorporates metadata from database 140 to create query 150. This method is not limited to a single database but can be applied across multiple databases.

[0019] Referring to Figure 2, an environment 200 is shown having a query generation system 130, a client device 201, an LLM 240, a schema generator 249, a database 270, and an execution system 330. The query generation system 130 includes a dataset specification engine 210 and a query transpiler engine 280. The dataset specification engine 210 includes a dataset specification generation engine 220 (for generating dataset specifications, for example, by sending prompts to the LLM 240) and a dataset specification validation engine 230 (for validating dataset specifications). The query transpiler engine 280 includes a query construction engine 290 and a query validation engine 300, as described below.

[0020] The dataset specification generation engine 220 receives user input 202 from the client device 201, which includes a request for data from the database 270. In this example, the environment 200 also includes a schema generator 249 that generates a dataset specification schema 250 (hereinafter referred to as "schema 250") from database metadata 260 contained in the database 270. That is, the database metadata 260 may be used by the schema generator 249 to construct the schema 250, which describes the properties and values ​​available for use by the LLM 240. The schema 250 may also specify not only its own fields (e.g., field names) but also the relationships between fields in the dataset stored in the database 270.

[0021] In particular, the database metadata 260 may specify an enumerated value (or type value) associated with each field of a data set stored in the database 270. The database metadata 260 may also specify the type (and associated field name) of the fields of the data set stored in the database 270. The properties of the schema 250 may also be determined by the permitted operations, which may be specified in the database metadata 260, other data obtained from the database 270, or a control source, as described below. Permitted operations are a set of operations that may be informed by policies and requirements including (i) functional requirements of the system, (ii) technical policies, (iii) legal policies, (iv) data and frame limitations, and (v) other non-functional requirements. Permitted operations are essential to enforce policies and controls such that the resulting queries contain only permitted operations. For example, permitted operations may specify that personally identifiable information (PII) be masked, tokenized, and encrypted. In some examples, permitted operations are limited to the inclusion or filtering of rows of a data set using values of a particular set of columns. Permitted operations define how the schema 250 is defined and also inform the downstream query transpiler engine 280. Depending on the complexity of the permitted operations (informed by the requirements of the system), the schema 250 may permit nesting and / or various forms of composition of the data set specification to allow flexibility and additional control for the user. The data set specification engine 210 may, for example, reject or decline the generation of a data set specification if the user input 202 requests an operation that is not a permitted operation. In this example, the data set specification engine 210 sends a rejection to the client device 201 indicating the reason why the request was not satisfied based on the permitted operations.

[0022] Schema Generation In various examples, the schema generator 249 is configured to generate the schema 250 based on (at least) a combination of the permitted operations and the database metadata 260 obtained from the database 270.

[0023] The permitted operations are determined from one or more control sources that define the query actions acceptable within the system. The control sources can be included in the environment 200 or be external to the environment 200. These control sources include: (i) constraints derived from functional requirements - the intended functions of the application or service (e.g., enabling only the aggregation and filtering operations required by a reporting workflow), (ii) technical policies - rules embedded in the system architecture such as restrictions on computationally expensive joins, constraints for maintaining system performance, or prohibitions on full table scans, (iii) legal and compliance policies - requirements imposed by regulatory frameworks, contractual terms, or data governance rules that restrict access to specific fields or combinations of fields (e.g., restrictions on medical data that can identify individuals under the Health Insurance Portability and Accountability Act), (iv) data and framework limitations - constraints defined by the characteristics of the underlying data source or analysis framework, including data type limitations, supported query syntax, or schema-level constraints, and (v) other requirements - those including security controls, access rights, or user role-based restrictions.

[0024] In some examples, these control sources store policy data 272 in a policy repository 271 accessible to the query generation system 130. Generally, policy data includes data specifying one or more policies (e.g., rules) and / or permitted actions that apply to underlying data, such as data stored in the database 270. For example, a policy might specify that PII is not returned, that PII is masked before being returned, that unique identifiers are in a specified format, that actions that modify and / or overwrite the underlying data are not permitted, or that only users of a specified user type or access level can retrieve PII. The schema generator 249 retrieves the relevant policy data 272 in combination with the database metadata 260 to derive permitted actions and / or policies. In some cases, permitted actions may be determined dynamically based on the identity, role, or access level of the requesting user, or in response to the detection of changes to the database schema or policy set.

[0025] To construct schema 250, schema generator 249 first parses database metadata 260 to obtain a baseline structure definition of the dataset, including available properties, their associated value domains (e.g., enumeration values), relational constraints (e.g., primary and foreign keys), index information, and any unique schema-level rules. Schema generator 249 then cross-references this baseline with permitted actions to generate a constrained, policy-compliant schema. This cross-referencing process may remove properties or relationships not subject to permitted actions, or may annotate properties with constraints derived from permitted actions (e.g., allowed filter values, supported aggregate functions, or permitted join conditions).

[0026] In some examples, the schema generator 249 applies configuration rules that conditionally enable certain permitted actions only for specific data types or enumeration values ​​specified in the database metadata 260. For example, aggregation actions may be permitted only for numeric fields identified in the metadata, while filtering actions may be restricted to categorical fields that have enumeration values.

[0027] The resulting schema 250 is machine-readable and describes both the available dataset elements (and the relationships between these elements) and the permitted ways in which those elements can be accessed or manipulated. By embedding policies and metadata constraints directly into the schema, the system (e.g., system 100 in Figure 1) ensures that all downstream query generation, such as that performed by the dataset specification generation engine 220 and the query transpiler engine 280, adheres to both technical feasibility and policy compliance.

[0028] PII Identification and Handling The schema generator 249 determines whether a given property of the database metadata 260 constitutes a PII by using a combination of: (i) metadata classification - checking for column-level governance tags, annotations, or descriptions about privacy labels (e.g., "PII", "Protected Health Information (PHI)", "Confidential"); (ii) naming pattern detection - matching field names against a keyword list in the policy definition (e.g., "Name", "SSN", "DOB", "Email Address", "Phone Number", "Address"); (iii) format and type analysis - matching data types and lengths against known identifier formats (e.g., a 9-digit SSN, a specific regular expression pattern for a phone number or email address); and (iv) sample value checking - optionally sampling a subset of non-confidential data for pattern matching or machine learning-based classification to detect identifiers or quasi-identifiers.

[0029] PII classification policies stored in a policy repository (for example, one contained in database 270 or another database) map database field identifiers to privacy categories such as “Direct Identifier,” “Semi-Identifier,” and “Non-PII.” The schema generator 249 cross-references these classifications in permitted actions to determine appropriate handling. For “Direct Identifier” fields, the schema generator 249 may (a) completely omit the property from schema 250, (b) replace it with a tokenized or anonymized representation, or (c) include it in a restricted permitted action (e.g., rejecting grouping or filtering that could reveal individual records). For “Semi-Identifier” fields, additional statistical privacy thresholds (e.g., minimum group size) may be enforced through permitted actions.

[0030] Specifically, after PII detection, the schema generator 249 constructs schema 250 by including only properties permitted under applicable technical policies, operational policies, and privacy policies. Schema 250 contains a hierarchical, machine-readable representation of permissible dataset elements and their associated operational constraints, designed to enable policy-compliant query generation while preventing PII exposure from database 270.

[0031] At the highest level, schema 250 includes a root dataset node 258 that references one or more property nodes (e.g., property 1 node 252, property 2 node 254). Each property node corresponds to a dataset field identified by parsing database metadata 260, which may specify field names, data types, enumeration domains, relational constraints (e.g., primary and foreign keys), join logic between different datasets, and index information. For each included property, schema 250 may also include child nodes derived from database metadata 260 and filtered through permitted behaviors, such as enumeration node 256 (listing permitted categorical values) and constraint node 257 (listing permitted operators, aggregate functions, or join keys). Schema 250 also specifies relationships between nodes.

[0032] When LLM240 receives user input 202 (for example, from a client device 201), it refers to schema 250 to determine valid properties, enumerations, and actions for constructing a dataset specification 251. Because schema 250 excludes or masks fields containing PII and restricts high-risk actions, LLM240 cannot generate a dataset specification that directly or indirectly exposes PII from database 270. That is, schema 250 may exclude any field containing PII, or may include only the field name (but not the value itself). This ensures that downstream components, including the dataset specification validation engine 230, query transpiler engine 280, and query construction engine 290, operate exclusively with respect to the privacy-preserving and policy-compliant subset of the underlying data. The schema generator 249, by combining database metadata 260, permitted actions, and automated PII detection, creates a constrained hierarchical schema 250 that enables natural language query generation while enforcing privacy requirements and regulatory compliance.

[0033] User input 202 and schema 250 are passed to LLM240. The hyperparameters of LLM240 can be configured to enforce highly deterministic and reproducible behavior. This is important because users may expect the same natural language specification to produce the same output over repeated trials. This behavior is also recommended by the use of function calls. LLM240 may also be fine-tuned to improve performance when generating the dataset specification specified in schema 250.

[0034] Fine tuning In some examples, LLM240 is fine-tuned to improve its performance in generating dataset specifications that conform to schema 250 and adhere to permitted behaviors. Fine-tuning can be performed using LLM methods such as supervised fine-tuning, reinforcement learning from human feedback, reinforcement learning from AI feedback, or a combination thereof. The training dataset is validated against schema 250 and constructed from historical dataset specifications that have been successfully used to generate compliant queries Q. Each training example may include (i) a natural language request for the data (similar to user input 202), (ii) the corresponding schema 250 that is valid at the time of generation, and (iii) the resulting validated dataset specification. LLM240 is trained to map combinations of natural language input and schema constraints to the output of a correct, policy-compliant dataset specification.

[0035] Fine-tuning may include negative sampling, which provides examples of non-compliant or invalid dataset specifications along with correct outputs, and penalizes models that produce non-compliant results. This improves the LLM's sensitivity to schema-level constraints, enumerations, and permitted behaviors.

[0036] In some examples, fine-tuning incorporates function call formats during training to ensure that the model's output follows a structured representation (e.g., JavaScript Object Notation (JSON) or another machine-readable format) that is directly compatible with downstream query building engines 290. The training process may also incorporate prompt templates that explicitly include schemas 250 as input, training the LLM to reference schema constraints during generation rather than relying solely on statistical correlations.

[0037] Reinforcement learning may be further applied, in which the LLM's outputs are scored by a dataset specification validation engine 230. Outputs that pass validation against the schema 250 and permitted behaviors are assigned high rewards, while outputs that fail validation are penalized. The LLM then receives reward signals (as input) indicating which outputs received higher rewards. These reward signals are then used to tune the LLM's parameters during training. This iterative feedback loop gradually biases the LLM 240 to produce outputs that are semantically correct and compliant with operational, technical, and policy constraints. Through this fine-tuning process, the LLM 240 develops the expertise to interpret natural language requests considering schema definitions, creating a deterministic and reproducible dataset specification that seamlessly integrates into the query generation system 130. Supervised learning may be applied to fine-tune the LLM outputs by asking users to provide feedback and incorporating that feedback as labels to fine-tune the LLM's performance against those labels.

[0038] Along with user input 202 and schema 250, additional instructions in the form of system prompts may be provided to the LLM240 (e.g., from client device 201) to improve performance when generating the dataset specification 251. System prompts may include information regarding (i) descriptions of domain / business objects, (ii) interpretation of properties within schema 250, and / or (iii) additional information regarding constraints when generating the dataset specification 251. Furthermore, few-shot prompts may be provided to add additional context, details, and / or limitations and constraints.

[0039] Generating and using few-shot prompts In this example, the system employs few-shot prompts to improve the performance of LLM240 in generating a dataset specification 251 from user input 202, taking schema 250 and permitted behaviors into consideration. The few-shot prompts include a small number of expressive input / output examples presented to LLM240 before requesting the model's output, thereby conditioning the model to follow a desired transformation pattern. By providing examples that conform to the constraints and permitted behaviors embodied in schema 250, the system biases LLM240 to generate a policy-compliant and technically feasible dataset specification.

[0040] In some examples, few-shot prompts are dynamically constructed from records of past dataset specifications stored in relation to the query generation system 130. Each record may include (i) a natural language data request similar to user input, (ii) the schema 250 and permitted behavior applicable at the time of the request, and (iii) a verified version of the dataset specification 251 that was generated and successfully executed to produce a compliant query. The system may select a subset of such records as examples to ensure that the examples reflect the diverse query structures, permitted behaviors, and field constraints defined by the schema 250.

[0041] For example, the first example might demonstrate a simple filtering operation constrained by enumeration values ​​within schema 250, the second example might demonstrate an aggregation allowed only on numeric fields, and the third example might demonstrate a join operation limited to specific key pairs defined by the allowed operations. In some cases, the system may select an example that demonstrates a combination of allowed operations, such as applying aggregation only after filtering on a categorical field.

[0042] Few-shot prompts may be generated at runtime to reflect the current state of schema 250 and permitted behaviors, thereby adapting to changes in database metadata 260, policy repository contents, or user access permissions. In such an example, the prompt generation logic retrieves one or more past records that match the current constraints, formats them into a structured prompt, and appends this prompt to the system prompt before submitting it to LLM240.

[0043] Including few-shot prompts in the input to LLM240 improves the model's ability to produce a deterministic and reproducible dataset specification 251 that adheres to the current schema 250 and permitted behaviors. In some examples, the model is fine-tuned using the few-shot prompt format as part of the training dataset, thereby enhancing the model's learned behavior by explicitly referencing schema-level constraints during generation, rather than relying solely on statistical correlations from the pre-training corpus. This integration of dynamically constructed few-shot prompts and schema-aware fine-tuning results in a technical improvement in ensuring that the generated dataset specification is semantically correct and adheres to operational, technical, and policy constraints.

[0044] LLM240 may comprise both (i) a "query generation" tool and (ii) a "rejection" tool via function calls. If schema 250 cannot support a request from user input 202, LLM240 may select the rejection tool, prompting dataset specification engine 210 to decline the request and provide an explanation to the user. The selection of the rejection tool may be facilitated for several reasons, including but not limited to (i) an inappropriate request, (ii) a request involving behavior not permitted by the schema, (iii) a request for inaccurate or unavailable data, or (iv) a malicious attempt to extract system prompts or other information about the data that is not permitted by the schema. The generated explanation to the user may include information about (i) why the request was unsuccessful, (ii) possible modifications to user input that could lead to successful query generation, and / or (iii) permitted behaviors and sample user inputs that the user could try instead of the original request.

[0045] Schema compliance determination and rejection triggers LLM240 determines whether a dataset specification can be generated for user input 202 by evaluating the schema 250 and the requests for permitted behaviors. The schema 250 is provided to LLM240 in a machine-readable format such as a JSON document, enumerating the properties available in the dataset, associated data types, enumeration domains, relational constraints (e.g., foreign key relationships), permitted joins, permitted aggregations and filters per property, and any user-specific access restrictions. Permitted behaviors, derived from policy data and database metadata 260, are similarly provided to LLM240 as structured input.

[0046] In some examples, the function call interface to the query generation tool enforces constraints derived from schema 250 and permitted behaviors. For example, the interface may be defined by a JSON schema or a system of equivalent types where parameter values ​​are restricted to valid data types (e.g., enumerations) from schema 250. Any attempt by LLM240 to emit properties, behaviors, or enumeration values ​​that do not exist in schema 250 or permitted behaviors when attempting to generate the dataset specification 251 will cause the decoding process to fail to validate the constraints. In the event of such a failure, LLM240 opts to use a rejection tool rather than a query generation tool, prompting the dataset specification engine 210 to decline the request and return a structured description to the client device 201.

[0047] In some cases, LLM240 may invoke schema lookup tools during generation to resolve conditional permissions or schema versioning. For example, the “lookup_field” function may return whether the requested field exists in the current schema 250, the “is_operation_allowed” function may return whether the specified operation is allowed for a given property, and the “join_allowed” function may indicate whether two entities can be joined under the current constraints. If any lookup indicates non-compliance, LLM240 invokes a reject tool.

[0048] In some cases, the dataset specification 251 undergoes deterministic post-generation validation by the dataset specification validation engine 230. This engine 230 verifies that (i) the referenced properties exist within the schema 250, (ii) the use of the properties is type-compatible, (iii) the category values ​​match the enumeration domain, (iv) the join operation is explicitly permitted, and (v) user-specific access controls are met. If validation fails, the dataset specification validation engine 230 returns an error code and rationale (e.g., "FIELD_NOT_FOUND", "JOIN_FORBIDDEN", ​​or "VALUE_OUT_OF_RANGE"), which the LLM240 presents through the rejection tool to produce a rejection response along with an explanation.

[0049] In some examples, system prompts instruct LLM240 to treat schema 250 and permitted behaviors as formal, and few-shot prompt examples include both compliance generation and rejection scenarios. This conditioning reinforces the model's behavior to select a rejection tool when a request cannot be met under current schema constraints. For dynamic databases, schema 250 may include version identifiers, and if user input 202 references an object from a different version, the schema lookup tool may also trigger a rejection path by returning a schema mismatch result. For role-based access control, an access-filtered version of schema 250 is generated for each request so that properties or behaviors outside of user privileges are omitted, thereby making the otherwise valid request appear unsupported and leading to a rejection in principle. This architecture allows rejections to be directly traceable to the constraints and permitted behaviors embodied in schema 250, thereby ensuring that the dataset specification 251 is technically feasible, policy-compliant, and executable by the downstream query construction engine 290.

[0050] If LLM240 selects a query generation tool, the query generation tool may generate a dataset specification 251 (for example, an object such as structured JSON) that adheres to schema 250 and is passed to the rest of the pipeline. In this example, LLM240 sends the dataset specification 251 to the dataset specification generation engine 220.

[0051] Schema-driven dataset specification generation In some examples, when LLM240 selects a query generation tool, the query generation tool produces a structured dataset specification 251 that satisfies the permitted behaviors according to schema 250. Schema 250 provides LLM240 with a formal, machine-readable representation of the dataset's structural and operational constraints. This schema 250 may be encoded in a structured format (e.g., JSON, YAML, XML) and may enumerate, for each available property, its data type, permitted value domains, relational relationships, and a subset of permitted behaviors for that property. Schema 250 may further include constraints between properties, conditional rules (e.g., aggregation is permitted only if a corresponding grouping field exists), and user-specific restrictions derived from policy data.

[0052] During dataset specification generation, schema 250 is supplied to LLM240 as part of its input context, optionally along with system prompts and few-shot prompts. LLM240 parses schema 250 to identify properties and behaviors that match the semantic intent expressed in user input 202. For example, if the input request specifies "mean systolic blood pressure of male patients over 60 years old," LLM240 refers to schema 250 to determine that (i) the property "systolic_bp" is numeric and supports aggregation using the "avg" function, (ii) "age" is of type "integer" and can be filtered using a comparison predicate (e.g., >60), and (iii) "gender" is a categorical field with enumeration values ​​including "male" and "female." The resulting dataset specification 251 includes only the behaviors allowed under the schema, expressed in a structured JSON-like format suitable for downstream processing.

[0053] In some cases, schema 250 also guides value normalization and constraint annotations during generation. For example, if schema 250 specifies that a data field uses the "YYYY-MM-DD" formatting, LLM240 may normalize any date literal accordingly. If a filter value is not in the enumeration domain, the model may omit it or replace it with the nearest valid alternative, depending on system prompt instructions. Constraints given in the schema may also be embedded directly in the dataset specification 251, such as allowed filter operators, permitted join keys, or aggregation granularity limits for a given field.

[0054] Once constructed, the dataset specification 251 is sent to the dataset specification validation engine 230. In some examples, this engine 230 performs deterministic validation of the dataset specification 251 against the schema 250 to ensure compliance before passing the dataset specification 251 to the query transpiler engine 280 and the query construction engine 290. This validation step verifies that all fields, behaviors, and values ​​in the dataset specification 251 exist and are permitted in the schema 250, ensuring that the resulting queries are technically executable, policy-compliant, and optimized for the underlying database 270.

[0055] By directly embedding the schema 250 into the process performed by the dataset specification engine 210, the system ensures that natural language-driven query generation is limited by explicit machine-readability constraints. This represents a technical improvement over unconstrained natural language systems that may generate semantically valid but technically invalid queries, thereby reducing execution errors, improving compliance with operational and legal policies, and extending the deterministic reproducibility of query generation.

[0056] In particular, the dataset specification validation engine 230 verifies that the properties in the dataset specification 251 are limited to those specified by the schema 250, and that the values ​​of those properties are taken from the enumeration in the schema, where applicable. In this example, the dataset specification validation engine 230 outputs a validated version of the dataset specification 251. The validated version of the dataset specification 251 is also referred to as the dataset specification 251 for convenience, rather than limited. This validation step ensures that the dataset specification 251 is processed by the query transpiler engine 280 without errors (or with reduced errors), as described later.

[0057] Within the query transpiler engine 280, the query construction engine 290 programmatically transpiles the dataset specification 251 into a query 150. Generally, transpilation involves converting code written in one programming language into code in another programming language.

[0058] The query transpiler engine 280 (and its subcomponents, (i) the query construction engine 290 and (ii) the query validation engine 300) are designed based on the allowed behavior (including data restrictions, access controls, policies, allowed query behavior, and other non-functional requirements) and the schema 250. For example, in a system where allowed behavior is limited to filtering a dataset using a specific set of columns of the dataset, properties in the schema 250 may be defined as the names of the columns used to filter the dataset. The values ​​corresponding to these properties will be the values ​​that can be used to filter the dataset. The dataset specification 251 may be stored as a JSON-like object to store the properties and corresponding values ​​used to filter the dataset. In this case, the query transpiler 280 may be designed to programmatically construct queries (e.g., SQL queries) in which the properties in the dataset specification 251 are used to filter the dataset. In this example, if the dataset specification is defined as a JSON-like object {"user_name": "Jane Doe"}, the corresponding SQL query constructed by the query transpiler engine 280 will be "SELECT * FROM user WHERE user_name='Jane Doe'". In this example, the query transpiler engine 280 refers to schema 250 to resolve the logical field "user_name" to its concrete database representation. Schema 250 may specify that the logical field "user_name" corresponds to the user_name column in the users table (a table named "Users"). By performing this resolution step at runtime, the query transpiler engine 280 ensures that the abstract properties in the dataset specification 251 are correctly bound to the actual table and column identifiers of the dataset in database 270.

[0059] Permitted actions may extend to selecting a subset of columns, aggregating across one or more columns, and / or other related actions. Depending on the permitted actions, schema 250 and query transpiler engine 280 are designed to accommodate these actions, limitations, policies, and controls.

[0060] In other words, the query transpiler engine 280 (also referred to as transpiler 280 for convenience) includes a query generator (e.g., an SQL generator) built specifically to translate only those dataset specifications that adhere to the rules and permitted actions within schema 250. Schema 250 defines which fields and actions are possible and how permitted actions may use those fields. Dataset specifications 251 act as a bridge between the two, capturing specific compliant instructions for a single request in a format that transpiler 280 can translate directly into a valid query. This design means that transpiler 280 does not need to interpret raw natural language or infer user intent; instead, it simply maps the structured instructions within dataset specifications 251 into executable queries, making the system more predictable, secure, and auditable.

[0061] By requiring the query transpiler engine 280 to operate only against dataset specifications 251 that have been pre-generated and validated against schema 250 and permitted behaviors, the system provides an additional technical safety net against invalid or non-compliant query execution. In particular, dataset specifications 251, apart from executable queries, include a structured, machine-readable intermediate representation of the user's request, which can be fully inspected by dataset specification validation engine 230 before being accepted by query construction engine 290. This separation of critical matters ensures that the transpiler 280 never processes raw, unconstrained natural language input, thereby eliminating opportunities for policy circumvention, SQL injection, or accidental inclusion of restricted fields such as PII from database 270. Furthermore, this architecture enables deterministic enforcement of behavioral control. Even if schema 250 and permitted behaviors change over time, dataset specifications 251 reflect a subset of compliant, context-specific dataset capabilities, and the transpiler 280 is coded to provide only queries that remain within that subset. This two-step process—dataset specification generation under schema constraints, followed by transpilation under the same constraints—results in a system that is not only flexible and portable across different database engines, but also inherently more secure, auditable, and resistant to unintentional or malicious query extensions that exceed authorization parameters.

[0062] The generated query is passed through the query validation engine 300, which ensures that the execution of query 150 is safe. Generally, validation includes (i) ensuring “safe” output, and (ii) ensuring that the returned values ​​are actually one of the values ​​in the data. With respect to (i), the query validation engine 300 passes the query through content filters and compliance filters to ensure, in particular, that the query satisfies content policies and privacy policies. For example, safe output may refer to content that has passed through such filters (sometimes called “guardrails”). With respect to (ii), the query validation engine 300 verifies that any literal values ​​or parameters in the query actually exist in the database before executing the query. For example, if the generated query specifies “SELECT * FROM users WHERE country='XYZ'”, the system first verifies that “XYZ” is a valid country code included in the underlying data, thereby preventing the execution of queries that do not return results or queries that would produce invalid or irrelevant values.

[0063] In some examples, the parameters of query 150 (e.g., bind parameters) themselves are extracted and validated. Generally, bind parameters are placeholder parameters that are bound to actual values ​​at runtime. Using bind parameters improves efficiency because it allows the database to reuse the execution plan instead of recompiling the SQL statement every time. In this example, the query validation engine 300 checks that the bind parameters meet expected criteria (e.g., they follow expected rules or formats such as being of the correct type (integer, string), within an allowed range of values, and not being malicious input).

[0064] By constructing this system, the schema and permitted behaviors directly dictate the process by which query 150 is constructed by the query construction engine 290, thus reducing or minimizing the chances of failure. The query validation engine 300 is designed according to the schema and permitted behaviors to ensure compliance with the system's functional and non-functional requirements. In some examples, the query validation engine 300 receives schema 250 and is configured to verify that query 150 conforms to schema 250. In other examples, the query validation engine 300 is pre-programmed according to schema 250 to ensure, for example, that the query conforms to schema 250. The query validation engine 300 outputs query 150. The execution system 330 executes query 150 against data in database 270 (e.g., dataset 331), generates results, and sends those results to client device 201. In this example, the results include the fields and data and permitted behaviors specified by schema 250, as accessible for retrieval.

[0065] As described herein, the query transpiler engine 280 consumes the dataset specification 251 along with the concurrently existing schema 250 when constructing queries. Although the dataset specification 251 has been pre-validated for conformance, schema 250 serves as a trusted source of information at runtime, which (i) resolves dataset specification fields to concrete database objects (e.g., table / column identifiers, key relationships, and required join paths), (ii) supplies the necessary collation rules to give data types, formatting, and syntactically and semantically correct predicates, (iii) applies policy-bound transformations such as masking, tokenization, or aggregate thresholds that may be updated after the dataset specification 251 is generated, (iv) maps logical operations within the dataset specification 251 to engine-specific structures (e.g., SQL dialect features, optimizer hints, or access control views), and (v) reconfirms compliance with current permitted behavior in case of policy or metadata drift. The transpiler 280 enforces a multi-layered defense model by binding query construction to schema 250, preventing non-compliant, obsolete, or ambiguous instructions within dataset specification 251 from being produced as executable queries, thereby ensuring accuracy, portability between backends, and deterministic compliance with technical and security controls. The generated query 150 can be executed against the target dataset to obtain the target resulting output. These results can be sent to the user for export or preview in system 100 (Figure 1) via additional tools.

[0066] The query construction engine 290 can also generate user-friendly, readable “external queries” that may be presented to the user to ensure they meet user expectations. These “external queries” may also be used to track the set of actions performed on the underlying data to produce the desired output, adding transparency and traceability to the process. Tables from the “external queries” may match tables created by query 150 through transformations that can be performed within common table expressions.

[0067] Referring to Figure 3, the feedback generation engine 310 is shown. The feedback generation engine 310 may take the generated query 150, schema 250, and user input (not shown) as input. The feedback generation engine 310 may use LLM 240 to generate feedback 320 indicating how the request was processed. The feedback 320 is presented to the user. The feedback may also include suggestions for correction, such as how to rephrase the request to better align with the properties defined in the schema, or explanations and reasons for partially fulfilled responses. The engine may take an "external" query as input instead of the generated query 150. Additional details may be added to system prompts and / or few-shot prompts to provide guidance on the content of the feedback 320. LLM 240 may be fine-tuned to generate feedback to improve the tone, style, understanding, guidance, quality, and / or other characteristics of the generated feedback that may be important to the user experience.

[0068] In addition to the above description and accompanying figures, embodiments may be based at least in part on the following methodological pseudocode for generating queries using natural input, as shown in Table 1 below.

[0069] [Table 1]

[0070] Referring to Figure 4, an exemplary process 400 for generating queries based on natural language input is shown. In this example, the system accesses metadata from a hardware storage device specifying fields of one or more datasets stored in the hardware storage device and data specifying permitted actions (402). The system generates a schema according to the accessed metadata and accessed data (404), the schema specifying which fields are accessible when responding to a request. The system receives a request for data based on one or more datasets from a client device by a computer system (406). The request includes natural language input. The system sends the request and schema to an artificial intelligence engine (408). The system receives a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema (410). The system compiles the dataset specification into a query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema (412). The system stores the compiled query for execution in the hardware storage device (414).

[0071] Referring to Figure 5, an exemplary operating environment for implementing an example of the technology described herein is shown and is generally designed as a computing device 130. The computing device 130 (also called a computer or data processing system or client or server) includes one or more programmable processors 132 for performing actions according to instructions and one or more memory devices 134 for storing instructions and data. Generally, the computer also includes I / O components 136, e.g., display devices, network / communication subsystems, etc. (not shown), one or more large storage devices 138 for storing data and instructions, etc., and a network / communication subsystem 140 powered by a power supply (not shown), or operably coupled to them (via a bus 131, fabric, network, etc.). Memory 134 contains an operating system 134a and applications 134b for application programming.

[0072] Computer program instructions and data may be stored in a non-temporary form, such as being embodied in a volatile or non-volatile storage medium, or any other non-temporary medium, using the physical properties of the medium (e.g., surface pits and lands, magnetic domains, or electric charge) over a period of time (e.g., the time between refresh periods of a dynamic memory device such as dynamic RAM). In preparation for loading instructions, the software may be provided on a tangible non-temporary medium, such as a CD-ROM or other computer-readable medium (e.g., readable by a general-purpose or dedicated computing system or device), or it may be delivered (e.g., encoded into a propagated signal) via a network communication medium to a tangible non-temporary medium on the computing system on which the software is executed. Some or all of the processing may be performed on a dedicated computer, or using dedicated hardware such as a coprocessor, a field-programmable gate array (FPGA), or a dedicated application-specific integrated circuit (ASIC). The processing may be performed in a distributed manner, where different parts of the computation specified by the software are performed by different computing elements. Each of such computer programs is stored or downloaded onto a computer-readable storage medium (e.g., solid-state memory or media, or magnetic or optical media) of a storage device accessible by a general-purpose or dedicated programmable computer (from a cloud computing infrastructure or other remote source) in order to configure and operate the computer when the storage device medium is read by the computer to perform the processing described herein. Each of such computer programs may also be accessed as a service provided by a cloud computing infrastructure. The examples described herein may also be implemented as a tangible, non-temporary medium composed of computer programs, such a medium causing the computer to operate in a specific predefined manner to perform one or more of the processing steps described herein.

[0073] A computer program may include, for example, one or more modules of a larger program that provide services related to the design, configuration, and execution of the program. A module of a program may be implemented as a data structure or other organized data conforming to a data model stored in a data repository.

[0074] To provide user interaction, the examples of subject matter described herein may be implemented on a computer having a display device (monitor) for displaying information to the user, as well as a keyboard and pointing device (e.g., mouse or trackball) on which the user can provide input to the computer. Furthermore, the computer may interact with the user by sending documents to and receiving documents from a device used by the user (e.g., by sending a web page to a web browser on the user's device in response to a request received from a web browser).

[0075] Examples of the subject matter described herein may be implemented in a computing system including a backend component (e.g., as a data server), a middleware component (e.g., an application server), or a frontend component (e.g., a user computer having a graphical user interface or web browser that allows a user to interact with embodiments of the subject matter described herein), or in any combination of one or more such backend, middleware, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad-hoc peer-to-peer networks).

[0076] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The client-server relationship arises when computer programs run on each other's computers and have a client-server relationship with each other. In some examples, the server sends data (e.g., an HTML page) to the client device (e.g., to display data to a user interacting with the user device and to receive user input from the user). Data generated on the client device (e.g., the results of user interactions) may be received from the client device by the server.

[0077] This specification includes details of many specific embodiments, but these should not be construed as limitations on the scope of any invention or claim, but rather as descriptions of features specific to particular examples of a particular invention.

[0078] Similarly, although the operations are shown in a specific order in the diagrams, this should not be understood as meaning that such operations must be performed in a specific illustrated or sequential order, or that all illustrated operations must be performed, in order to achieve the desired result. Furthermore, the separation of various system components in the examples above should not be understood as meaning that such separation is necessary in all examples, and the described program components and systems can generally be integrated into a single software product or packaged into multiple software products.

[0079] Several examples have been described. Notwithstanding the foregoing, it should be understood that various modifications can be made without departing from the spirit and scope of the technology described herein. For example, some of the steps described above may be sequentially independent and therefore may be performed in a different order than those described. Accordingly, other examples are within the scope of the following claims. [Explanation of symbols]

[0080] 100 Systems 110 User Input Capture System 120 Natural Language User Input 130 Query Generation System 140 Databases 150 queries 200 Environment 201 Client Devices 202 User Input 210 Dataset Specification Engine 220 Dataset Specification Generation Engines 230 Dataset Specification Validation Engine 240 LLM 249 Schema Generator 250 Dataset Specification Schema 251 Dataset Specifications 252 Property 1 Node 254 Property 2 Nodes 256 Enumeration Value Nodes 257 constraint nodes 258 root dataset nodes 260 Database Metadata 270 databases 271 Policy Repositories 272 Policy Data 280 Query Transpiler Engine 290 Query Construction Engine 300 Query Validation Engines 310 Feedback Generation Engine 320 Feedback 330 Execution Systems

Claims

1. Accessing metadata and data specifying permitted operations from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. Generating a schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request; Receiving a request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, The artificial intelligence engine receives a dataset specification, which includes a structured, machine-readable representation of the request, generated according to the schema. Compiling the dataset specification into the query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema, The hardware storage device stores the aforementioned queries, which have been compiled for execution. A computer implementation method, including

2. The computer implementation method according to claim 1, wherein the dataset specification excludes the requested data if the requested data is specified by a field not represented in the schema.

3. The computer implementation method according to claim 1, wherein the schema is configured to exclude sensitive information or personally identifiable information (PII) from accessible data.

4. The method further includes accessing instructions from the hardware storage device that specify that personally identifiable information (PII) or other sensitive data should be excluded from representations within a dataset specification, Accessing predefined field names that indicate PII or confidential data, Accessing the field names of one or more datasets stored in the hardware storage device, The schema is generated in such a way that data associated with field names corresponding to predefined field names indicating PII or confidential data is excluded from the accessible data. The computer implementation method according to claim 1, further comprising:

5. The process involves generating a computer program that performs an action, the action being: Accessing metadata and data specifying permitted actions from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. To generate the schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request. Receiving the request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, Receiving the dataset specification from the artificial intelligence engine, which includes the structured, machine-readable representation of the request generated according to the schema, Compiling the dataset specification into the query according to the schema so that the query is executable for performing the actions specified by the schema and for accessing the data specified by the schema, and The compiled queries for execution are stored in a hardware storage device. Including generating, Executing a computer program that performs an action, the action being: Accessing metadata and data specifying permitted actions from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. To generate the schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request. Receiving the request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, Receiving the dataset specification from the artificial intelligence engine, which includes the structured, machine-readable representation of the request generated according to the schema, Compiling the dataset specification into the query according to the schema so that the query is executable for performing the actions specified by the schema and for accessing the data specified by the schema, and The compiled queries for execution are stored in a hardware storage device. This includes performing, The computer implementation method according to claim 1, further comprising:

6. The computer implementation method according to claim 1, further comprising verifying the dataset specification in order to ensure compliance with the schema.

7. The computer implementation method according to claim 1, further comprising validating the query to ensure that the query conforms to the schema.

8. Executing the aforementioned query, Based on the execution of the aforementioned query, data is retrieved from the hardware storage device according to the aforementioned schema, The computer implementation method according to claim 1, further comprising:

9. One or more machine-readable hardware storage devices that store instructions executable by one or more processing devices for performing an operation, wherein the operation is Accessing metadata and data specifying permitted operations from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. Generating a schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request; Receiving a request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, Receiving a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema, Compiling the dataset specification into the query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema, The hardware storage device stores the queries compiled for execution, One or more machine-readable hardware storage devices, including [the specified element].

10. The machine-readable hardware storage device according to claim 9, wherein the dataset specification excludes the requested data if the requested data is specified by a field not represented in the schema.

11. The schema is configured to exclude sensitive or personally identifiable information (PII) from accessible data, one or more machine-readable hardware storage devices according to claim 9.

12. The aforementioned operation is, The method further includes accessing instructions from the hardware storage device that specify that personally identifiable information (PII) or other sensitive data should be excluded from representations within a dataset specification, Accessing predefined field names that indicate PII or confidential data, Accessing the field names of one or more datasets stored in the hardware storage device, The schema is generated in such a way that data associated with field names corresponding to predefined field names indicating PII or confidential data is excluded from the accessible data. One or more machine-readable hardware storage devices according to claim 9, further comprising:

13. The aforementioned operation is, The process involves generating a computer program that performs an action, the action being: Accessing metadata and data specifying permitted actions from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. To generate the schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request. Receiving the request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, Receiving the dataset specification from the artificial intelligence engine, which includes the structured, machine-readable representation of the request generated according to the schema, Compiling the dataset specification into the query according to the schema so that the query is executable for performing the actions specified by the schema and for accessing the data specified by the schema, and The compiled queries for execution are stored in a hardware storage device. Including generating, Executing a computer program that performs an action, the action being: Accessing metadata and data specifying permitted actions from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. To generate the schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request. Receiving the request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, Receiving the dataset specification from the artificial intelligence engine, which includes the structured, machine-readable representation of the request generated according to the schema, Compiling the dataset specification into the query according to the schema so that the query is executable for performing the actions specified by the schema and for accessing the data specified by the schema, and The compiled queries for execution are stored in a hardware storage device. This includes performing, One or more machine-readable hardware storage devices according to claim 9, including the following:

14. The operation further comprises verifying the dataset specification to ensure compliance with the schema, one or more machine-readable hardware storage devices according to claim 9.

15. The operation further comprises validating the query to ensure that the query conforms to the schema, one or more machine-readable hardware storage devices according to claim 9.

16. The aforementioned operation is, Executing the aforementioned query, Based on the execution of the aforementioned query, data is retrieved from the hardware storage device according to the aforementioned schema, One or more machine-readable hardware storage devices according to claim 9, further comprising:

17. It is a system, One or more processing devices, One or more machine-readable hardware storage devices that store instructions executable by one or more processing devices in order to perform an operation, wherein the operation is Accessing metadata and data specifying permitted actions from a hardware storage device, which specify fields of one or more datasets stored in the hardware storage device. To generate a schema according to the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible when responding to a request. Receiving a request for data from a client device by a computer system based on one or more datasets, Sending the aforementioned request and the aforementioned schema to the artificial intelligence engine, Receiving a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema. Compiling the dataset specification into the query according to the schema so that the query is executable to perform the actions specified by the schema and to access the data specified by the schema, and To store the queries compiled for execution in a hardware storage device, The one or more machine-readable hardware storage devices, A system equipped with these features.

18. The system according to claim 17, wherein the dataset specification excludes the requested data if the requested data is specified by a field not represented in the schema.

19. The system according to claim 17, wherein the schema is configured to exclude sensitive information or personally identifiable information (PII) from accessible data.

20. The aforementioned operation is, The method further includes accessing instructions from the hardware storage device that specify that personally identifiable information (PII) or other sensitive data should be excluded from representations within a dataset specification, Accessing predefined field names that indicate PII or confidential data, Accessing the field names of one or more datasets stored in the hardware storage device, The schema is generated in such a way that data associated with field names corresponding to predefined field names indicating PII or confidential data is excluded from the accessible data. The system according to claim 1, further comprising:

Images