Systems, methods, and machine-readable hardware storage devices for generating queries against datasets using large language models and patterns to improve data security.

Abstract

This disclosure provides systems, methods, and machine-readable hardware storage devices for generating queries against datasets using large language models and patterns to improve data security. The computer-implemented method includes: accessing metadata and data specifying allowed operations for fields of one or more datasets stored in the hardware storage device; generating a pattern based on the accessed metadata and accessed data, 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 via a computer system; transmitting the request and pattern to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, including a structured, machine-readable representation of the request generated according to the pattern; and compiling the dataset specification into a query based on the pattern, enabling the query to execute to perform the pattern-specified operations and access the pattern-specified data.

Description

Technical Field

[0001] This disclosure generally relates to generating queries for datasets using large language models (LLMs). Background Technology

[0002] The LLM engine has the ability to use simple languages ​​to write code for common tasks such as documentation. Summary of the Invention

[0003] The explosion of generative artificial intelligence (AI) has unlocked possibilities such as content creation and efficiency improvements. Text-to-query is one such use case where generative AI is making progress.

[0004] While many solutions focus directly on text-to-query transformation, this approach has limitations. Existing query generation tools send user input to an LLM (Limited Language Management Model) to directly generate queries using that LLM. However, running queries generated directly from an LLM on datasets containing sensitive information can pose privacy and operational risks. Queries generated directly from an LLM may include grammatical errors, alter underlying data, and / or potentially leak private information.

[0005] To at least address this issue, the disclosed examples provide a method for generating queries using natural language input and LLM, designed to protect the privacy of the datasets on which these queries can be executed. This approach automates high-fidelity query generation while controlling the risks of malicious query creation and information leakage. This is particularly valuable for interacting with datasets containing sensitive information, where risks such as Structured Query Language (“SQL”) injection or data exposure could lead to serious financial or unfair 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.

[0006] The disclosed example generates queries through a method in which natural user input is captured and processed by the LLM to produce a dataset specification, which then guides the programmatic generation of queries. This ensures high-quality, accurate query operations while restricting unauthorized actions. The resulting queries (e.g., SQL) can be executed on any dataset while maintaining strict oversight of permitted query functionality. Furthermore, this method limits the exposure of the LLM to essential dataset elements, such as schemas or metadata, thereby minimizing the risk of information leakage and enhancing dataset protection. That is, the underlying data itself is not transmitted to the LLM. Only the schema (or other information describing the type of underlying data, the type of values, the structure of the data, foreign key-primary key relationships, etc.) is transmitted to the LLM, thus enhancing data security.

[0007] In some examples, a computer-implemented method includes: accessing metadata and data specifying allowed operations for fields of one or more datasets stored in a hardware storage device; generating a pattern based on the accessed metadata and the accessed data, wherein the pattern 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 via a computer system; transmitting the request and pattern to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the pattern; compiling the dataset specification into a query according to the pattern, such that the query can be executed to perform the operations specified by the pattern and access the data specified by the pattern; and storing the compiled query for execution in the hardware storage device. A system of one or more computers can be configured to perform specific operations or actions by installing software, firmware, hardware, or combinations thereof on the system, which in operation causes the system to operate. A computer program can be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to operate.

[0008] In this example, when the requested data is specified by a field not represented in the schema, the dataset specification excludes the requested data. The schema is configured to exclude sensitive or personally identifiable information (PII) from the accessible data. The actions include accessing instructions from the hardware storage device that specify the exclusion of personally identifiable information (PII) or other sensitive data from the representation in the dataset specification. The method also includes: accessing predefined field names indicating PII or sensitive data; accessing field names stored in one or more datasets on the hardware storage device; and generating a schema to exclude data associated with field names corresponding to the predefined field names indicating PII or sensitive data from the accessible data. The actions include generating a computer program to perform operations, the operations including: accessing metadata and data specifying allowed operations for fields stored in one or more datasets from a hardware storage device; generating the schema based on the accessed metadata and data, wherein the schema specifies which fields are accessible in response to a request; receiving a request for data based on the one or more datasets from a client device via a computer system; transmitting the request and the schema to the artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into a query according to the schema, such that the query can be executed to perform the operations specified by the schema and access the data specified by the schema; and storing the compiled query for execution in the hardware storage device. The computer program is executed to perform operations including: accessing metadata and data specifying allowed operations for fields of one or more datasets stored in the hardware storage device; generating the schema based on the accessed metadata and data, wherein the schema specifies which fields are accessible in response to a request; receiving a request for data based on the one or more datasets from a client device via a computer system; transmitting the request and the schema to the artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into a query according to the schema, such that the query can be executed to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in the hardware storage device. Actions include verifying the dataset specification to ensure conformity to the schema. Actions include verifying the query to ensure conformity to the schema. Actions include executing the query; and, based on the execution of the query, retrieving data from the hardware storage device according to the schema.

[0009] In another example, one or more machine-readable hardware storage devices store instructions executable by one or more processing devices to perform operations including: accessing metadata and data specifying allowed operations for fields of one or more datasets stored in the hardware storage device; generating a pattern based on the accessed metadata and accessed data, wherein the pattern 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 via a computer system; transmitting the request and pattern to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the pattern; compiling the dataset specification into a query according to the pattern, such that the query can be executed to perform the operations specified by the pattern and access the data specified by the pattern; and storing the compiled query for execution in the hardware storage device.

[0010] In this example, when the requested data is specified by a field not represented in the schema, the dataset specification excludes the requested data. The schema is configured to exclude sensitive or personally identifiable information (PII) from the accessible data. The operation also includes: accessing instructions from a hardware storage device specifying that personally identifiable information (PII) or other sensitive data is excluded from the representation in the dataset specification; the method further includes: accessing predefined field names indicating PII or sensitive data; accessing field names stored in one or more datasets on the hardware storage device; and generating a schema to exclude data associated with field names corresponding to the predefined field names indicating PII or sensitive data from the accessible data. The operation further includes: generating a computer program to perform the operation, the operation including: accessing metadata and data specifying allowed operations for fields stored in one or more datasets in the hardware storage device from a hardware storage device; generating the schema based on the accessed metadata and the accessed data, wherein the schema specifies which fields are accessible in response to a request; receiving a request for data based on the one or more datasets from a client device via a computer system; sending the request and the schema to the artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into a query according to the schema, such that the query can be executed to perform the operations specified by the schema and access the data specified by the schema; and storing the compiled query for execution in the hardware storage device. The system executes the computer program to perform operations, including: accessing metadata and data specifying allowed operations for fields of one or more datasets stored in the hardware storage device; generating the schema based on the accessed metadata and data, wherein the schema specifies which fields are accessible in response to a request; receiving a request for data based on the one or more datasets from a client device via a computer system; transmitting the request and the schema to the artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the schema; compiling the dataset specification into the query according to the schema, such that the query can be executed to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in the hardware storage device. The operations also include: validating the dataset specification to ensure conformity with the schema. The operations further include: validating the query to ensure conformity with the schema. The operations further include: executing the query; and retrieving data from the hardware storage device according to the schema based on the execution of the query.

[0011] In another example, the system includes one or more processing devices; one or more machine-readable hardware storage devices storing instructions executable by the one or more processing devices to perform operations including: accessing metadata and data specifying allowed operations for fields of one or more datasets stored in the hardware storage devices; generating a pattern based on the accessed metadata and accessed data, wherein the pattern 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 via a computer system; transmitting the request and pattern to an artificial intelligence engine; receiving a dataset specification from the artificial intelligence engine, the dataset specification including a structured, machine-readable representation of the request generated according to the pattern; compiling the dataset specification into a query according to the pattern, such that the query can be executed to perform operations specified by the pattern and access data specified by the pattern; and storing the compiled query for execution in the hardware storage devices.

[0012] In this example, when the requested data is specified by a field not represented in the schema, the dataset specification excludes the requested data. The schema is configured to exclude sensitive or personally identifiable information (PII) from the accessible data. The operation also includes: accessing instructions from a hardware storage device specifying that personally identifiable information (PII) or other sensitive data is excluded from the representation in the dataset specification; the method further includes: accessing predefined field names indicating PII or sensitive data; accessing field names stored in one or more datasets on the hardware storage device; and generating a schema to exclude data associated with field names corresponding to the predefined field names indicating PII or sensitive data from the accessible data. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method. Attached Figure Description

[0013] Figure 1 It is a block diagram depicting a system for generating queries based on natural language analysis.

[0014] Figure 2 This is a block diagram showing the query generation system in detail.

[0015] Figure 3 This is a block diagram of a feedback generation system designed to provide feedback on user input during query generation.

[0016] Figure 4 An example process for generating queries based on natural language input is shown.

[0017] Figure 5This is a diagram of an example computer system. Detailed Implementation

[0018] Current query generation methods rely on LLMs to directly translate natural language user input into queries. This approach introduces significant risks, especially when querying sensitive datasets such as clinical trial data. Directly executing queries generated by LLMs can introduce errors, expose private information, and lead to unintended data modification, resulting in serious privacy and operational risks. Queries generated without security measures may include syntactic errors, allow unauthorized data access, or alter underlying data, all of which can compromise data integrity and privacy. These risks underscore the need for query generation schemes specifically tailored for sensitive data queries—schemes designed to provide controlled and validated query generation. The techniques described in this paper address these needs by automatically generating queries based on natural language input while implementing controls to mitigate privacy and security risks (e.g., compared to the privacy and security risks of not implementing these techniques). The scheme is characterized by: (i) protecting sensitive information by eliminating or reducing the need to expose the complete data model to the LLM; (ii) ensuring full control over permissible query operations on the dataset (e.g., enabling privacy-preserving query capabilities that implement logic (e.g., strict business rules); and (iii) mitigating the risk of prompt-based attacks or query injection attacks through design. This approach provides a robust privacy implementation framework for query generation in environments where data sensitivity and operational control are critical.

[0019] The disclosed examples generate queries through a method in which natural language user input is captured and processed by the LLM to produce a dataset specification, which then declaratively guides the programmatic generation of queries. Typically, a dataset specification includes a structured description defining the content, organization, format, and constraints of one or more datasets. The 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 schema of the dataset. The dataset specification may also identify data source requirements necessary for interoperability within the system, update or refresh rules, sorting or indexing parameters, and compliance or standardization guidelines (e.g., adherence to the Clinical Data Exchange Standards Association-Study Data Tabular Model (“CDISC SDTM”) or the International Organization for Standardization (“ISO”) format). This ensures high-quality, accurate query operations while restricting unauthorized actions. The resulting queries (e.g., SQL) can be executed on the dataset while maintaining strict oversight of permitted query functionality. Furthermore, this method limits the LLM's exposure to essential data elements, such as schemas or metadata, thereby reducing the risk of information leakage and enhancing data protection.

[0020] Given the significant risks posed by LLMs in the unintentional disclosure of information about the data on which these models are trained and exposed, maintaining data privacy is paramount. Current security measures and safeguards used for these models are truly limited in distinguishing between permitted actions and the protection of sensitive information, resulting in a non-negligible possibility that sensitive data could be exposed during normal or malicious interactions with LLMs. Considering the importance of protecting data privacy and the significant financial and unfair consequences of unintentional disclosure, technologies built using LLMs (especially those manipulating sensitive information such as patient health records) need to ensure security mechanisms that deterministically restrict information and operations. The included methods and systems describe the use of LLMs to generate queries mediated by a dataset specification, which acts as a constraint for implementing security mechanisms to ensure (i) the disclosure of sensitive information and (ii) that the operations to be performed by the generated queries conform to the dataset specification in the system.

[0021] refer to Figure 1 The diagram illustrates a system 100 for automatically generating a query 150 using natural language user input 120. System 100 receives natural language user input 120 from user input capture system 110. Natural language user input 120 may include specific instructions in natural language, such as: a subset of data (“List the data extracted from system X between 2010 and 2020”), a transformation of the data (“List the number of unique users in the dataset”), or other expressions (“List the number of users and data points in system X”). Natural language user input 120 is passed to query generation system 130, which combines it with metadata from database 140 to create query 150. This method is not limited to a single database in its application and can be applied across multiple databases.

[0022] refer to Figure 2 Environment 200 is shown together with query generation system 130, client device 201, LLM 240, schema generator 249, database 270, and execution system 330. Query generation system 130 includes dataset specification engine 210 and query transcriber engine 280. Dataset specification engine 210 includes dataset specification generation engine 220 (for generating dataset specifications, for example, by sending prompts to LLM 240) and dataset specification validation engine 230 (for validating dataset specifications). Query transcriber engine 280 includes query building engine 290 and query validation engine 300, as described below.

[0023] 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, which generates a dataset specification schema 250 (hereinafter referred to as "schema 250") using database metadata 260 included in the database 270. That is, the schema generator 249 can use the database metadata 260 to construct schema 250, which describes the attributes and values ​​available for use by the LLM 240. Schema 250 can also specify relationships between fields in the dataset stored in the database 270, as well as specify the fields themselves (e.g., field names).

[0024] Specifically, database metadata 260 can specify enumerated values ​​(or the type of values) associated with each field of the dataset stored in database 270. Database metadata 260 can also specify the field types (and associated field names) of the dataset stored in database 270. The attributes of pattern 250 can also be determined by permitted operations, which can be specified in database metadata 260, in other data retrieved from database 270, or in a control source, as described below. Permitted operations are a set of operations that can be notified by policies and requirements, including: (i) system functional requirements, (ii) technical policies, (iii) legal policies, (iv) data and framework restrictions, and (v) other non-functional requirements. Permitted operations are essential for implementing policies and controls, where result queries will only include permitted operations. For example, permitted operations can be specified as masking, tokenizing, and encrypting personally identifiable information (PII). In some examples, permitted operations are included or restricted to filtering rows of a dataset using values ​​from a specific set of columns. The permitted operations will define how pattern 250 is defined and will also inform the downstream query transpiler engine 280. Depending on the complexity of the permitted operations (as instructed by the system requirements), pattern 250 may allow nesting and / or changes to the composition of the dataset specification to allow for flexibility and additional user control. For example, when user input 202 requests an operation that is not a permitted operation, the dataset specification engine 210 may refuse or decline to generate the dataset specification. In this example, the dataset specification engine 210 transmits a rejection to the client device 201 based on the permitted operations, indicating why the request is not satisfied.

[0025] Pattern generation

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

[0027] Permitted operations are determined based on one or more control sources that define permissible query actions within the system. Control sources may be located within or outside environment 200. These control sources may include: (i) functional requirements—constraints derived from the intended functionality of the application or service (e.g., enabling only aggregation and filtering operations required for reporting workflows); (ii) technical policies—rules embedded in the system architecture, such as restrictions on computationally expensive connections, constraints on maintaining system performance, or prohibitions on full table scans; (iii) legal and compliance policies—requirements imposed by regulatory frameworks, contractual terms, or data management rules restricting access to certain fields or combinations of fields (e.g., health insurance portability and accountability bill restrictions on personally identifiable health data); (iv) data and framework restrictions—constraints imposed by the characteristics of the underlying data source or analytics framework, including restrictions on data types, supported query syntax, or schema-level constraints; and (v) other requirements—including security controls, access privileges, or user role-based restrictions.

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

[0029] To construct schema 250, schema generator 249 first performs syntactic analysis on database metadata 260 to obtain a baseline structure definition of the dataset, including available attributes, their associated value ranges (e.g., enumerated values), relational constraints (e.g., primary keys and foreign keys), indexing information, and any inherent schema-level rules. Schema generator 249 then cross-references this baseline with permitted operations to generate a constrained, policy-compliant schema. This cross-reference process may remove attributes or relations not subject to any permitted operations, or may annotate attributes with constraints derived from permitted operations (e.g., permitted filter values, supported aggregate functions, or permissible join conditions).

[0030] In some examples, the schema generator 249 applies composition rules, thereby conditionally enabling certain permitted operations only for specific data types or enumeration values ​​specified in the database metadata 260. For example, aggregation operations may be permitted only for numeric fields identified in the metadata, while filtering operations may be constrained to categorical fields with enumeration values.

[0031] The resulting schema 250 is machine-readable and describes the available dataset elements (and the relationships between these elements) and the permitted ways to access or manipulate these elements. By embedding policies and metadata constraints directly into the schema, the system (e.g., Figure 1 The system 100 ensures that all downstream query generation (such as query generation performed by the dataset specification generation engine 220 and the query translator engine 280) complies with both technical feasibility and policy compliance.

[0032] PII Identification and Handling

[0033] Pattern generator 249 uses a combination of the following to determine whether a given attribute in database metadata 260 constitutes a PII: (i) metadata classification - examining the description of column-level management labels, notes, or privacy labels (e.g., “PII”, “Protected Health Information (PHI)”, “Confidential”); (ii) naming pattern detection - matching field names against a policy-defined list of keywords (e.g., “Name”, “SSN”, “DOB”, “Email”, “Phone”, “Address”); (iii) format and type analysis - matching data types and lengths to known identifier formats (e.g., a nine-digit SSN, a specific regular expression (regex) pattern for a phone number, or an email address); and (iv) sample value examination - optionally sampling a subset of non-sensitive data for pattern matching or machine learning-based classification to detect identifiers or quasi-identifiers.

[0034] A PII classification policy stored in a policy store (e.g., included in database 270 or included in another database) maps database field identifiers to privacy categories such as “direct identifier,” “quasi-identifier,” and “non-PII.” The schema generator 249 cross-references this classification with permitted operations to determine appropriate disposition. For the “direct identifier” field, the schema generator 249 may (a) omit the attribute entirely from schema 250, (b) replace it with a tokenized or anonymized representation, or (c) include the attribute where there are restricted permitted operations (e.g., disallowing grouping or filtering that might reveal a single record). For the “quasi-identifier” field, additional statistical privacy thresholds (e.g., minimum group size) may be implemented through permitted operations.

[0035] In other words, after PII detection, pattern generator 249 constructs pattern 250 by including only attributes that are permissible under applicable technical, operational, and privacy policies. Pattern 250 includes a hierarchical, machine-readable representation of permissible dataset elements and their associated operational constraints, designed to enable the generation of policy-compliant queries while preventing the exposure of the PII from database 270.

[0036] At the top level, pattern 250 includes a root dataset node 258 that references one or more attribute nodes (e.g., attribute 1 node 252, attribute 2 node 254). Each attribute node corresponds to a dataset field identified through syntactic analysis of database metadata 260, and can specify the field name, data type, enumerated value range, relational constraints (e.g., primary and foreign keys), join logic across different datasets, and indexing information. For each included attribute, pattern 250 can include child nodes derived from database metadata 260 and filtered by allowed operations, such as enumerated value nodes 256 (listing allowed categorical values) and constraint nodes 257 (listing permitted operators, aggregate functions, or join keys). Pattern 250 also specifies the relationships between nodes.

[0037] When LLM 240 receives user input 202 (e.g., from client device 201), it references pattern 250 to determine the valid attributes, enumerations, and operations used to construct dataset specification 251. Because pattern 250 excludes or masks fields containing PIIs and restricts high-risk operations, LLM 240 cannot generate dataset specifications that directly or indirectly expose PIIs from database 270. That is, pattern 250 can exclude any field containing a PII, or can include only the field name (not the value itself). This ensures that downstream components (including dataset specification validation engine 230, query transpiler engine 280, and query building engine 290) operate solely on a privacy-preserving, policy-compliant subset of the underlying data. By combining database metadata 260, permitted operations, and automatic PII detection, pattern generator 249 produces a constrained hierarchical pattern 250 that enables the generation of natural language queries while enforcing privacy requirements and regulatory compliance.

[0038] User input 202 and pattern 250 are passed to LLM 240. The hyperparameters of LLM 240 can be configured to implement highly deterministic and repeatable behavior. This is important because users may expect the same natural language specification to produce the same output across repeated attempts. The use of function calls also encourages this behavior. LLM 240 can also be fine-tuned to improve the performance of generating the dataset specification specified by pattern 250.

[0039] Fine-tuning

[0040] In some examples, LLM 240 is fine-tuned to improve its performance in generating dataset specifications that conform to pattern 250 and comply with permitted operations. 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. A training dataset is constructed using a historical dataset specification that has been validated for pattern 250 and successfully used to generate compliant queries Q. Training examples may include: (i) a natural language request to the data (similar to user input 202); (ii) the corresponding pattern 250 valid at generation time; and (iii) an empirically validated dataset specification as a result. LLM 240 is trained to map combinations of natural language input and pattern constraints to the correct, policy-compliant dataset specification output.

[0041] Fine-tuning can include negative sampling, where examples of non-compliant or invalid dataset specifications are provided along with the correct output, and the model is penalized for producing non-compliant results. This improves the sensitivity of LLM to schema-level constraints, enumeration values, and permitted operations.

[0042] 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) directly compatible with the downstream query building engine 290. The training process can also incorporate cue templates that explicitly include pattern 250 as input, thereby teaching LLM reference pattern constraints during generation, rather than relying solely on statistical relevance.

[0043] Reinforcement learning can be further applied, where the LLM output is scored by the dataset specification validation engine 230. Outputs that pass validation against pattern 250 and allowed operations are assigned higher rewards, while outputs that fail validation are penalized. The LLM then receives reward signals (as input) specifying which outputs receive higher rewards. These reward signals are then used to adjust the LLM parameters during training. This iterative feedback loop gradually biases the LLM 240 towards producing semantically correct outputs that conform to operational, technical, and policy constraints. Through this fine-tuning process, the LLM 240 develops a specialized ability to interpret natural language requests based on the constraints defined by the pattern, resulting in deterministic and reproducible dataset specification that can be seamlessly integrated into the query generation system 130. Supervised learning can be applied to fine-tune the LLM output by requesting user feedback and combining that feedback into labels to fine-tune the LLM's performance against those labels.

[0044] Along with user input 202 and pattern 250, additional instructions in the form of system prompts can be provided to LLM 240 (e.g., from client device 201) to improve the performance of generating dataset specification 251. System prompts may include information about (i) a description of the domain / business object, (ii) an explanation of the attributes in pattern 250, and / or (iii) additional information about constraints when generating dataset specification 251. Additionally, few-shot prompts can be provided to add additional context, details, and / or limitations and constraints.

[0045] Few-sample hint generation and use

[0046] In this example, given pattern 250 and the permitted operations, the system employs few-shot hints to improve the performance of LLM 240 in generating dataset specification 251 based on user input 202. Few-shot hints involve presenting a small number of representative input-output examples to LLM 240 before requesting the model's own output, thereby tuning the model to follow the desired transformation pattern. By providing examples that conform to the constraints and permitted operations embodied in pattern 250, the system biases LLM 240 towards generating a policy-compliant and technically feasible dataset specification.

[0047] In some examples, few-sample hints are dynamically constructed based on historical dataset specification records stored in association with the query generation system 130. Each record may include: (i) a natural language request for the data, similar to user input; (ii) the permitted operations and pattern 250 applicable at the time of the request; and (iii) a validated 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 different query structures, permitted operations, and field constraints defined by pattern 250.

[0048] For example, the first example could show a simple filtering operation constrained by the enumerated values ​​in pattern 250, the second example could show an aggregation permitted only on numeric fields, and the third example could show a join operation limited to specific key pairs defined in the permitted operations. In some cases, the system chooses to show examples of combinations of permitted operations, such as applying aggregation only after filtering on categorical fields.

[0049] A few-sample hint can be generated at runtime to reflect the current state of pattern 250 and permitted operations, thus adapting to changes in database metadata 260, policy store contents, or user access privileges. In such an example, the hint generates one or more historical records that logically retrieve the current constraint, formats them into a structured hint, and appends the hint to the system hint before submitting it to LLM 240.

[0050] Including few-shot cues in the input of LLM 240 improves the model's ability to generate deterministic and reproducible dataset specifications 251 that follow the current pattern 250 and permitted operations. In some examples, the few-shot cue format is used as part of its training dataset to fine-tune the model, thereby enhancing the model's learned behavior to explicitly reference pattern-level constraints during generation, rather than relying solely on statistical relevance from its pre-training corpus. This integration of dynamically constructed few-shot cues with pattern-aware fine-tuning provides a technical improvement in ensuring that the generated dataset specifications are semantically correct and conform to operational, technical, and policy constraints.

[0051] LLM 240 can be equipped with (i) a "query generation" tool and (ii) a "reject" tool via function calls. If a request from user input 202 cannot be supported by pattern 250, LLM 240 can choose to use the reject tool, prompting the dataset specification engine 210 to decline the request and providing an explanation to the user. The rejection tool may be prompted for a variety of reasons, including but not limited to: (i) an inappropriate request, (ii) a request that includes an operation not permitted by the pattern, (iii) a request for incorrect or unavailable data, or (iv) a malicious attempt to extract system prompts or other information about data not permitted by the pattern. The generated explanation to the user may include information about: (i) the reason why the request was unsuccessful, (ii) possible modifications to the user input that could lead to successful query generation, and / or (iii) permitted operations and sample user input that the user can try to replace the original request.

[0052] The pattern matches the confirm / deny trigger.

[0053] LLM 240 determines whether a dataset specification can be generated for user input 202 by evaluating the pattern 250 and the permitted operations request. Pattern 250 is provided to LLM 240 in a machine-readable format (such as a JSON document) that enumerates the available attributes in the dataset, associated data types, enumerated value ranges, relational constraints (e.g., foreign key relationships), permitted joins, permitted aggregation and filtering for each attribute, and any user-specific access restrictions. Permitted operations derived from policy data and database metadata 260 are also supplied to LLM 240 as structured input.

[0054] In some examples, the function call interface used for the query generation tool implements the constraints and allowed operations derived from pattern 250. For example, the interface could be defined by a JSON pattern or an equivalent type system, where parameter values ​​are restricted to valid data types (e.g., enumerations) from pattern 250. When LLM 240 attempts to generate dataset specification 251, any attempt to issue an attribute, operation, or enumeration value that does not exist in pattern 250 or the allowed operations will cause the decoding process to fail constraint validation. In the event of such a failure, LLM 240 chooses to reject the tool instead of the query generation tool, prompting dataset specification engine 210 to decline the request and return a structured interpretation to client device 201.

[0055] In some examples, LLM 240 can invoke schema lookup tools during generation to resolve conditional permissions or schema version creation. For instance, the "lookup_field" function can return whether a requested field exists in the current schema 250; the "is_operation_allowed" function can return whether a specified operation is permitted for a given attribute; and the "join_allowed" function can indicate whether two entities are joinable under the current constraints. If any lookup indication is non-compliant, LLM 240 invokes the denial tool.

[0056] In some examples, dataset specification 251 undergoes deterministic post-generation validation performed by dataset specification validation engine 230. Engine 230 validates that (i) the referenced attributes exist in pattern 250, (ii) the attribute usage is type-compatible, (iii) the categorical value matches the enumerated domain, (iv) the join operation is explicitly permitted, and (v) user-specific access controls are satisfied. If validation fails, dataset specification validation engine 230 returns an error code and principle (e.g., “FIELD_NOT_FOUND”, “JOIN_FORBIDDEN”, or “VALUE_OUT_OF_RANGE”), which LLM 240 displays via a rejection tool to generate an explained rejection response.

[0057] In some examples, the system prompts LLM 240 to treat pattern 250 and permitted operations as authoritative, and a few sample prompts include both compliant generation and rejection scenarios. This condition strengthens the behavior of the model's selective rejection tool when a request cannot be satisfied under the current pattern constraints. For dynamic databases, pattern 250 may include a version identifier; if user input 202 references an object from a different version, the pattern lookup tool may return a pattern mismatch result, also triggering a rejection path. For role-based access control, an access-filtered version of pattern 250 is generated for each request, omitting attributes or operations outside the user's privileges, thus making requests that are valid in other cases appear unsupported and leading to a principled rejection. Through this architecture, rejection can be directly traced back to the constraints embodied in pattern 250 and permitted operations, thereby ensuring that dataset specification 251 is technically feasible, policy-compliant, and executable by the downstream query building engine 290.

[0058] If the LLM 240 selects the query generation tool, it can generate a dataset specification 251 (e.g., a structured JSON-like object) that follows pattern 250 and will be passed through the rest of the pipeline. In this example, the LLM 240 transmits the dataset specification 251 to the dataset specification generation engine 220.

[0059] Pattern-driven dataset specification generation

[0060] In some examples, when the LLM 240 selects a query generation tool, it produces a structured dataset specification 251 that conforms to pattern 250 and satisfies permitted operations. Pattern 250 provides the LLM 240 with an authoritative, machine-readable representation of the structure and operational constraints of the dataset. Pattern 250 can be encoded in a structured format (e.g., JSON, YAML, XML) and can enumerate the data type, permissible value range, relational relationships, and subsets of permitted operations for each available attribute. Pattern 250 can also include cross-attribute constraints, conditional rules (e.g., aggregations permitted only if a corresponding grouping field exists), and user-specific restrictions derived from policy data.

[0061] During dataset specification generation, pattern 250 is fed to LLM 240 as part of its input context, optionally along with system prompts and few-shot prompts. LLM 240 performs syntactic analysis on pattern 250 to identify attributes and actions 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 of age,” LLM 240 consults pattern 250 to determine that: (i) the attribute “systolic_bp” is numeric and supports aggregation using the “avg” function; (ii) “age” is of type “integer” and can be filtered using comparison predicates (e.g., >60); and (iii) “gender” is a categorical field with enumerated values ​​including “male” and “female.” The resulting dataset specification 251 includes only the actions permitted in the pattern, represented in a structured JSON-like format suitable for downstream processing.

[0062] In some examples, Pattern 250 also guides value normalization and constraint annotations during generation. For instance, if Pattern 250 specifies the use of the “YYYY-MM-DD” format for a date field, LLM 240 can normalize any date literal accordingly. If a filter value is not in the enumeration domain, the model can omit it or replace it with the closest valid alternative, depending on system prompts. Constraints provided by the pattern can also be directly embedded into the dataset specification 251, such as permitted filter operators for a given field, allowed join keys, or aggregate granularity restrictions.

[0063] Once constructed, the dataset specification 251 is transmitted 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 building engine 290. This validation step verifies that all fields, operations, and values ​​in the dataset specification 251 exist and are permitted in the schema 250, thereby ensuring that the resulting query is technically feasible, policy-compliant, and optimized for the underlying database 270.

[0064] By directly embedding pattern 250 into the process implemented by the dataset specification engine 210, the system ensures that natural language-driven query creation remains defined by explicit machine-readable constraints. This provides a technical improvement over unconstrained natural language systems that may generate semantically reasonable but technically invalid queries, thereby reducing execution errors, improving compliance with operational and legal policies, and enhancing the deterministic repeatability of query generation.

[0065] Specifically, the dataset specification validation engine 230 verifies that the attributes in dataset specification 251 are limited to those specified by pattern 250, and extracts the values ​​of those attributes from the enumeration in the pattern where applicable. In this example, the dataset specification validation engine 230 outputs an empirical version of dataset specification 251. For convenience and not limitation, the empirical version of dataset specification 251 is also referred to as dataset specification 251. This validation step ensures that query translator engine 280 processes dataset specification 251 without errors (or with reduced errors), as described below.

[0066] Within the query transcriber engine 280, the query building engine 290 programmatically transcribs the dataset specification 251 into query 150. Typically, transcribing involves translating code written in one programming language into code written in another.

[0067] The query transpiler engine 280 (and its sub-components: (i) the query building engine 290 and (ii) the query validation engine 300) is designed around permitted operations (including data restrictions, access controls, policies, permitted query operations, and other non-functional requirements) and pattern 250. For example, in a system where permitted operations are restricted to filtering a dataset using a specific set of columns, the properties of pattern 250 can be defined as the names of the columns that will be 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 can be stored as a JSON-like object to store the properties to be used for filtering the dataset and their corresponding values. In this case, the query transpiler engine 280 can be designed to programmatically construct queries (e.g., SQL queries) where the properties within the dataset specification 251 will be 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 would be "SELECT ... "FROM user WHERE user_name='Jane Doe'". In this example, query translator engine 280 consults schema 250 to resolve the logical field "user_name" into its concrete database representation. Schema 250 can be specified as the logical field "user_name" corresponding to the column "user_name" in a user table (e.g., a table named "user"). By performing this resolution step at runtime, query translator engine 280 ensures that the abstract properties in dataset specification 251 are correctly bound to the actual table and column identifiers of the dataset in database 270.

[0068] Permitted operations can be extended to selection of a subset of columns, aggregation across one or more columns, and / or other related operations. Depending on the permitted operations, pattern 250 and query translator engine 280 are designed to accommodate these operations, restrictions, strategies, and controls.

[0069] In other words, the query transcriber engine 280 (also referred to herein as transcriber 280 for convenience and not limitation) includes a query generator (e.g., an SQL generator) specifically designed to transcrib only those dataset specifications that conform to the rules in pattern 250 and the allowed operations. Pattern 250 defines which fields and operations are possible, while the allowed operations define how those fields can be used. The dataset specification 251 acts as a bridge between the two, capturing specific compatible instructions for a single request in a format that the transcriber 280 can directly translate into a valid query. This design means that the transcriber 280 does not have to interpret the raw natural language or guess the user's intent; instead, the transcriber 280 simply maps the structured instructions in the dataset specification 251 to executable queries, making the system more predictable, secure, and easier to audit.

[0070] By requiring query transpiler engine 280 to operate specifically on a pre-generated dataset specification 251 validated against pattern 250 and permitted operations, the system provides additional technical protection against unauthorized or non-compliant query execution. Specifically, because dataset specification 251 includes a structured, machine-readable intermediate representation of the user's request—separate from the executable query—it can be fully inspected by dataset specification validation engine 230 before being accepted by query building engine 290. This separation of concerns ensures that transpiler 280 never processes raw, unconstrained natural language input, thus eliminating opportunities for policy evasion, SQL injection, or accidental inclusion of restricted fields (such as PII) from database 270. Furthermore, this architecture enables deterministic implementation of operational controls: even as pattern 250 and permitted operations change over time, dataset specification 251 reflects a compatible, context-specific subset of dataset capabilities, and transpiler 280 is encoded to render only queries that remain within that subset. This two-stage process—generating a dataset under schema constraints and then translating it under the same constraints—results in a system that is not only flexible and portable across different database engines, but also inherently more secure, more auditable, and more resistant to unintentional or malicious query expansions that exceed authorized parameters.

[0071] The generated query passes through query validation engine 300, which ensures that query 150 is executed securely. Typically, validation includes (i) ensuring “secure” output and (ii) ensuring that the returned value is actually one of the values ​​in the data. Regarding (i), query validation engine 300 passes the query through content and compliance filters to ensure that the query meets content and privacy policies, etc. For example, secure output might refer to content that has already passed through such filters (sometimes called “guardrails”). Regarding (ii), query validation engine 300 validates before running the query that any literal values ​​or parameters in the query actually exist in the database. For example, if the generated query specifies “SELECT ... If the query is executed using the command "FROM users WHERE country='XYZ'", the system can first verify that 'XYZ' is a valid country code contained in the underlying data, thereby preventing the execution of queries that will not return results or indicate that the query will produce invalid or deviate from the target value.

[0072] In some examples, the parameters of query 150 (e.g., bind parameters) are extracted and validated themselves. Typically, bind parameters are placeholder parameters that are bound to actual values ​​at runtime. Using bind parameters improves efficiency because they allow the database to reuse the execution plan instead of recompiling the SQL statement each time. In this example, query validation engine 300 checks whether the bind parameters meet expected criteria (e.g., conform to expected rules or formats, such as correct type (integer, string), allowed value range, no malicious input, etc.).

[0073] Given the system's architecture (where the schema and allowed operations directly dictate how query building engine 290 constructs query 150), the chance of failure is reduced or minimized. Query validation engine 300 is designed according to the schema and allowed operations to ensure compliance with the system's functional and non-functional requirements. In some examples, query validation engine 300 receives schema 250 and is configured to verify that query 150 conforms to schema 250. In other examples, query validation engine 300 is pre-programmed according to schema 250, for example, to ensure that the query conforms to schema 250. Query validation engine 300 outputs query 150. Execution system 330 executes query 150 on data in database 270 (e.g., dataset 331), for example, to generate results and transmit these results to client device 201. In this example, the results include fields and data specified by schema 250 and allowed operations as accessible for retrieval.

[0074] As described herein, query transpiler engine 280 consumes dataset specification 251 and concurrent schema 250 during query construction. Although the consistency of dataset specification 251 has been previously verified, schema 250 serves as the source of truth at execution time, which (i) resolves dataset specification fields into concrete database objects (e.g., table / column identifiers, key relationships, and required join paths); (ii) provides the data types, formatting, and collation rules required to present predicates correctly in terms of syntax and semantics; (iii) applies policy-bound transformations, such as masks, tokenization, or aggregation thresholds that can be updated after dataset specification 251 is generated; (iv) maps logical operations in dataset specification 251 to engine-specific constructs (e.g., SQL dialect features, optimizer hints, or access control views); and (v) revalidates compliance with currently permitted operations in the event of policy or metadata drift. By binding query construction to pattern 250, translator 280 implements a defense-in-depth model, where non-compliant, outdated, or ambiguous instructions in dataset specification 251 cannot produce executable queries, thus ensuring correctness, cross-backend portability, and deterministic compliance with technical and security controls. The generated query 150 can be executed on the dataset of interest to obtain the desired output results. These results can be sent to the user via additional tools in system 100 (…). Figure 1 Export or preview in ).

[0075] The query building engine 290 can also generate user-friendly, readable "outer-oriented queries," which can be presented to the user to ensure that the query matches the user's expectations. These "outer-oriented queries" can also be used to track a set of operations performed on the underlying data to generate the desired output, adding transparency and traceability to the process. Tables from the "outer-oriented queries" can be matched against tables generated by query 150 via transformations that can be performed within common table expressions.

[0076] refer to Figure 3The diagram illustrates a feedback generation engine 310. The feedback generation engine 310 can take a generated query 150, a pattern 250, and user input (not shown) as input. The feedback generation engine 310 can use an LLM 240 to generate feedback 320 indicating how the request is processed, which is presented back to the user. The feedback may also include suggestions for modification, such as how or how the request should be rephrased to better align with the attributes defined in the pattern, and reasons for a partially satisfied response. The engine can take an "outer-facing" query instead of the generated query 150 as input. Additional details can be added to system prompts and / or few-sample prompts to provide guidance on the content of the feedback 320. The LLM 240 can be fine-tuned to generate feedback, thereby improving the tone, style, understanding, guidance, quality, and / or other characteristics of the generated feedback that may be important to the user experience.

[0077] In addition to the description and figures above, the implementation can be based at least in part on the following method pseudocode for generating queries using natural input, as shown in Table 1 below:

[0078]

[0079] Table 1

[0080] refer to Figure 4 Example process 400 for generating queries based on natural language input is shown. In this example, the system accesses (402) metadata and data specifying allowed operations for fields of one or more datasets stored in the hardware storage device from a hardware storage device. The system generates (404) a schema based on the accessed metadata and data, wherein the schema specifies which fields are accessible in response to a request. The system receives (406) a request for data based on one or more datasets from a client device via a computer system. The request includes natural language input. The system transmits (408) the request and schema to an artificial intelligence engine. The system receives (410) a dataset specification from the artificial intelligence engine, which includes a structured, machine-readable representation of the request generated according to the schema. The system compiles (412) the dataset specification into a query based on the schema, such that the query can be executed to perform the operations specified by the schema and access the data specified by the schema. The system stores (414) the compiled query for execution in the hardware storage device.

[0081] refer to Figure 5This illustrates an example operating environment for implementing the techniques described herein, and is generally designated as computing device 130. Computing device 130 (also referred to as a computer, data processing system, client, or server) includes one or more programmable processors 132 for acting according to instructions and one or more memory devices 134 for storing instructions and data. Typically, the computer will also include (via bus 131, fiber optic, network, etc.) operably coupled to I / O components 136 (e.g., display devices, network / communication subsystems, etc. (not shown)), one or more mass storage devices 138 for storing data and instructions, etc., and a network communication subsystem 140 powered by a power supply (not shown). Within memory 134 are an operating system 134a and applications 134b for application programming.

[0082] Computer program instructions and data can be stored in a non-transitory form, such as embodied in volatile or non-volatile storage media or any other non-transitory medium, using the physical properties of the medium (e.g., surface pits and plateaus, magnetic domains, or charges) for a period of time (e.g., the time between refresh cycles of a dynamic memory device such as dynamic RAM). When ready to load instructions, the software can be provided on a tangible non-transitory medium, such as a CD-ROM or other computer-readable medium (e.g., readable by a general-purpose or special-purpose computing system or device), or transmitted via a network communication medium (e.g., encoded in a propagating signal) to a tangible non-transitory medium of the computing system executing the software. Some or all of the processing can be executed on a dedicated computer or using dedicated hardware, such as a coprocessor or a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). The processing can be implemented in a distributed manner, where different parts of the computation specified by the software are executed by different computing elements. Such computer programs are each stored in or downloaded (from cloud computing infrastructure or other remote sources) to a computer-readable storage medium (e.g., solid-state memory or medium, or magnetic or optical medium) accessible by a general-purpose or special-purpose programmable computer, for configuring and operating the computer when the storage medium is read by the computer to perform the processes described herein. Such computer programs can also be accessed as services provided by cloud computing infrastructure. The examples described herein can also be implemented as tangible, non-transitory media configured with computer programs, wherein such configured media causes the computer to operate in a specific and predefined manner to perform one or more processing steps described herein.

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

[0084] To provide interaction with the user, examples of the subjects described in this specification can be implemented on a computer having a display device (monitor) for displaying information to the user and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Additionally, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a webpage to a web browser on the user's device in response to a request received from a web browser.

[0085] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes backend components (e.g., as a data server), or middleware components (e.g., an application server), or frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with an implementation of the subject matter described in this specification), or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), interconnected networks (e.g., the Internet), and peer-to-peer networks (e.g., self-organizing peer-to-peer networks).

[0086] A computing system may include clients and servers. Clients and servers are typically geographically separated and interact via a communication network. The client-server relationship is established by computer programs running on respective computers and having a client-server relationship with each other. In some examples, the server transmits data (e.g., HTML pages) to the client device (e.g., for the purpose of displaying data to a user interacting with the user device and receiving user input from that user). Data generated at the client device (e.g., the result of user interaction) can be received at the server from the client device.

[0087] This disclosure also provides a computer program product that stores instructions that, when executed by a processor, cause the processor to implement the methods described in this disclosure.

[0088] Although this specification contains many specific implementation details, these should not be construed as limiting the scope of any invention or claimable content, but rather as descriptions of features specific to the implementations of the systems and methods described herein.

[0089] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order, or to perform all illustrated operations to achieve the desired result. Furthermore, the separation of the various system components in the above implementation should not be construed as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or encapsulated in multiple software products.

[0090] Several examples have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of the techniques described herein. For example, some of the steps described above may be sequentially independent and therefore may be performed in a different order than described. Thus, other examples are within the scope of the appended claims.

[0091] Priority Statement

[0092] This application claims priority to U.S. Patent Application Serial No. 63 / 724,971, filed November 26, 2024, pursuant to 35 U.SC 119(e), the entire contents of which are incorporated herein by reference.

Claims

1. A computer-implemented method comprising: accessing, from hardware storage, metadata specifying fields of one or more data sets stored in the hardware storage and data specifying allowed operations; generating a schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in responding to requests; receiving, by a computer system, a request from a client device for data based on the one or more data sets; transmitting the request and the schema to an artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising a structured, machine-readable representation of the request that has been generated according to the schema; compiling the data set specification into a query according to the schema such that the query is executable to perform the operations specified by the schema and access the data specified by the schema; and storing the compiled query for execution in the hardware storage.

2. The computer-implemented method of claim 1, wherein the data set specification excludes requested data when the requested data is specified by a field not represented in the schema.

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

4. The computer-implemented method of claim 1, further comprising: accessing, from the hardware storage, instructions specifying that personally identifiable information (PII) or other sensitive data is excluded from representation in a data set specification, the method further comprising: accessing a predefined field name indicative of PII or sensitive data; accessing field names of the one or more data sets stored in the hardware storage; and generating the schema to exclude data associated with field names corresponding to the predefined field name indicative of PII or sensitive data from accessible data.

5. The computer-implemented method of claim 1, further comprising: generating a computer program to perform operations comprising: accessing, from hardware storage, metadata specifying fields of one or more data sets stored in the hardware storage and data specifying allowed operations; generating the schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in responding to requests; receiving, by a computer system, the request from a client device for data based on the one or more data sets; transmitting the request and the schema to the artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising the structured, machine-readable representation of the request that has been generated according to the schema; compiling the data set specification into the query according to the schema such that the query is executable to perform the operations specified by the schema and access the data specified by the schema; and storing the compiled query for execution in the hardware storage; and ​ executing the computer program to perform operations comprising: accessing, from hardware storage, metadata specifying fields of one or more data sets stored in the hardware storage and data specifying allowed operations; generating a schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in responding to requests; receiving, by a computer system, a request from a client device for data based on the one or more data sets; transmitting the request and the schema to an artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising a structured, machine-readable representation of a request that has been generated according to the schema; compiling the data set specification into the query according to the schema such that the query is executable to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in the hardware storage.

6. The computer-implemented method of claim 1, further comprising: validating the data set specification to ensure compliance with the schema.

7. The computer-implemented method of claim 1, further comprising: validating the query to ensure that the query complies with the schema.

8. The computer-implemented method of claim 1, further comprising: executing the query; and based on the execution of the query, retrieving data from the hardware storage according to the schema.

9. One or more machine-readable hardware storage devices storing instructions executable by one or more processing devices to perform operations comprising: accessing, from hardware storage, metadata specifying fields of one or more data sets stored in the hardware storage and data specifying allowed operations; generating a schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in responding to requests; receiving, by a computer system, a request from a client device for data based on the one or more data sets; transmitting the request and the schema to an artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising a structured, machine-readable representation of a request that has been generated according to the schema; compiling the data set specification into the query according to the schema such that the query is executable to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in the hardware storage.

10. The one or more machine-readable hardware storage devices of claim 9, wherein the data set specification excludes requested data when the requested data is specified by a field not represented in the schema.

11. The one or more machine-readable hardware storage devices of claim 9, wherein the schema is configured to exclude sensitive information or personally identifiable information (PII) from accessible data. ​ ​ 12. The one or more machine-readable hardware storage devices of claim 9, wherein the operations further comprise: accessing, from the hardware storage device, instructions specifying that the personally identifiable information (PII) or other sensitive data is excluded from representation in a data set specification, the operations further comprising: accessing a predefined field name indicative of PII or sensitive data; accessing field names of the one or more data sets stored in the hardware storage device; and generating the schema to exclude data associated with field names corresponding to the predefined field name indicative of PII or sensitive data from accessible data.

13. The one or more machine-readable hardware storage devices of claim 9, wherein the operations further comprise: generating a computer program to perform operations comprising: accessing, from hardware storage device, metadata specifying fields of one or more data sets stored in the hardware storage device and data specifying allowed operations; generating the schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in response to a request; receiving, by a computer system, the request for data based on the one or more data sets from a client device; transmitting the request and the schema to the artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising a structured, machine-readable representation of the request that has been generated according to the schema; compiling the data set specification into the query according to the schema such that the query is executable to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in hardware storage device; and performing the computer program to perform operations comprising: accessing, from hardware storage device, metadata specifying fields of one or more data sets stored in the hardware storage device and data specifying allowed operations; generating the schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in response to a request; receiving, by a computer system, the request for data based on the one or more data sets from a client device; transmitting the request and the schema to the artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising a structured, machine-readable representation of the request that has been generated according to the schema; compiling the data set specification into the query according to the schema such that the query is executable to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in hardware storage device.

14. The one or more machine-readable hardware storage devices of claim 9, wherein the operations further comprise: verifying the data set specification to ensure compliance with the schema.

15. The one or more machine-readable hardware storage devices of claim 9, wherein the operations further comprise: validating the query to ensure that the query conforms to the schema.

16. The one or more machine-readable hardware storage devices of claim 9, wherein the operations further comprise: executing the query; and retrieving data from hardware storage devices according to the schema based on the execution of the query.

17. A system comprising: one or more processing devices; one or more machine-readable hardware storage devices storing instructions executable by the one or more processing devices for performance of operations comprising: accessing, from hardware storage devices, metadata specifying fields of one or more data sets stored in the hardware storage devices and data specifying allowed operations; generating a schema from the accessed metadata and the accessed data, wherein the schema specifies which of the fields are accessible in response to a request; receiving, by a computer system, a request from a client device for data based on the one or more data sets; transmitting the request and the schema to an artificial intelligence engine; receiving, from the artificial intelligence engine, a data set specification comprising a structured, machine-readable representation of the request that has been generated according to the schema; compiling the data set specification into a query according to the schema such that the query is executable to perform operations specified by the schema and access data specified by the schema; and storing the compiled query for execution in hardware storage devices.

18. The system of claim 17, wherein the data set specification excludes requested data when the requested data is specified by a field not represented in the schema.

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

20. The system of claim 17, wherein the operations further comprise: accessing, from the hardware storage devices, instructions specifying that personally identifiable information (PII) or other sensitive data is excluded from representation in data set specifications, the operations further comprising: accessing predefined field names indicative of PII or sensitive data; accessing field names of the one or more data sets stored in the hardware storage devices; and generating the schema to exclude data associated with field names corresponding to the predefined field names indicative of PII or sensitive data from accessible data. ​

Images