Systems and methods for contextual enrichment and persistence in ai agentic applications

Abstract

A system for contextual enrichment and persistence in Al agentic applications comprises an enrichment factory configured to receive raw data from disparate sources and transform it into a structured context graph. The enrichment factory comprises a micro track processor configured to identify entities within data chunks using named entity recognition and model first-order relationships between entities within a localized context window, and a macro track processor configured to perform structural analysis on data artifacts and model second-order relationships through cross-artifact correlation including detection of column similarity and value overlap. A persistence layer comprises a multi-modal storage architecture including vectorized storage, graph structure storage, and relational storage configured to store structured records of entities with pointers to corresponding vector representations and nodes. An application layer leverages the structured context graph for Al agent operations.

Description

Applicant: Anil Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTSYSTEMS AND METHODS FOR CONTEXTUAL ENRICHMENT AND PERSISTENCE IN Al AGENTIC APPLICATIONSCOPYRIGHT STATEMENT

[0001] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0002] Trademarks used in the disclosure of the invention, and the applicants, make no claim to any trademarks referenced.CROSS REFERENCE TO RELATED APPLICATIONS

[0003] This application is a Continuation-In-Part Utility Patent application claiming priority to U.S. patent application Ser. No. 19 / 466,813, filed on February 2, 2026, which in turn claims the benefit of U.S. patent application Ser. No. 19 / 459,699, filed on January 26, 2026, which in turn claims the benefit of U.S. patent application Ser. No. 19 / 457,545, filed on January 23, 2026, which in turn claims the benefit of U.S. patent application Ser. No. 19 / 454,155, filed on January 20, 2026, which in turn claims the benefit of U.S. Provisional patent Application Ser. No. 63 / 756,494, filed on February 10, 2025, which are incorporated by reference herein in their entirety.BACKGROUND OF THE INVENTION1) Field of the Invention

[0004] The invention relates in general to the field of artificial intelligence systems and multi-agent architectures, and more particularly to systems and methods for contextual enrichment and persistence that enable Al agents to process raw, disparate data intoApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTstructured, relational context graphs for enhanced reasoning and autonomous action execution.2) Description of related art

[0005] Currently the state of the art includes various multi-agent systems to automate complex workflows that were previously performed by humans or rule-based controllers.

[0006] Multi-agent collaboration and orchestration for complex workflows has enabled industries to build several automations that were previously done by Humans or Rule-based controllers. However, existing multi-agent systems often struggle with maintaining deep, persistent, and nuanced context across different steps and agents, leading to brittle workflows, redundant processing, and limited applicability in highly dynamic environments. Existing agentic systems are deployed in an out-of-the-box configuration, wherein agents operate over raw or weakly structured data without an explicit understanding of the underlying data schemas, semantic relationships, or domain-specific meaning, resulting in shallow reasoning and poor task execution.

[0007] Multi-agent collaboration and orchestration systems have enabled various industries to automate complex workflows that were previously performed by humans or rule-based controllers. These systems typically employ multiple artificial intelligence agents that work together to accomplish tasks across diverse operational environments, including manufacturing, pharmaceutical production, and industrial process control.

[0008] Existing multi-agent systems often operate over raw or weakly structured data without an explicit understanding of underlying data schemas, semantic relationships, or domain-specific meaning. When agents process information from disparate sources such as sensor readings, standard operating procedure documents, operational manuals, and equipment specifications, they frequently lack mechanisms to establish meaningful connections between related data elements. For instance, a temperature sensor reading and a corresponding safety limit specified in a separate document may be processed independently without recognition of their operational relationship.

[0009] Current approaches to context management in Al systems face challenges in maintaining deep, persistent, and nuanced context across different workflow steps andApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTagent interactions. Data collected from various sources— including sensors, documents, and operational logs— often remains fragmented, with agents relying on pre-programmed rules rather than dynamic contextual reasoning to interpret relationships between data elements. This fragmentation can result in shallow reasoning capabilities and reduced effectiveness in task execution.

[0010] The translation of raw, disparate data into cohesive and actionable context presents technical challenges. Merely collecting individual data points, such as a temperature reading or a line from a standard operating procedure, may be insufficient for robust agent operation. Establishing relationships between data elements at multiple levels— including direct relationships between entities and broader structural relationships between data artifacts— involves complex processing that existing systems may not adequately address.

[0011] Storage and retrieval mechanisms for contextual information in Al systems present additional considerations. Different types of contextual data may benefit from different storage paradigms, including vector representations for semantic similarity search, graph structures for relationship modeling, and relational databases for structured metadata management. Coordinating these different storage approaches while maintaining consistency and enabling efficient retrieval poses technical challenges.

[0012] Accordingly, there exists a general interest in systems and methods that address contextual enrichment and persistence in Al agentic applications.

[0013] These and other objects, features, and advantages of the present invention will become more readily apparent from the attached drawings and the detailed description of the preferred embodiments, which follow.SUMMARY OF THE INVENTION

[0014] Bearing in mind the problems and deficiencies of the prior art, it is therefore an object of the present invention to provide a system for contextual enrichment and persistence in Al agentic applications.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0015] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0016] The efficacy of Al agent applications is fundamentally tied to their ability to process and utilize relevant contextual information. Current systems often fail to maintain a deep, continuous, and actionable context throughout complex, multi-agent workflows. This deficiency results in suboptimal decision-making, frequent workflow breakdowns, and limited ability to handle dynamic, real-world scenarios. For Al Agents to perform actions like humans, they need to be aware of the context and take appropriate actions.

[0017] A context is defined as a dynamic, actionable body of information encompassing the operational state, resources (e.g., equipment), participants (e.g., humans requiring assistance), critical data points (e.g., measured values, optimized parameters), and any other relevant factors necessary for an Al agent to accurately understand and execute its intended operation.

[0018] The current disclosure provides a novel framework for Contextual Enrichment and Persistence, designed to provide Al agents with a robust, human-like understanding of their operational environment. By actively enriching the operational context and ensuring its persistence across multiple agent interactions over time, we enable agents to exhibit more accurate reasoning, take timely and appropriate actions, and reliably replace human intervention in complex automations.

[0019] According to an aspect of the present disclosure, a system for contextual enrichment and persistence in Al agentic applications is provided. The system includes an Enrichment Factory configured to receive raw, disparate data including sensor readings, text documents, and operational manuals, and automatically transform the data into a structured, relational context graph. The Enrichment Factory performs Micro Track Processing utilizing Named Entity Recognition to identify localized entities and employing Relationship Extraction to model first -order relationships between entities within a defined context window. The Enrichment Factory further performs Macro Track ProcessingApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTincluding structural analysis and cross-artifact correlation including foreign key detection via column similarity and value overlap to model second-order relationships between major data artifacts such as tables, figures, and document sections. The system includes a Persistence Layer comprising a multi-modal storage architecture configured to store the output of the Enrichment Factory. The multi-modal storage architecture includes a Vectorized Storage for storing data chunks as high-dimensional vector representations to enable semantic retrieval. The multi-modal storage architecture includes a Graph Structure Storage for storing the structured, relational context graph representing first-order and second-order relationships between entities to enable contextual reasoning and inferential querying. The multi-modal storage architecture includes a Relational Storage for storing structured records of identified entities, metadata, and pointers to their corresponding vector embeddings and graph nodes to enable rapid metadata lookups and transactional integrity. The system includes an Application Layer configured to leverage the enriched context graph for Al agent operations.

[0020] According to other aspects of the present disclosure, the system may include one or more of the following features. The Application Layer may include a Retrieval Orchestration Layer configured to utilize the stored Graph Structure to discover relevant entities and relationships, and to construct a virtual SQL environment for querying data chunks. The Retrieval Orchestration Layer may operate by an Anchor-Traverse-Promote pattern comprising the steps of finding initial data chunks via semantic retrieval from the Vectorized Storage during an Anchor step, exploring hidden connections between the initial chunks by executing graph queries on the Graph Structure Storage during a Traverse step, and mapping the connected chunks back to their parent logical artifacts and assembling them into structured data frames during a Promote and Reconstruct step. A final step of the Retrieval Orchestration Layer may be SQL Context Construction, which builds a virtual database payload including target tables, verified join hints from the Graph Structure, and query constraints, enabling a subsequent SQL Agent to perform context-aware joins. The Application Layer may include a Generative Actions Layer configured to integrate the enriched context graph to drive autonomous, pointed actions and real-time decision-Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTmaking by the Al agent. The Enrichment Factory's Micro Track Processing may be based on the underlying assumption that related entities and their interactions are described within close proximity or neighborhoods in the raw data, utilizing a localized context window to model high-precision, first-order relationships. The Enrichment Factory's Macro Track Processing may use Value Overlap analysis on columns of disparate data artifacts to suggest potential join relationships, thereby establishing cross-artifact correlations. The Relational Storage may act as a master index for the Persistence Layer, storing attributes for each identified entity including a pointer to its corresponding vector embedding in the Vectorized Storage and its node in the Graph Structure Storage, thereby enabling reliable entity metadata lookups and subsequent multi-modal access. The Micro Track Processing may utilize a sliding context window of seven data chunks or sentences forward and backward to facilitate the high-precision identification of direct neighborhood relationships and coreferences between entities, allowing relationships to bleed across adjacent neighborhoods through the window's overlap. The Macro Track Processing may further model second-order relationships by leveraging enhanced metadata associated with data artifacts and the principle of entity co-occurrence, formalizing connections based on semantic and structural commonalities to enrich the global contextual graph. The Generative Actions Layer may be configured to utilize the enriched context graph including established first-order and second-order relationships to perform complex, real-time inferential decisions that reliably replace the need for human intervention in complex automations, such as controlling operational parameters based on dynamic sensor data cross-referenced with standard operating procedure limits.

[0021] According to another aspect of the present disclosure, a method for enhancing contextual reasoning in Al agentic applications is provided. The method includes a Context Generation step of automatically discovering and modeling multi-level relationships from raw operational data using an Enrichment Factory. The method includes a Relationship Modeling step of establishing first-order relationships between localized entities via Micro Track Processing. The method includes a Structural Modeling step of establishing second-order relationships between major data artifacts via Macro Track Processing. The methodApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTincludes a Context Persistence step of storing the generated context graph along with vectorized data chunks and entity metadata across a multi-modal Persistence Layer. The method includes a Contextual Retrieval step of orchestrating data retrieval by utilizing the persisted context graph to guide semantic searches and construct context-aware query environments for Al agents.

[0022] According to other aspects of the present disclosure, the method may include one or more of the following features. The Contextual Retrieval step may include using the graph structure to identify and verify relationships between retrieved data chunks, ensuring the final assembled data payload is contextually cohesive.

[0023] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

[0024] Still other objects and advantages of the invention will in part be obvious and will in part be apparent from the specification.

[0025] The above and other objects, which will be apparent to those skilled in the art, are achieved in the present invention which is directed to a system for contextual enrichment and persistence in Al agentic applications, comprising:a. an enrichment factory configured to receive raw data from disparate sources and transform the raw data into a structured context graph, the enrichment factory comprising:b. a micro track processor configured to identify entities within data chunks using named entity recognition and to model first-order relationships between the entities within a localized context window; and c. a macro track processor configured to perform structural analysis on data artifacts and to model second-order relationships between the data artifacts through cross-artifact correlation including detection of column similarity and value overlap between the data artifacts;Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTd. a persistence layer comprising a multi-modal storage architecture configured to store outputs from the enrichment factory, the multi-modal storage architecture comprising:e. a vectorized storage configured to store the data chunks as vector representations to enable semantic retrieval;f. a graph structure storage configured to store the structured context graph representing the first-order relationships and the second-order relationships to enable contextual reasoning; andg. a relational storage configured to store structured records of the entities with pointers to corresponding vector representations in the vectorized storage and corresponding nodes in the graph structure storage; and h. an application layer configured to leverage the structured context graph for Al agent operations.BRIEF DESCRIPTION OF THE DRAWINGS

[0026] A further understanding of the nature and advantages of particular embodiments may be realized by reference to the remaining portions of the specification and the drawings, in which like reference numerals are used to refer to similar components. When reference is made to a reference numeral without specification to an existing sublabel, it is intended to refer to all such multiple similar components.

[0027] FIG. 1 illustrates a system architecture for a pharma-graph RAG pipeline, according to aspects of the present disclosure.

[0028] FIG. 2 illustrates a class diagram of a dynamic context construction system for contextual enrichment, according to an embodiment.

[0029] FIG. 3 illustrates a doc-type knowledge graph representing relationships between data elements, according to aspects of the present disclosure.

[0030] Corresponding reference characters indicate corresponding parts throughout the several views. The exemplifications set out herein illustrate embodiments of the inventionApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTand such exemplifications are not to be construed as limiting the scope of the invention in any manner.DETAILED DESCRIPTION

[0031] While various aspects and features of certain embodiments have been summarized above, the following detailed description illustrates a few exemplary embodiments in further detail to enable one skilled in the art to practice such embodiments. The described examples are provided for illustrative purposes and are not intended to limit the scope of the invention.

[0032] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the described embodiments. It will be apparent to one skilled in the art however that other embodiments of the present invention may be practiced without some of these specific details. Several embodiments are described herein, and while various features are ascribed to different embodiments, it should be appreciated that the features described with respect to one embodiment may be incorporated with other embodiments as well. By the same token however, no single feature or features of any described embodiment should be considered essential to every embodiment of the invention, as other embodiments of the invention may omit such features.

[0033] In this application the use of the singular includes the plural unless specifically stated otherwise and use of the terms "and" and "or" is equivalent to "and / or," also referred to as "non-exclusive or" unless otherwise indicated. Moreover, the use of the term "including," as well as other forms, such as "includes" and "included," should be considered non-exclusive. Also, terms such as "element" or "component" encompass both elements and components including one unit and elements and components that include more than one unit, unless specifically stated otherwise.

[0034] Lastly, the terms "or" and "and / or" as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, "A, B or C" or "A, B and / or CApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTmean "any of the following: A; B; C; A and B; A and C; B and C; A, B and C." An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

[0035] As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

[0036] Prior to a discussion of the preferred embodiment of the invention, it should be understood that while the features and advantages of the invention are illustrated in terms of a system for contextual enrichment and persistence in Al agentic applications the applicant realizes that the system could be used in numerous alternative applications and therefore reserves the rights to these other applications.

[0037] Context enrichment comes from data. The data is gathered from sensors, reading SOP documents, gathering operating instructions of instruments and so on. The next step is to establish first and second order relationships amongst the discovered elements. The challenge lies in translating this raw, disparate data into a cohesive and actionable context. Merely collecting data points (e.g., a temperature reading, a line from an SOP) is insufficient. The critical missing link in current systems is the structured, dynamic generation of relationships between these elements.

[0038] For instance, an Al agent must not just see:a. Temperature Sensor X reads 85°C.b. SOP Y specifies that Component Z's operating temperature limit is 80°C.

[0039] It must be able to establish the first-order relationship: Sensor X is monitoring Component Z, and the second-order relationship: The current reading (85°C) exceeds the SOP-defined limit (80°C) for Component Z, creating a critical operational context ('Overheat Alert') that requires immediate action.

[0040] Without a mechanism to automatically discover, model, and maintain these multi-level relationships, the context remains fragmented, forcing the Al agent to rely onApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTbrittle, pre-programmed rules rather than robust, contextual reasoning. This is the core problem our invention seeks to solve.

[0041] The system of the current disclosure implements a modular architecture for Contextual Enrichment and Persistence, which is universally applicable across various use cases, from enhanced retrieval (search) to autonomous, pointed actions (e.g., automated system control).

[0042] The overall framework is segmented into core, foundational layers followed by use-case-specific application layers:

[0043] Enrichment Factory (Context Generation Core): This is the initial and crucial step, serving as the engine for transforming raw, disparate data (sensor readings, SOP text, operational manuals) into structured, actionable context graphs. Its primary function is to automatically discover and model multi-level relationships (first-order and second-order) between data elements, thereby establishing a deep, cohesive operational context.

[0044] Persistence Layer (Context Storage): An appropriate layer is utilized to store the dynamically generated and relational context graphs, ensuring context persistence across time, agents, and workflow steps. This layer must support rapid, context-aware retrieval and dynamic updating of the complex relationship models.

[0045] Application Layers (Use-Case Oriented): The subsequent layers are designed to leverage the enriched context for specific application goals.a. Retrieval Orchestration Layer: In a typical implementation, this layer is plugged in to retrieve and orchestrate the enriched contexts. This mechanism significantly enhances the capability of an Al Agent to respond to user queries with high contextual accuracy and relevance.b. Generative Actions Layer: This layer is designed for driving autonomous, pointed actions. By integrating the enriched context, the Agent can perform complex, real-time decisions, such as controlling a thermostat based on the dynamic context of a chemical reaction's operating parameters and safety SOPs.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0046] This modularity allows the framework to be extended by plugging in new application layers based on evolving to the use case requirements.

[0047] A high level picture of the overall solution looks as shown in FIG. 1.

[0048] This high-level picture depicts the architecture of the Contextual Enrichment and Persistence framework, illustrating how raw data is fed into the Enrichment Factory to create a unified, actionable context graph for Al agent applications. This structure ensures context is dynamically generated, persisted, and leveraged by different application layers for both retrieval and autonomous actions.

[0049] Enrichment Factory.

[0050] There are two broad parts to the enrichment factory, one that works at Macro level identifying broader items like Tables, Figures, Sections, Paragraphs, MQTT (loT) topics etc., to name a few. The Micro level discovery establishes Entities and Relationships through NER modelling.

[0051] The Enrichment Factory operates on a dual-track system to ensure comprehensive contextual graph generation:

[0052] Micro Track Data Processing (Entity and Neighborhood Relationship Modeling)

[0053] The Micro Track focuses on deep, localized analysis to establish fine-grained relationships and entity interactions from raw data chunks (e.g., text snippets, sensor payload segments).a. Objective: Establish first-order relationships, track data intent, and model entity interactions within localized data neighborhoods.b. Context Window: A small, localized context window (e.g., 7 data chunks / sentences forward and backward) is utilized to ensure high precision in identifying direct neighborhood relationships and co-references.c. Mechanism: Following mechanisms are used in this phase for extraction, d. NER Modeling (Named Entity Recognition): Identifies and categorizes key entities (e.g., Temperature Sensor X, Component Z, 80°C Limit). e. Relationship Extraction: Utilizes Language Models (LLMs) or rule-based methods to explicitly define the relationship between identified entitiesApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTwithin the context window (e.g., Sensor X $\rightarrow$ monitors $\rightarrow$ Component Z).f. Data Intent / Description Tracking: Captures the operational meaning of the data chunk (e.g., "This chunk describes the operating safety parameters for Component Z").

[0054] Upon completion of the Micro Track, the system will have successfully identified localized entities and their immediate, first-order relationships. This is based on the underlying assumption that content, particularly within technical documents, organizes information such that related entities and their interactions are described within close proximity or "neighborhoods." The neighborhood approach along with the sliding window allows for relationships in one neighborhood to bleed into another, due to the overlap of the sliding window.

[0055] Macro Track Data Discovery (Structural and Global Relationship Modeling)

[0056] The Macro Track operates at a broader, structural level, identifying connections between major data artifacts (like tables, sections, or different MQTT topic streams) to build a global operational context.

[0057] Objective: Model second-order relationships and structural commonalities across disparate data sources and artifacts.

[0058] Artifact Focus: Tables, figures, document sections, large data streams (e.g., MQTT topics, historical logs).

[0059] Mechanism (Applied to Tabular Data):

[0060] Structural Analysis: Identifies the nature and schema of data artifacts (e.g., column headers, data types, section hierarchy).

[0061] Cross-Artifact Correlation (Foreign Key Detection): Detects potential semantic and structural linkages between tables or data streams. This is achieved by analyzing:

[0062] Column Similarity: Matching columns with high name or semantic similarity.

[0063] Value Overlap: Identifying columns where a significant percentage of values overlap, suggesting a potential join or foreign key relationship (e.g., linking aApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT'ComponentJD' column in an SOP table to a 'ComponentJD' column in a sensor reading table).

[0064] Relationship Definition: Establishes and formalizes the commonality or relationship (e.g., Table A $\rightarrow$ references parameters of $\rightarrow$ Table B).

[0065] As part of Global relationship modelling, we enhance the metadata associated with data artifacts so that it can be leveraged to establish these long-range, structural relationships. These connections are formalized based on the enhanced metadata and integrated into the query execution process.

[0066] In the context of Global relationship modeling, we also leverages the principle of entity co-occurrence to establish additional relationships. Entities frequently appearing together within the data are likely to be related, and this co-occurrence is encoded to enrich the overall contextual graph.

[0067] Data Chunks Stored in a Vectorized Form, this output comprises the raw or pre-processed data chunks (e.g., sentences from SOPs, specific sensor readings, paragraphs from manuals) where each chunk is encoded into a high-dimensional vector representation (embedding).a. Purpose: To enable semantic retrieval and similarity search. The vectorized form allows the system to efficiently find contextually relevant data chunks based on the meaning of a query, rather than just keyword matching. b. Mechanism in Context: The vectors contain the descriptive information of the entities (identified by NER in the Micro Track). This allows an agent querying for "Component Z's operating limits" to retrieve the specific sentence ("SOP Y specifies that Component Z's operating temperature limit is 80°C") even if the query uses synonyms or different phrasing. This forms the basis for highly relevant contextual grounding.

[0068] Graph Structure Representing the Relationships, this output is a comprehensive, dynamic Knowledge Graph where nodes represent the entities (both at Micro and Macro levels) and edges represent the first-order and second-order relationships discovered by theApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTEnrichment Factory. The Macro-level nodes are typically sections in a structure document and micro-level nodes are entity types found within a section.

[0069] Sections in a structured document generally represent the macro-level nodes. Conversely, micro-level nodes are typically defined by the entity types contained within those sections.a. Purpose: To model and persist the complex, multi-level relationships crucial for contextual reasoning. This graph is the materialized context itself. b. Mechanism in Context: The graph links disparate data points, such as Sensor X (Micro entity) $\rightarrow$ monitors $\rightarrow$ Component Z (Micro entity), which is structurally linked to SOP Y (Macro entity, e.g., a Document Section) $\rightarrow$ specifies limit $\rightarrow$ 80°C Limit (Micro entity). This persistent graph structure allows agents to perform complex inferential queries (e.g., "Which components are currently being monitored by a sensor mentioned in SOP Y?").

[0070] SQL Storage with All Entities, this output is a relational database containing structured records of every identified entity, along with their core metadata and links to the other storage artifacts.a. Purpose: To ensure structured persistence, transactional integrity, and rapid metadata lookups for all discovered elements.b. Mechanism in Context: This serves as the master index. Each entity (e.g., a specific sensor ID, a document ID, a component name) is stored with attributes like its data source, last update timestamp, and a pointer (ID) to its corresponding vector embedding and its node in the graph structure. This allows for reliable retrieval of entity metadata via traditional structured queries, often used as the initial step before navigating the graph or performing a vector search.

[0071] A high-level diagram illustrating the integration of the Micro and Macro Tracks is presented in FIG. 2, representing the approach to dynamic context construction of the instant invention.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0072] The instant invention provides retrieval APIs to gather contextual information. The contextual information is then used to identify and retrieve relevant data chunks, tables, and relationships. This provides the ability to retrieve the whole chunk of data along with additional contextual information for the Agent execution layer to take relevant action. The method of the instant invention incorporates retrieval APIs to collect contextual data. This contextual information is subsequently used to retrieve specific data from the existing data chunks. As a result, the Agent execution layer is now empowered to retrieve the complete data chunk, supplemented with extra contextual information, enabling it to take appropriate action.

[0073] The Context Agent orchestrates retrieval by querying the enriched Graph and Master Index to discover relevant tables, relationships and construct a virtual SQL environment for querying. It follows the Anchor-Traverse-Promote pattern, a novel approach for dynamic context generation from fragmented document data.

[0074] The Anchor (Data and Metadata Search) Analyze Query and optionally rewrite Metadata based search and filtering of data on enriched chunk metadata (descriptions, intents, entities) and finds initial chunks (e.g., yield data rows, deviation text snippets) based on query terms.

[0075] The Traverse (Micro-Plane Graph) explores hidden connections between anchors through multi-level horizon expansion. An example: discovers that a CAPA plan chunk is linked to a deviation snippet via shared entities, which references a yield table via structural JOIN.

[0076] The Promote & Reconstruct (The Stitch) maps expanded chunks back to their parent logical tables (e.g., Yield, Deviations, CAPA) using the Master Index:a. Constructs a Retrieval Plan specifying:I. Target tables with verified JOIN hintsII. Key chunks with page ranges for full-text retrievalIII. Relevant entities and column lists for query constraint generation IV. Fetches all table fragments (chunks) from storage and assembles them into coherent DataFrames or virtual table representationsApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0077] Virtual Database Constructiona. Builds a Virtual Database payload for the execution layerb. Payload includes:I. Targets: Reconstructed logical tables (e.g., Yield, Deviations, CAPA) with discovered column schemasII. Verified JOIN Hints: Graph-derived structural and functional relationships between tables (e.g., "Deviations. batch_id -> Yield. batch_id", "deviations investigate yield")III. Query Constraints: Key entities for filtering, column lists for projection, provenance metadata (source_table, source_chunk identifiers)IV. Contextual Guidance: Page ranges for document retrieval, entity definitions for grounding.V. The process ensures that localized chunksmulti-level graph traversallogical tables -> stitched DataFramesVirtual Database payload are seamlessly connected.

[0078] This enables the downstream Retrieval Agents to execute context-aware operations on the reconstructed data, producing meaningful insights such as "Show yield data for batches with deviation reports and link to relevant CAPA actions," which would be impossible from raw, fragmented document chunks alone.

[0079] The Agent Execution & Response Layer receives the Virtual Database payload and Retrieval Plan from the orchestration layer and executes context-aware operations to generate actionable insights. This layer operates on reconstructed, relationship-aware data structures rather than raw, fragmented chunks - enabling reasoning capabilities that would be impossible on unstructured documents alone.

[0080] The layer employs two complementary utility agents that consume different aspects of the Retrieval Plan:

[0081] SQL Utility Agent (Structured Data Retrieval).Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0082] The SQL Utility Agent operates on the Virtual Database payload to execute structured queries:a. Receives reconstructed logical tables (e.g., Yield, Deviations, CAPA) with discovered column schemas.b. Utilizes verified JOIN hints to connect related tables based on graph- derived relationships (e.g., "Deviations. batch_id Yield. batch_id").c. Applies entity-based filtering and column projection using query constraints from the Retrieval Plan.d. Executes SQL queries to produce structured results: aggregations, filtered datasets, cross-table analytics.

[0083] Example: For the query "Show yield data for batches with deviation reports," the utility generates and executes a JOIN between Yield and Deviations tables using the verified batch d relationship, filtering for batches present in both tables.

[0084] RAG Utility Agent (Document Context Retrieval).

[0085] The RAG Utility Agent leverages contextual guidance to retrieve and assemble relevant document passages:a. Retrieves full text for key chunks identified during the Anchor phase b. -Expands retrieval to surrounding pages using page range specifications when broader context is requiredc. Grounds retrieved text with entity definitions and metadatad. Assembles contextual passages with complete provenance information (document ID, page numbers, chunk IDs)

[0086] Example: For the query "Explain the deviation investigation procedure for temperature excursions," the utility retrieves SOP text sections describing investigation protocols, grounded with temperature limit specifications and relevant entity references.

[0087] Hybrid Execution Pattern

[0088] The key innovation lies in the combined operation of these utilities, enabled by the enriched context graph:Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTa. SQL Utility identifies specific instances and quantitative patterns (e.g., "Batch X123 failed quality checks due to temperature deviation in operation 61") b. RAG Utility provides explanatory context and procedural information (e.g., "SOP Y specifies 80°C limit for operation 61; temperature monitoring protocol outlined on page 12")c. Response synthesis combines structured results with contextual explanations, producing coherent answers that reference both data and supporting documentation

[0089] Example synthesis for "Why did Batch X123 fail quality checks?":

[0090] Batch X123 failed because operation 61 temperature reached 85°C, exceeding the SOP-specified limit of 80°C. According to the manufacturing protocol this deviation triggers automatic quality hold and requires investigation per CAPA-2024-045."

[0091] This response integrates:a. Structured data from Yield and Deviations tables (batch ID, operation number, temperature reading)b. Contextual information from SOP documents (temperature limit, protocol reference)c. Relationship traversal linking deviation to CAPA action via the enriched graph

[0092] Provenance and Auditability

[0093] Every response element maintains traceable lineage to source data:a. Structured results include source_table and source_chunk identifiers (injected during Virtual Database construction)b. Text passages include document_id, page_number, and chunk_id referencesc. This enables verification, compliance auditing, and explainability, which are extremely critical for regulated industries

[0094] The enriched context graph elevates these utility agents from simple retrieval functions to sophisticated reasoning tools capable of answering complex, multi-faceted questions that span both structured data and unstructured documentation. The sameApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTutilities, when applied to raw or weakly-structured data, would fail to establish the necessary connections between related information across different data artifacts.

[0095] The Context Storage layer is engineered to store the output of the Enrichment Factory in formats optimized for subsequent retrieval, relationship querying, and actionable insights by the Al agents. The multi-modal storage strategy is critical for supporting the framework's core functionalities: context-aware retrieval and autonomous actions.

[0096] The following description sets forth exemplary aspects of the present disclosure. It should be recognized, however, that such description is not intended as a limitation on the scope of the present disclosure. Rather, the description also encompasses combinations and modifications to those exemplary aspects described herein.

[0097] Referring to FIG. 1, a pharma-graph RAG pipeline 6100 provides a framework for contextual enrichment and persistence in Al agentic applications. The pharma-graph RAG pipeline 6100 comprises a data ingestion and enrichment factory 6102, a storage triad 6140, a retrieval orchestration 6170, and an agent execution and response 6180. The framework transforms raw, disparate data into structured, relational context graphs that enable Al agents to perform enhanced reasoning and execute complex operations.

[0098] The data ingestion and enrichment factory 6102 serves as a context generation core that receives raw documents 6105 and processes the raw documents 6105 into structured, actionable context. The raw documents 6105 include PDFs, logs, tables, and figures as different document types. A chunking and metadata extraction 6110 step processes the raw documents 6105 to extract text snippets along with metadata attributes including source, section, and timestamp information. The chunking and metadata extraction 6110 feeds processed data into two parallel processing tracks for comprehensive context generation.

[0099] A macro track 6115 handles structural processing of data artifacts. The macro track 6115 processes different types of macro artifacts including tables, figures, sections, paragraphs, and MQTT (loT) topics. The macro track 6115 comprises a logical table stitching 6120, a column profiling 6122, an LLM verification 6124, and a foreign key to edges 6126. The column profiling 6122 uses Jaccard similarity for comparing column characteristicsApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTbetween tables. The LLM verification 6124 validates potential SQL joins between tables identified through structural analysis. The macro track 6115 processing leverages an entity co-occurrence principle where entities frequently appearing together are encoded as related to enrich a contextual graph.

[0100] With continued reference to FIG. 1, a micro track 6130 handles semantic processing of data. The micro track 6130 comprises a NER and concept normalization 6132, a concept linking 6134, and concept edges 6136. The micro track 6130 utilizes a localized context window of 7 data chunks or sentences forward and backward for identifying neighborhood relationships. The concept linking 6134 establishes mentions and defines_spec relationships between entities and concepts. The micro track 6130 captures data intent and operational meaning of data chunks such as safety parameters and operational specifications. Relationship extraction in the micro track 6130 utilizes either Language Models (LLMs) or rule-based methods to define relationships between entities.

[0101] The storage triad 6140 provides multi-modal storage for persisting the generated context. The storage triad 6140 comprises a PostgreSQL data and registry 6142, an Apache AGE graph topology 6148, and a Qdrant vector index 6160 as specific technology implementations. The PostgreSQL data and registry 6142 contains logical tables 6144 and chunk storage 6146 for relational data persistence. The Apache AGE graph topology 6148 stores a logical table node 6150, a chunk node 6152, and a concept node 6154 as distinct node types. The Apache AGE graph topology 6148 includes a foreign key to edge 6156, a contains edge 6157, a mentions edge 6158, and a defines spec edge 6159 as edge types connecting the nodes. The Qdrant vector index 6160 stores dense vectors 6162, sparse vectors 6164, and enriched payloads 6166 for hybrid retrieval capabilities.

[0102] The foreign key to edges 6126 from the macro track 6115 feeds into the Apache AGE graph topology 6148. The concept edges 6136 from the micro track 6130 connect to both the Apache AGE graph topology 6148 and the Qdrant vector index 6160, enabling integration of semantic information across storage components.

[0103] The retrieval orchestration 6170 receives a user query 6172 and orchestrates context-aware retrieval operations. A RAG helper agent 6174 processes the user query 6172Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTand optionally rewrites the user query 6172 during an anchor phase to improve retrieval accuracy. The RAG helper agent 6174 performs an anchor search 6176 using the Qdrant vector index 6160, a context pruning and payload construction 6177, and a graph traversal 6178 using the Apache AGE graph topology 6148. The graph traversal 6178 explores hidden connections through multi-level horizon expansion between anchor chunks. The RAG helper agent 6174 interacts bidirectionally with both the Apache AGE graph topology 6148 and the Qdrant vector index 6160.

[0104] A retrieval plan specifies target tables with verified JOIN hints, key chunks with page ranges, relevant entities, and column lists for query constraint generation. A virtual database payload includes targets as reconstructed logical tables, verified JOIN hints from graph-derived relationships, query constraints with key entities, and contextual guidance with page ranges.

[0105] The agent execution and response 6180 receives a context payload 6190 in JSON format from the RAG helper agent 6174. The context payload 6190 contains specific chunks, concepts, and metadata for agent consumption. The agent execution and response 6180 provides two processing paths for handling different types of operations.

[0106] A SQL agent path 6182 includes a SQL agent 6186 that generates separate SQL queries 6184 with source table annotations for provenance tracking. The context payload 6190 provides specific chunks JSON 6188 to the SQL agent path 6182. The SQL agent 6186 produces aggregated SQL results 6195 from structured data operations.

[0107] A RAG agent path 6191 receives specific chunks and concepts 6192 from the context payload 6190. The RAG agent path 6191 includes a RAG agent 6194 and a verification and synthesis 6196 step. The RAG agent 6194 retrieves full text for key chunks and expands retrieval to surrounding pages using page range specifications when broader context is required. The verification and synthesis 6196 validates retrieved text before generating responses and produces a verified text response 6198.

[0108] A final application layer aggregation 6197 combines the aggregated SQL results 6195 with the verified text response 6198 to produce a final user response 6199. A hybrid execution pattern combines SQL utility for quantitative patterns with RAG utility forApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTexplanatory context to produce coherent synthesized answers. The system maintains provenance and auditability by including source_table and source_chunk identifiers in structured results and documentjd, page_number, and chunkjd references in text passages. The framework is applicable to regulated industries where compliance auditing and explainability are requirements.

[0109] Referring to FIG. 2, a dynamic context construction system 6200 illustrates the relationships and data flow between components involved in transforming raw data into structured contextual information. The dynamic context construction system 6200 begins with a raw document 6205, which includes PDFs, logs, tables, and figures. The raw document 6205 passes data to a chunk 6210, which comprises text snippets and metadata.

[0110] From the chunk 6210, data flows to three parallel processing paths. A first path leads to metadata 6215, which stores source information, section identifiers, and timestamps associated with the data chunks. A second path connects to an entity 6220, which handles named entity recognition and concept identification. A third path leads to an intent 6225, which captures operational meaning and safety parameters associated with the data.

[0111] The entity 6220 passes data to a relationship 6230, which models connections between entities including defines, mentions, and monitors relationships. Both the entity 6220 and the relationship 6230 feed into a graph builder 6240, which combines macro and micro outputs to generate a contextual graph 6270.

[0112] A macro artifact 6235 represents higher-level structural elements including tables, figures, sections, and streams. The macro artifact 6235 passes data to both a structural analysis 6245 component and the graph builder 6240. The structural analysis 6245 performs schema detection and column profiling operations, and subsequently passes data to a foreign key relation 6255, which analyzes column similarity and value overlap to identify potential relationships between data artifacts.

[0113] The graph builder 6240 outputs to two storage components. A relational store 6260 provides SQL tables, joins, foreign keys, and schema-based storage capabilities. A vector store 6250 handles embeddings, semantic search, and similarity indexing functions.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTBoth the relational store 6260 and the vector store 6250 pass data to the contextual graph 6270, which represents the final output containing nodes for entities and artifacts, and edges representing the discovered relationships between them.

[0114] Referring to FIG. 3, a doc-type knowledge graph 6300 represents global relationships generated from multiple processed input documents. The doc-type knowledge graph 6300 displays interconnections between various data elements discovered and modeled by the contextual enrichment factory.

[0115] The doc-type knowledge graph 6300 comprises several types of nodes and edges. Tables 6305 are represented as rectangular nodes distributed around the perimeter of the graph, each corresponding to logical table structures extracted from source documents. Entity types 6310 are depicted as circular nodes positioned throughout the graph, representing named entities and concepts identified during micro track processing.

[0116] The connections between nodes in the doc-type knowledge graph 6300 are represented by different edge types. A table join 6315 connects tables 6305 that share structural relationships, indicating potential join paths discovered through column similarity and value overlap analysis during macro track processing. A co-occurs-with relationship 6320 links entity types 6310 that frequently appear together within the data, encoding the principle of entity co-occurrence to enrich the overall contextual graph. A table-relates-to relationship 6325 connects tables 6305 to entity types 6310, establishing associations between structural data artifacts and the semantic concepts they contain or reference.

[0117] The framework is designed with modularity allowing new application layers to be plugged in based on evolving use case requirements. Sensor data processing enables temperature sensor readings to be cross-referenced with SOP-defined operating limits to create overheat alert contexts, demonstrating the framework's capability to establish actionable relationships between disparate data sources.

[0118] Referring to FIG. 1, the pharma-graph RAG pipeline 6100 provides a complete system architecture for processing raw data through to generating contextual responses for Al agentic applications. The pharma-graph RAG pipeline 6100 comprises four primaryApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTfunctional sections that operate in sequence to transform unstructured information into actionable context for Al agents.

[0119] The data ingestion and enrichment factory 6102 serves as the first functional section and receives the raw documents 6105 as input to the system. The raw documents 6105 include PDFs, logs, tables, and figures as different document types that enter the pipeline for processing. The chunking and metadata extraction 6110 processes the raw documents 6105 and extracts source, section, and timestamp as metadata attributes from the raw documents 6105. The data ingestion and enrichment factory 6102 then processes the extracted chunks through the macro track 6115 and the micro track 6130 in parallel to generate structured context representations.

[0120] The storage triad 6140 serves as the second functional section and receives processed data from the data ingestion and enrichment factory 6102. The storage triad 6140 persists the generated context across three complementary storage mechanisms: the PostgreSQL data and registry 6142, the Apache AGE graph topology 6148, and the Qdrant vector index 6160. The storage triad 6140 maintains the relationships and embeddings generated during the enrichment process for subsequent retrieval operations.

[0121] The retrieval orchestration 6170 serves as the third functional section and receives the user query 6172 as input. The RAG helper agent 6174 within the retrieval orchestration 6170 queries the storage triad 6140 to discover relevant entities, relationships, and data chunks based on the user query 6172. The retrieval orchestration 6170 constructs the context payload 6190 containing the retrieved information for downstream processing.

[0122] The agent execution and response 6180 serves as the fourth functional section and receives the context payload 6190 from the retrieval orchestration 6170. The agent execution and response 6180 processes the context payload 6190 through the SQL agent path 6182 and the RAG agent path 6191 to generate structured results and verified text responses. The final application layer aggregation 6197 combines outputs from both paths to produce the final user response 6199, completing the data flow through the pharmagraph RAG pipeline 6100.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0123] The chunking and metadata extraction 6110 receives the raw documents 6105 and performs segmentation of document content into discrete data chunks suitable for downstream processing. The chunking and metadata extraction 6110 parses the raw documents 6105 to identify logical boundaries within the document content, where logical boundaries include paragraph breaks, section headers, table boundaries, and figure captions. Each data chunk produced by the chunking and metadata extraction 6110 comprises a text snippet or data segment extracted from the raw documents 6105.

[0124] The chunking and metadata extraction 6110 extracts metadata attributes from the raw documents 6105 and associates the metadata attributes with each corresponding data chunk. Source metadata identifies the origin document from which a data chunk was extracted, including document identifiers, file names, and document types such as PDFs, logs, tables, or figures. Section metadata captures the hierarchical position of a data chunk within the source document structure, including section headers, subsection identifiers, and page numbers. Timestamp metadata records temporal information associated with the data chunk, including document creation dates, modification dates, and extraction timestamps.

[0125] The metadata attributes extracted by the chunking and metadata extraction 6110 enable traceability and provenance tracking throughout the pharma-graph RAG pipeline 6100. The source metadata allows downstream components to reference original documents when generating responses. The section metadata preserves document structure information that supports context reconstruction during retrieval operations. The timestamp metadata enables temporal filtering and version tracking of data chunks across multiple document ingestion cycles.

[0126] The chunking and metadata extraction 6110 outputs the extracted data chunks along with associated metadata to both the macro track 6115 and the micro track 6130 for parallel processing. The macro track 6115 receives the data chunks and metadata to perform structural analysis operations including the logical table stitching 6120, the column profiling 6122, the LLM verification 6124, and the foreign key to edges 6126. The micro track 6130 receives the same data chunks and metadata to perform semantic analysisApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCToperations including the NER and concept normalization 6132, the concept linking 6134, and the concept edges 6136.

[0127] The parallel distribution of data chunks to the macro track 6115 and the micro track 6130 enables simultaneous extraction of structural relationships and semantic relationships from the same source data. The metadata attributes accompany the data chunks through both processing tracks, ensuring that relationship information generated by each track maintains linkage to the original source documents. The chunk storage 6146 within the PostgreSQL data and registry 6142 persists the data chunks along with their associated metadata for subsequent retrieval and reference operations.

[0128] The macro track 6115 operates at a structural level to identify and model relationships between major data artifacts extracted from the raw documents 6105. The macro track 6115 processes different types of macro artifacts including tables, figures, sections, paragraphs, and MQTT (Message Queuing Telemetry Transport) topics associated with loT (Internet of Things) data streams. Each macro artifact type undergoes structural analysis to extract schema information, hierarchical organization, and potential linkages to other artifacts within the data corpus.

[0129] The logical table stitching 6120 receives data chunks containing tabular data and reconstructs logical table structures from fragmented table representations. When tables span multiple pages or are split across document sections, the logical table stitching 6120 identifies table fragments that belong to the same logical table based on column header continuity, row structure consistency, and positional metadata. The logical table stitching 6120 assembles the identified fragments into coherent logical table representations that preserve the complete tabular data structure for downstream analysis.

[0130] The column profiling 6122 analyzes the characteristics of columns within each logical table to enable cross-artifact correlation. The column profiling 6122 extracts column attributes including column names, data types, value distributions, and cardinality statistics. The column profiling 6122 utilizes Jaccard similarity for comparing column characteristics between tables, where Jaccard similarity measures the intersection over union of column attribute sets. Two columns with high Jaccard similarity scores indicate potential semanticApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTor structural correspondence between the columns, suggesting that the columns reference related data domains or serve as join candidates.

[0131] The column profiling 6122 computes Jaccard similarity by comparing the set of distinct values present in each column pair under evaluation. For two columns A and B, the Jaccard similarity equals the number of values appearing in both columns divided by the total number of distinct values appearing in either column. Columns exhibiting high value overlap through Jaccard similarity analysis are flagged as potential foreign key relationships, indicating that one table references data contained in another table.

[0132] The LLM verification 6124 receives the potential join relationships identified through the column profiling 6122 and validates the semantic correctness of the proposed joins. The LLM verification 6124 validates potential SQL joins between tables identified through structural analysis by evaluating whether the proposed column relationships represent meaningful data connections. The LLM verification 6124 analyzes column names, surrounding context from the source documents, and sample data values to determine whether a proposed join reflects an actual referential relationship rather than coincidental value overlap.

[0133] The LLM verification 6124 generates verification queries that test the proposed join relationships against the logical table data. The verification queries assess join cardinality, referential integrity, and semantic coherence of the joined results. The LLM verification 6124 filters out false positive join candidates where column value overlap occurs due to common data patterns rather than actual referential relationships. Verified join relationships proceed to the foreign key to edges 6126 for graph representation.

[0134] The foreign key to edges 6126 transforms the verified join relationships into graph edge representations suitable for storage in the Apache AGE graph topology 6148. Each verified foreign key relationship between two logical tables is encoded as a directed edge connecting the corresponding logical table node 6150 instances in the graph structure. The foreign key to edge 6156 captures the source column, target column, and join type metadata associated with each relationship.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0135] Cross-artifact correlations are established through the combination of column similarity analysis and value overlap analysis performed by the column profiling 6122.Column similarity analysis compares structural attributes of columns including naming conventions, data type specifications, and constraint definitions. Value overlap analysis examines the actual data values present in columns to identify shared value domains between tables. The intersection of high column similarity and high value overlap provides strong evidence for cross-artifact relationships that the LLM verification 6124 subsequently validates.

[0136] The macro track 6115 processes MQ.TT topics by treating each topic stream as a distinct data artifact with schema characteristics derived from the message payload structure. The macro track 6115 extracts field names, data types, and value ranges from MQ.TT message payloads to construct logical table representations of streaming data. Crossartifact correlations between MQTT topics and document-derived tables are established when field names and value domains exhibit similarity, enabling integration of real-time sensor data with static document content within the contextual graph 6270.

[0137] The micro track 6130 operates at a semantic level to identify and model finegrained relationships between entities extracted from data chunks. The micro track 6130 processes text snippets and data segments produced by the chunking and metadata extraction 6110 to discover named entities, normalize entity representations, and establish first-order relationships between co-occurring entities within localized data neighborhoods.

[0138] The NER and concept normalization 6132 receives data chunks from the chunking and metadata extraction 6110 and performs named entity recognition to identify entities within the text content. Named entity recognition identifies and categorizes entities including equipment identifiers, component names, measurement values, parameter specifications, and operational terms present in the data chunks. The NER and concept normalization 6132 normalizes identified entities to canonical forms by resolving variations in entity naming, abbreviations, and synonyms to consistent entity representations. Entity normalization ensures that references to the same real-world entity across different data chunks are mapped to a single canonical entity identifier within the contextual graph 6270.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0139] The micro track 6130 utilizes a localized context window of 7 data chunks or sentences forward and backward for identifying neighborhood relationships. The context window defines the scope of analysis for relationship extraction, where entities appearing within the same context window are evaluated for potential relationships. The localized context window approach operates on the assumption that related entities and their interactions are described within close proximity in technical documents. The 7-chunk forward and backward window creates a 15-chunk total analysis span centered on each target chunk, enabling detection of relationships between entities that appear in adjacent or nearby text segments.

[0140] The sliding context window mechanism allows relationships identified in one neighborhood to extend into adjacent neighborhoods through window overlap. As the context window advances through the document, entities near the boundary of one window appear in the subsequent window, enabling relationship continuity across neighborhood boundaries. The overlap between successive context windows ensures that entity relationships spanning multiple chunks are captured without artificial truncation at window boundaries.

[0141] The concept linking 6134 receives entities identified by the NER and concept normalization 6132 and establishes semantic relationships between the entities. The concept linking 6134 establishes mentions and defines\_spec relationships between entities and concepts. A mentions relationship indicates that a data chunk references or discusses a particular entity without providing definitional information about the entity. A defines\_spec relationship indicates that a data chunk provides specification information, parameter values, or definitional content for a particular entity.

[0142] The concept linking 6134 analyzes the linguistic context surrounding each entity occurrence to determine the relationship type. When a data chunk contains parameter values, threshold specifications, or operational limits associated with an entity, the concept linking 6134 assigns a defines\_spec relationship between the chunk and the entity. When a data chunk references an entity in a descriptive or procedural context without providing specification data, the concept linking 6134 assigns a mentions relationship. The distinctionApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTbetween mentions and defines\_spec relationships enables downstream retrieval operations to differentiate between chunks that describe entities and chunks that define entity parameters.

[0143] Relationship extraction in the micro track 6130 utilizes either Language Models or rule-based methods to define relationships between entities. Language Model-based relationship extraction employs trained models to analyze sentence structure, semantic context, and entity co-occurrence patterns to infer relationship types between entity pairs. The Language Model approach handles complex linguistic constructions, implicit relationships, and domain-specific terminology through learned representations of relationship patterns.

[0144] Rule-based relationship extraction employs predefined patterns, syntactic templates, and lexical rules to identify relationships between entities. Rule-based methods match entity pairs against relationship patterns defined through regular expressions, dependency parse structures, or keyword proximity rules. The rule-based approach provides deterministic relationship extraction with explicit pattern definitions that enable direct interpretation of extraction logic.

[0145] The selection between Language Model-based and rule-based relationship extraction depends on the characteristics of the source data and the relationship types being extracted. Language Model-based extraction provides flexibility for handling varied linguistic expressions and implicit relationships. Rule-based extraction provides consistency and interpretability for well-defined relationship patterns with predictable linguistic structures.

[0146] The concept edges 6136 transforms the relationships identified by the concept linking 6134 into graph edge representations. Each relationship between entities is encoded as a directed edge connecting the corresponding concept node 6154 instances in the Apache AGE graph topology 6148. The concept edges 6136 include relationship type labels, confidence scores from the extraction process, and source chunk identifiers for provenance tracking. The concept edges 6136 connect to both the Apache AGE graph topology 6148 forApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTgraph-based relationship storage and the Qdrant vector index 6160 for integration with vector-based retrieval operations.

[0147] The micro track 6130 captures data intent and operational meaning associated with each data chunk. Data intent describes the functional purpose of the information contained in a chunk, such as safety parameters, operational specifications, procedural instructions, or measurement data. The captured intent information is stored as metadata attributes associated with each chunk and entity, enabling intent-based filtering during retrieval operations. The intent information enriches the contextual graph 6270 by providing semantic annotations that describe the operational role of each data element within the broader document context.

[0148] The storage triad 6140 provides a multi-modal persistence architecture that stores the outputs generated by the data ingestion and enrichment factory 6102 across three complementary storage mechanisms. The storage triad 6140 comprises PostgreSQL for relational data, Apache AGE for graph topology, and Qdrant for vector indexing as specific technology implementations. Each storage mechanism within the storage triad 6140 addresses distinct data representation and retrieval requirements, enabling the pharma-graph RAG pipeline 6100 to support diverse query patterns and access methods.

[0149] The PostgreSQL data and registry 6142 provides relational database capabilities for structured data persistence within the storage triad 6140. The PostgreSQL data and registry 6142 contains the logical tables 6144 and the chunk storage 6146 as primary data structures. The logical tables 6144 store reconstructed table structures generated by the logical table stitching 6120, preserving column schemas, data types, and row data extracted from the raw documents 6105. The chunk storage 6146 persists the data chunks produced by the chunking and metadata extraction 6110 along with associated metadata attributes including source identifiers, section information, and timestamps.

[0150] The PostgreSQL data and registry 6142 serves as a master index for the storage triad 6140, maintaining structured records of every identified entity along with core metadata and links to other storage artifacts. Each entity record in the PostgreSQL data and registry 6142 includes attributes such as data source, last update timestamp, and pointerApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTidentifiers to corresponding vector embeddings in the Qdrant vector index 6160 and corresponding nodes in the Apache AGE graph topology 6148. The relational structure of the PostgreSQL data and registry 6142 enables traditional SQL queries for entity metadata lookups, which serve as initial steps before navigating the graph structure or performing vector searches.

[0151] The Apache AGE graph topology 6148 provides graph database capabilities for storing and querying the relational context graph generated by the macro track 6115 and the micro track 6130. The Apache AGE graph topology 6148 stores the logical table node 6150, the chunk node 6152, and the concept node 6154 as distinct node types representing different categories of data elements. The logical table node 6150 instances represent table structures identified during macro track processing. The chunk node 6152 instances represent individual data chunks extracted from source documents. The concept node 6154 instances represent named entities and concepts identified during micro track processing.

[0152] The Apache AGE graph topology 6148 stores multiple edge types that encode relationships between nodes. The foreign key to edge 6156 connects logical table node 6150 instances that share verified join relationships identified through the column profiling 6122 and the LLM verification 6124. The contains edge 6157 connects chunk node 6152 instances to concept node 6154 instances, indicating which concepts appear within each data chunk. The mentions edge 6158 connects nodes where one data element references another without providing definitional content. The defines spec edge 6159 connects nodes where one data element provides specification or parameter information for another element.

[0153] The graph structure stored in the Apache AGE graph topology 6148 enables complex inferential queries that traverse multiple relationship types to discover connections between disparate data elements. The Apache AGE graph topology 6148 supports the graph traversal 6178 operations performed by the RAG helper agent 6174 during retrieval orchestration. The persistent graph structure allows agents to navigate from one entity to related entities through the stored edge relationships, enabling multihop reasoning across the contextual graph.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0154] The Qdrant vector index 5160 provides vector database capabilities for semantic retrieval operations within the storage triad 6140. The Qdrant vector index 6160 stores the dense vectors 5162, the sparse vectors 6164, and the enriched payloads 6166 as primary data structures. The dense vectors 6162 comprise high-dimensional vector representations of data chunks generated through embedding models, enabling semantic similarity search based on meaning rather than keyword matching. The sparse vectors 6164 comprise termfrequency-based representations that support lexical matching and hybrid retrieval approaches.

[0155] The enriched payloads 5166 store metadata and contextual information associated with each vector entry in the Qdrant vector index 5160. The enriched payloads 6165 include entity identifiers, relationship annotations, intent classifications, and source provenance information extracted during the enrichment process. The enriched payloads 6166 enable filtered retrieval operations where vector similarity search is constrained by metadata attributes such as document source, entity type, or intent category.

[0156] The Qdrant vector index 5160 supports the anchor search 6176 performed by the RAG helper agent 6174, where initial data chunks are retrieved based on semantic similarity to the user query 6172. The vector representations in the Qdrant vector index 6160 encode descriptive information of entities identified by the NER and concept normalization 5132, enabling retrieval of contextually relevant chunks even when queries use synonyms or alternative phrasing.

[0157] The three storage components within the storage triad 6140 operate in coordination to support the retrieval and reasoning capabilities of the pharma-graph RAG pipeline 6100. The PostgreSQL data and registry 5142 provides structured access to entity metadata and chunk content. The Apache AGE graph topology 6148 provides relationship-aware navigation across the contextual graph. The Qdrant vector index 6160 provides semantic retrieval based on meaning similarity. The integration of these three storage mechanisms enables the retrieval orchestration 6170 to combine structured queries, graph traversals, and semantic searches within a unified retrieval workflow.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0158] The Apache AGE graph topology 6148 stores three distinct node types that represent different categories of data elements within the contextual graph. The logical table node 6150 represents table structures identified and reconstructed during processing by the macro track 6115. Each logical table node 6150 instance corresponds to a logical table stored in the logical tables 6144 of the PostgreSQL data and registry 6142, with node attributes capturing table name, column schema, row count, and source document provenance. The logical table node 6150 instances serve as anchor points for structural relationships between tabular data artifacts discovered through the column profiling 6122 and the LLM verification 6124.

[0159] The chunk node 6152 represents individual data chunks extracted from the raw documents 6105 by the chunking and metadata extraction 6110. Each chunk node 6152 instance corresponds to a data chunk stored in the chunk storage 6146, with node attributes including chunk identifier, text content hash, source document reference, section position, and extraction timestamp. The chunk node 6152 instances provide granular access points to document content within the graph structure, enabling traversal from high-level table structures to specific text passages containing relevant information.

[0160] The concept node 6154 represents named entities and concepts identified by the NER and concept normalization 6132 during processing by the micro track 6130. Each concept node 6154 instance corresponds to a normalized entity with attributes including canonical entity name, entity type classification, normalization confidence score, and occurrence count across the document corpus. The concept node 6154 instances encode the semantic elements extracted from document content, providing nodes that capture domain-specific terminology, equipment identifiers, parameter names, and operational concepts.

[0161] The Apache AGE graph topology 6148 stores four distinct edge types that encode relationships between the node types. The foreign key to edge 6156 connects pairs of logical table node 6150 instances that share verified join relationships. Each foreign key to edge 6156 instance includes attributes specifying the source column name, target column name, join type, and verification confidence score from the LLM verification 6124. TheApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTforeign key to edge 6156 instances enable graph traversal between related tables, supporting query operations that span multiple logical tables through their referential relationships.

[0162] The contains edge 6157 connects chunk node 6152 instances to concept node 6154 instances, indicating which concepts appear within each data chunk. Each contains edge 6157 instance includes attributes specifying the position of the concept mention within the chunk text, the mention form as it appears in the source text, and the extraction confidence score. The contains edge 6157 instances establish the linkage between document content segments and the semantic entities they contain, enabling bidirectional navigation from chunks to their contained concepts and from concepts to the chunks where they appear.

[0163] The mentions edge 6158 connects nodes where one data element references another without providing definitional or specification content. The mentions edge 6158 instances link chunk node 6152 instances to concept node 6154 instances when the chunk discusses or references the concept in a descriptive or procedural context. The mentions edge 6158 instances also connect concept node 6154 instances to other concept node 6154 instances when one concept references another within the extracted relationship structure. Each mentions edge 6158 instance includes attributes specifying the mention context, relationship direction, and extraction source.

[0164] The defines spec edge 6159 connects nodes where one data element provides specification, parameter, or definitional information for another element. The defines spec edge 6159 instances link chunk node 6152 instances to concept node 6154 instances when the chunk contains parameter values, threshold specifications, operating limits, or definitional content for the concept. Each defines spec edge 6159 instance includes attributes specifying the specification type, parameter value when applicable, and the source chunk location. The distinction between the mentions edge 6158 and the defines spec edge 6159 enables retrieval operations to differentiate between descriptive references and authoritative specification sources.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0165] The foreign key to edges 6126 from the macro track 6115 feeds directly into the Apache AGE graph topology 6148 to populate the foreign key to edge 6156 instances. The foreign key to edges 6126 receives verified join relationships from the LLM verification 6124 and transforms each relationship into a graph edge representation. The transformation process creates a foreign key to edge 6156 instance for each verified relationship, connecting the corresponding logical table node 6150 instances and populating edge attributes with column mapping and verification metadata.

[0166] The concept edges 6136 from the micro track 6130 connect to the Apache AGE graph topology 6148 to populate the contains edge 6157, the mentions edge 6158, and the defines spec edge 6159 instances. The concept edges 6136 receives relationship information from the concept linking 6134 and transforms each relationship into the appropriate edge type based on the relationship classification. The transformation process creates edge instances connecting chunk node 6152 and concept node 6154 instances according to the relationship semantics identified during micro track processing. The concept edges 6136 also connect to the Qdrant vector index 6160 to associate relationship metadata with vector entries in the enriched payloads 6166.

[0167] The Qdrant vector index 6160 provides vector database capabilities for semantic retrieval operations within the storage triad 6140. The Qdrant vector index 6160 stores the dense vectors 6162, the sparse vectors 6164, and the enriched payloads 6166 as three distinct data structures that enable hybrid retrieval capabilities.

[0168] The dense vectors 6162 comprise high-dimensional vector representations of data chunks generated through embedding models. Each data chunk processed by the chunking and metadata extraction 6110 is encoded into a dense vector representation that captures the semantic meaning of the chunk content. The dense vectors 6162 enable semantic similarity search operations where retrieval is based on meaning correspondence rather than exact keyword matching. When the RAG helper agent 6174 performs the anchor search 6176, the dense vectors 6162 support identification of data chunks that are semantically related to the user query 6172 even when the query uses different terminology or phrasing than the source documents.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0169] The sparse vectors 6164 comprise term-frequency-based representations that encode lexical information from data chunks. The sparse vectors 6164 capture word occurrence patterns, term frequencies, and vocabulary distributions present in each data chunk. The sparse vectors 6164 support lexical matching operations where retrieval is based on shared vocabulary between queries and documents. The combination of the dense vectors 6162 and the sparse vectors 6164 within the Qdrant vector index 6160 enables hybrid retrieval approaches that leverage both semantic similarity and lexical matching to identify relevant data chunks.

[0170] The enriched payloads 6166 store metadata and contextual information associated with each vector entry in the Qdrant vector index 6160. The enriched payloads 6166 include entity identifiers extracted by the NER and concept normalization 6132, relationship annotations generated by the concept linking 6134, intent classifications captured during micro track 6130 processing, and source provenance information linking each vector to its origin in the raw documents 6105. The enriched payloads 6166 enable filtered retrieval operations where vector similarity search is constrained by metadata attributes such as document source, entity type, section identifier, or intent category.

[0171] The concept edges 6136 from the micro track 6130 connect to the Qdrant vector index 6160 to associate relationship metadata with vector entries. When the concept linking 6134 identifies relationships between entities within data chunks, the concept edges 6136 transmits this relationship information to the Qdrant vector index 6160 for storage in the enriched payloads 6166. The relationship metadata stored in the enriched payloads 6166 includes relationship type classifications such as mentions and defines\_spec, entity pair identifiers involved in each relationship, and confidence scores from the relationship extraction process. This integration enables the Qdrant vector index 6160 to support retrieval operations that filter results based on relationship characteristics in addition to vector similarity scores.

[0172] The retrieval orchestration 6170 receives the user query 6172 and orchestrates context-aware retrieval operations across the storage triad 6140. The RAG helper agent 6174 processes the user query 6172 through a multi-phase retrieval workflow thatApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTcombines semantic search, graph navigation, and structured data assembly to construct comprehensive context for downstream agent operations.

[0173] The RAG helper agent 6174 performs the anchor search 6176 as an initial retrieval phase using the Qdrant vector index 6160. During the anchor search 6176, the RAG helper agent 6174 encodes the user query 6172 into a vector representation and performs similarity search against the dense vectors 6162 stored in the Qdrant vector index 6160. The anchor search 6176 identifies initial data chunks that exhibit semantic similarity to the user query 6172, establishing anchor points for subsequent graph exploration. The RAG helper agent 6174 optionally rewrites the user query 6172 during the anchor phase to improve retrieval accuracy. Query rewriting transforms the original user query 6172 into alternative formulations that better match the terminology and phrasing present in the indexed data chunks. The rewritten queries expand the retrieval scope by capturing semantic variations and domain-specific terminology that the original query formulation does not include.

[0174] The anchor search 6176 leverages the enriched payloads 6166 stored in the Qdrant vector index 6160 to filter retrieval results based on metadata attributes. The enriched payloads 6166 contain entity identifiers, relationship annotations, intent classifications, and source provenance information that enable constrained retrieval operations. The RAG helper agent 6174 applies metadata filters during the anchor search 6176 to restrict results to data chunks matching specified entity types, document sources, or intent categories relevant to the user query 6172.

[0175] The context pruning and payload construction 6177 processes the anchor chunks retrieved during the anchor search 6176 to refine the retrieval results and prepare structured payloads for downstream operations. The context pruning and payload construction 6177 evaluates each anchor chunk against relevance criteria derived from the user query 6172 and removes chunks that exhibit low relevance scores or redundant content. The pruning operation reduces the volume of retrieved content while preserving chunks that contribute distinct contextual information to the retrieval results.

[0176] The graph traversal 6178 explores the Apache AGE graph topology 6148 starting from the anchor chunks identified during the anchor search 6176. The graph traversal 6178Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTnavigates the edge relationships stored in the Apache AGE graph topology 6148 to discover additional data elements connected to the anchor chunks. The graph traversal 6178 explores hidden connections through multi-level horizon expansion between anchor chunks. Multi-level horizon expansion extends the traversal beyond immediate neighbors to include nodes reachable through multiple edge hops from each anchor chunk. The horizon expansion discovers relationships between anchor chunks that are not directly connected but share common intermediate nodes within the graph structure.

[0177] The graph traversal 6178 follows the foreign key to edge 6156 connections to discover logical table node 6150 instances related to the anchor chunks. The graph traversal 6178 follows the contains edge 6157 connections to identify concept node 6154 instances contained within the anchor chunks. The graph traversal 6178 follows the mentions edge 6158 and the defines spec edge 6159 connections to discover additional chunk node 6152 and concept node 6154 instances that reference or provide specifications for entities present in the anchor chunks. The multi-level horizon expansion enables the graph traversal 6178 to assemble a connected subgraph that captures the contextual neighborhood surrounding the anchor chunks.

[0178] The RAG helper agent 6174 constructs a retrieval plan based on the results of the anchor search 6176 and the graph traversal 6178. The retrieval plan specifies target tables with verified JOIN hints derived from the foreign key to edge 6156 relationships discovered during graph traversal. The verified JOIN hints indicate which logical table node 6150 pairs share referential relationships and specify the column mappings that enable join operations between the tables. The retrieval plan specifies key chunks with page ranges that identify the chunk node 6152 instances containing relevant content along with their positional information within source documents. The page ranges enable retrieval of surrounding document context when broader contextual information is required for response generation.

[0179] The retrieval plan specifies relevant entities extracted from the concept node 6154 instances discovered during the graph traversal 6178. The relevant entities include entity identifiers, entity type classifications, and canonical entity names that constrainApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTsubsequent query operations. The retrieval plan specifies column lists for query constraint generation that identify the specific columns within target tables relevant to the user query 6172. The column lists enable projection operations that retrieve targeted data fields rather than complete table contents.

[0180] The RAG helper agent 6174 assembles the retrieval plan into the context payload 6190 for transmission to the agent execution and response 6180. The context payload 6190 encapsulates the target tables, verified JOIN hints, key chunks, page ranges, relevant entities, and column lists in a structured format suitable for consumption by the SQL agent 6186 and the RAG agent 6194. The retrieval plan construction ensures that downstream agents receive comprehensive contextual information derived from both semantic retrieval and graph-based relationship discovery.

[0181] The agent execution and response 6180 receives the context payload 6190 in JSON format from the RAG helper agent 6174. The context payload 6190 is formatted as JSON containing specific chunks, concepts, and metadata for agent consumption. The JSON format provides a structured data representation that enables the SQL agent 6186 and the RAG agent 6194 to parse and access the contextual information assembled during the retrieval orchestration 6170.

[0182] The context payload 6190 encapsulates multiple categories of information derived from the anchor search 6176 and the graph traversal 6178. The specific chunks and concepts 6192 within the context payload 6190 include chunk identifiers, chunk text content, concept identifiers, concept names, and relationship annotations extracted from the Apache AGE graph topology 6148. The metadata within the context payload 6190 includes source document references, section positions, page numbers, extraction timestamps, and provenance information that enables traceability to the raw documents 6105.

[0183] The context payload 6190 includes a virtual database payload structure that provides comprehensive contextual information for structured query operations. The virtual database payload includes targets as reconstructed logical tables derived from the logical table node 6150 instances discovered during the graph traversal 6178. Each target logicalApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTtable within the virtual database payload includes the table name, column schema with data types, and row data assembled from the chunk storage 6146 and the logical tables 6144 stored in the PostgreSQL data and registry 6142. The reconstructed logical tables represent coherent data structures assembled from fragmented document chunks, enabling the SQL agent 6186 to execute structured queries against complete table representations.

[0184] The virtual database payload includes verified JOIN hints from graph-derived relationships stored in the Apache AGE graph topology 6148. The verified JOIN hints are derived from the foreign key to edge 6156 instances that connect logical table node 6150 pairs within the graph structure. Each verified JOIN hint specifies the source table name, source column name, target table name, target column name, and join type that enables the SQL agent 6186 to construct join operations between related tables. The verified JOIN hints encode the referential relationships validated by the LLM verification 6124 during the macro track 6115 processing, ensuring that proposed joins represent semantically correct data connections rather than coincidental value overlaps.

[0185] The virtual database payload includes query constraints with key entities extracted from the concept node 6154 instances discovered during the graph traversal 6178. The query constraints specify entity identifiers, entity type classifications, and canonical entity names that constrain the scope of query operations executed by the SQL agent 6186. The key entities within the query constraints enable filtering operations that restrict query results to rows containing references to the specified entities. The query constraints also include column lists that identify specific columns within target tables relevant to the user query 6172, enabling projection operations that retrieve targeted data fields.

[0186] The virtual database payload includes contextual guidance with page ranges that specify the positional information of key chunks within source documents. The page ranges identify the starting page number and ending page number for each chunk node 6152 instance included in the context payload 6190. The contextual guidance enables the RAG agent 6194 to retrieve surrounding document content when broader contextual information is required for response generation. The page ranges support expansion ofApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTretrieval scope beyond the specific chunks identified during the anchor search 6176 to include adjacent document sections that provide additional context for the retrieved information.

[0187] The SQL agent path 6182 within the agent execution and response 6180 processes structured data operations using the context payload 6190 received from the RAG helper agent 6174. The SQL agent path 6182 receives the specific chunks JSON 6188 from the context payload 6190, which contains the virtual database payload with reconstructed logical tables, verified JOIN hints, and query constraints assembled during the retrieval orchestration 6170.

[0188] The SQL agent 6186 within the SQL agent path 6182 generates the separate SQL queries 6184 based on the virtual database payload contained in the context payload 6190. Each query within the separate SQL queries 6184 includes source table annotations that identify the origin logical table from which data is retrieved. The source table annotations embed provenance information directly within the query structure, enabling downstream components to trace query results back to their source data artifacts within the storage triad 6140.

[0189] The SQL agent 6186 constructs the separate SQL queries 6184 by analyzing the target tables, verified JOIN hints, and query constraints specified in the virtual database payload. For each target table identified in the context payload 6190, the SQL agent 6186 generates a corresponding SQL query that retrieves relevant data fields based on the column lists specified in the query constraints. The SQL agent 6186 incorporates the verified JOIN hints to construct join operations between related tables, utilizing the source column and target column mappings derived from the foreign key to edge 6156 relationships stored in the Apache AGE graph topology 6148.

[0190] The separate SQL queries 6184 include source\_table identifiers as annotations within the query structure. The source\_table identifiers specify the name of the logical table from which each data field originates, enabling result sets to maintain explicit linkage to their source tables. When the SQL agent 6186 executes join operations across multipleApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTtables, the source\_table annotations distinguish data fields originating from different tables within the joined result set.

[0191] The separate SQL queries 6184 include source\_chunk identifiers that link query results to the specific chunk node 6152 instances from which the underlying data was extracted. The source\_chunk identifiers reference the chunk storage 6146 within the PostgreSQL data and registry 6142, enabling traceability from query results to the original data chunks produced by the chunking and metadata extraction 6110. The source\_chunk identifiers preserve the connection between structured query results and the raw documents 6105 from which the data was originally extracted.

[0192] The SQL agent 6186 executes the separate SQL queries 6184 against the reconstructed logical tables contained in the virtual database payload. The execution process retrieves data rows matching the query constraints, applies join operations based on the verified JOIN hints, and projects the specified columns from the column lists. The SQL agent 6186 aggregates the results from multiple queries into the aggregated SQL results 6195.

[0193] The aggregated SQL results 6195 comprise the combined output from all queries within the separate SQL queries 6184 executed by the SQL agent 6186. Each row within the aggregated SQL results 6195 includes the source\_table identifier indicating the logical table from which the row data originates. Each row within the aggregated SQL results 6195 includes the source\_chunk identifier linking the row data to the specific data chunk from which the information was extracted. The inclusion of source\_table and source\_chunk identifiers within the aggregated SQL results 6195 enables auditability of the structured data retrieval process.

[0194] The provenance information embedded in the aggregated SQL results 6195 supports compliance auditing and explainability requirements. The source\_table identifiers enable verification that query results originate from the expected logical tables within the storage triad 6140. The source\_chunk identifiers enable tracing of query results back to specific document sections within the raw documents 6105, supporting verification of data accuracy against original source materials. The combination of source\_table andApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTsource\_chunk identifiers provides a complete provenance chain from the aggregated SQL results 6195 through the logical tables 6144 and the chunk storage 6146 to the original raw documents 6105.

[0195] The SQL agent path 6182 transmits the aggregated SQL results 6195 to the final application layer aggregation 6197 for combination with outputs from the RAG agent path 6191. The provenance information within the aggregated SQL results 6195 persists through the aggregation process, enabling the final user response 6199 to include traceable references to source data artifacts. The source\_table and source\_chunk identifiers within the aggregated SQL results 6195 support downstream verification operations that validate the accuracy and completeness of structured data included in responses generated by the pharma-graph RAG pipeline 6100.

[0196] The RAG agent path 6191 within the agent execution and response 6180 processes document context retrieval operations using the context payload 6190 received from the RAG helper agent 6174. The RAG agent path 6191 receives the specific chunks and concepts 6192 from the context payload 6190, which contains chunk identifiers, chunk text content, concept identifiers, concept names, and relationship annotations assembled during the retrieval orchestration 6170. The specific chunks and concepts 6192 provide the RAG agent 6194 with targeted document segments and semantic entities relevant to the user query 6172.

[0197] The RAG agent 6194 within the RAG agent path 6191 retrieves full text for key chunks identified during the anchor search 6176. The RAG agent 6194 accesses the chunk storage 6146 within the PostgreSQL data and registry 6142 to obtain complete text content for each chunk node 6152 instance specified in the specific chunks and concepts 6192. The full text retrieval operation extracts the complete textual content of each key chunk, including any formatting, structural markers, and inline references present in the original data chunk.

[0198] The RAG agent 6194 expands retrieval to surrounding pages using page range specifications when broader context is required. The page range specifications within the context payload 6190 identify the starting page number and ending page number for eachApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTkey chunk, enabling the RAG agent 6194 to retrieve adjacent document sections that provide additional contextual information. The expansion operation accesses the chunk storage 6146 to retrieve data chunks that fall within the specified page ranges, assembling a broader document context that extends beyond the specific chunks identified during the anchor search 6176.

[0199] The page range expansion enables the RAG agent 6194 to capture contextual information that precedes or follows the key chunks within the source documents. When a key chunk references information described in adjacent sections, the page range expansion retrieves those adjacent sections to provide complete contextual grounding for the retrieved content. The expanded retrieval scope ensures that the RAG agent 6194 assembles sufficient document context to support accurate response generation.

[0200] The RAG agent 6194 grounds retrieved text with entity definitions and metadata extracted from the specific chunks and concepts 6192. The entity definitions include canonical entity names, entity type classifications, and relationship annotations derived from the concept node 6154 instances discovered during the graph traversal 6178. The metadata includes source document references, section positions, and extraction timestamps that enable traceability to the raw documents 6105.

[0201] The verification and synthesis 6196 step within the RAG agent path 6191 validates retrieved text before generating responses. The verification and synthesis 6196 receives the retrieved text passages from the RAG agent 6194 along with associated entity definitions and metadata. The validation process evaluates the retrieved text passages against relevance criteria derived from the user query 6172 to confirm that the assembled document context addresses the information requirements of the query.

[0202] The verification and synthesis 6196 performs consistency checking across the retrieved text passages to identify contradictions or inconsistencies within the assembled document context. The consistency checking compares entity references, parameter values, and procedural statements across different text passages to detect discrepancies that require resolution before response generation. The verification process flags passagesApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTcontaining conflicting information for further evaluation or exclusion from the response synthesis.

[0203] The verification and synthesis 6196 assembles contextual passages with complete provenance information. Each text passage within the assembled context includes document\_id references that identify the source document from which the passage was extracted. Each text passage includes page\_number references that specify the positional location of the passage within the source document. Each text passage includes chunk\_id references that link the passage to the specific chunk node 6152 instance stored in the chunk storage 6146. The provenance information enables downstream verification of the retrieved content against original source materials.

[0204] The verification and synthesis 6196 produces the verified text response 6198 as output from the RAG agent path 6191. The verified text response 6198 comprises validated text passages assembled from the retrieved document context, with each passage annotated with provenance information including document\_id, page\_number, and chunk\_id references. The verified text response 6198 includes entity definitions and relationship annotations that ground the text content within the semantic structure of the contextual graph.

[0205] The verified text response 6198 transmits to the final application layer aggregation 6197 for combination with the aggregated SQL results 6195 from the SQL agent path 6182. The provenance information within the verified text response 6198 persists through the aggregation process, enabling the final user response 6199 to include traceable references to source document passages. The document\_id, page\_number, and chunk\_id references within the verified text response 6198 support compliance auditing and explainability requirements by providing a complete provenance chain from response content to the original raw documents 6105.

[0206] The final application layer aggregation 6197 combines the aggregated SQL results 6195 with the verified text response 6198 to produce the final user response 6199. The final application layer aggregation 6197 receives structured data outputs from the SQL agent path 6182 and document context outputs from the RAG agent path 6191 as parallelApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTinput streams. The combination process merges quantitative data retrieved through SQL operations with explanatory text passages retrieved through document context operations into a unified response structure.

[0207] The final application layer aggregation 6197 implements a hybrid execution pattern that combines SQL utility for quantitative patterns with RAG utility for explanatory context to produce coherent synthesized answers. The SQL utility component within the hybrid execution pattern provides structured data including aggregations, filtered datasets, and cross-table analytics derived from the aggregated SQL results 6195. The RAG utility component within the hybrid execution pattern provides contextual explanations, procedural information, and supporting documentation derived from the verified text response 6198. The hybrid execution pattern integrates these complementary data types to generate responses that address both quantitative and qualitative aspects of the user query 6172.

[0208] The final application layer aggregation 6197 correlates data elements from the aggregated SQL results 6195 with corresponding text passages from the verified text response 6198 based on shared entity references and relationship annotations. When the aggregated SQL results 6195 contain data rows referencing specific entities, the final application layer aggregation 6197 identifies text passages within the verified text response 6198 that provide explanatory context for those entities. The correlation process utilizes the entity identifiers and relationship annotations preserved through the provenance tracking mechanisms of the pharma-graph RAG pipeline 6100.

[0209] The final user response 6199 comprises synthesized content that integrates structured results with contextual explanations. Each data element within the final user response 6199 includes references to both the source table from which the data originated and the supporting document passages that provide explanatory context. The synthesis process constructs coherent narrative responses that present quantitative findings alongside procedural explanations, parameter specifications, and regulatory references extracted from the source documents.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0210] The pharma-graph RAG pipeline 6100 is applicable to regulated industries where compliance auditing and explainability are requirements. The provenance information maintained throughout the pipeline enables verification of response content against original source materials. The source\_table and source\_chunk identifiers embedded in the aggregated SQL results 6195 provide traceable references to the logical tables 6144 and the chunk storage 6146 within the PostgreSQL data and registry 6142. The documented, page\_number, and chunk\_id references embedded in the verified text response 6198 provide traceable references to specific passages within the raw documents 6105.

[0211] The compliance auditing capabilities of the pharma-graph RAG pipeline 6100 enable regulatory reviewers to trace each element of the final user response 6199 back to its authoritative source. The explainability features of the pipeline provide transparent reasoning chains that document how the system arrived at specific conclusions or recommendations. The combination of structured data provenance and document passage provenance supports audit requirements in pharmaceutical manufacturing, clinical research, and other regulated domains.

[0212] The pharma-graph RAG pipeline 6100 supports sensor data processing that enables temperature sensor readings to be cross-referenced with SOP-defined operating limits to create overheat alert contexts. In this processing scenario, the micro track 6130 identifies a temperature sensor entity and a component entity from sensor data streams and SOP documents respectively. The NER and concept normalization 6132 extracts the sensor identifier, the component identifier, and the temperature limit value as distinct entities from the source data.

[0213] The concept linking 6134 establishes a first-order relationship indicating that the temperature sensor monitors the component. The concept linking 6134 establishes a defines spec relationship between the SOP document chunk and the temperature limit value, indicating that the SOP specifies the operating temperature limit for the component. The concept edges 6136 encodes these relationships as edge instances within the Apache AGE graph topology 6148.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0214] The macro track 6115 processes tabular sensor data and SOP specification tables to identify structural relationships between the data artifacts. The column profiling 6122 detects column similarity between sensor data tables containing component identifiers and SOP tables containing component specifications. The LLM verification 6124 validates the proposed join relationship between the sensor data table and the SOP specification table based on the shared component identifier column.

[0215] When a temperature sensor reading exceeds the SOP-defined limit, the retrieval orchestration 6170 assembles context that includes the current sensor reading, the SOP-specified limit, and the relationship between the sensor and the monitored component. The graph traversal 6178 navigates from the sensor entity through the monitors relationship to the component entity, and from the component entity through the defines\_spec relationship to the temperature limit specification. The assembled context establishes a second-order relationship indicating that the current reading exceeds the SOP-defined limit for the component, creating an overheat alert context that requires action.

[0216] The final application layer aggregation 6197 synthesizes the overheat alert context by combining the quantitative sensor reading from the aggregated SQL results 6195 with the procedural response requirements from the verified text response 6198. The final user response 6199 presents the temperature exceedance condition along with the relevant SOP reference, the specified limit value, and the recommended response actions extracted from the source documentation. The provenance information within the final user response 6199 enables verification of the alert condition against both the sensor data source and the authoritative SOP document.

[0217] Referring to FIG. 2, the dynamic context construction system 6200 is illustrated as a class diagram depicting the relationships and data flow between components involved in transforming raw data into structured contextual information for Al agentic applications. The class diagram representation of the dynamic context construction system 6200 provides a structural view of the component interactions that enable contextual enrichment within the framework.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0218] The dynamic context construction system 6200 begins with the raw document 6205, which includes PDFs, logs, tables, and figures as different document types that enter the system for processing. The raw document 6205 represents the initial input to the dynamic context construction system 6200 and encompasses the various data formats that the system processes to generate contextual information. PDFs within the raw document 6205 contain textual content, embedded tables, and figures extracted from structured documents. Logs within the raw document 6205 contain timestamped operational records and event data. Tables within the raw document 6205 contain structured data organized in row and column formats. Figures within the raw document 6205 contain graphical representations and diagrams that accompany textual content.

[0219] The raw document 6205 passes data to the chunk 6210, which comprises text snippets and metadata extracted from the source documents. The chunk 6210 serves as an intermediate processing unit that segments the content from the raw document 6205 into discrete data segments suitable for downstream analysis. Each instance of the chunk 6210 contains a text snippet representing a portion of the original document content along with metadata attributes that describe the origin and characteristics of the text snippet.

[0220] The chunk 6210 functions as a distribution point that passes information to multiple downstream components within the dynamic context construction system 6200. The distribution function of the chunk 6210 enables parallel processing paths that extract different types of information from the same source data. The chunk 6210 transmits data to the metadata 6215, the entity 6220, and the intent 6225 as three parallel processing paths that operate on the chunked content.

[0221] The metadata 6215 receives data from the chunk 6210 and stores source information, section identifiers, and timestamps associated with each data chunk. The source information within the metadata 6215 identifies the origin document from which the chunk was extracted. The section identifiers within the metadata 6215 capture the hierarchical position of the chunk within the document structure. The timestamps within the metadata 6215 record temporal information including document creation dates and extraction times.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0222] The entity 6220 receives data from the chunk 6210 and handles named entity recognition and concept identification operations. The entity 6220 processes the text snippets within each chunk to identify named entities including equipment identifiers, component names, measurement values, and operational terms. The entity 6220 normalizes identified entities to canonical forms by resolving variations in naming conventions and synonyms.

[0223] The intent 6225 receives data from the chunk 6210 and captures operational meaning and safety parameters associated with the data. The intent 6225 analyzes the content of each chunk to determine the functional purpose of the information, such as whether the chunk describes safety parameters, operational specifications, or procedural instructions. The captured intent information provides semantic annotations that describe the operational role of each data element.

[0224] The chunk 6210 distributes data to three parallel processing paths that extract distinct categories of information from the segmented document content. Each processing path operates independently on the text snippets and associated data contained within the chunk 6210, enabling concurrent extraction of metadata attributes, semantic entities, and operational intent from the same source material. The three parallel processing paths comprise the metadata 6215, the entity 6220, and the intent 6225 as distinct processing components within the dynamic context construction system 6200.

[0225] The metadata 6215 receives data from the chunk 6210 and maintains structured records of provenance and positional information for each data chunk. The source information stored within the metadata 6215 comprises document identifiers, file names, and document type classifications that identify the origin document from which each chunk was extracted. The source information enables traceability from processed chunks back to the raw document 6205 throughout subsequent processing stages within the dynamic context construction system 6200.

[0226] The section identifiers stored within the metadata 6215 capture the hierarchical position of each chunk within the document structure of the raw document 6205. The section identifiers include section headers, subsection labels, chapter numbers, and pageApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTnumbers that locate each chunk within the organizational hierarchy of the source document. The section identifiers preserve document structure information that supports context reconstruction during retrieval operations performed by downstream components.

[0227] The timestamps stored within the metadata 6215 record temporal information associated with each data chunk. The timestamps include document creation dates that indicate when the source document was originally authored. The timestamps include document modification dates that indicate when the source document was last updated. The timestamps include extraction timestamps that record when the chunk was extracted from the raw document 6205 during processing by the dynamic context construction system 6200. The temporal information enables version tracking and temporal filtering of data chunks across multiple document ingestion cycles.

[0228] The entity 6220 receives data from the chunk 6210 and performs named entity recognition operations on the text snippets contained within each chunk. The named entity recognition operations identify and categorize entities present in the text content, including equipment identifiers, component names, measurement values, parameter specifications, chemical compounds, process steps, and operational terms. Each identified entity is assigned an entity type classification that categorizes the entity according to its semantic role within the domain context.

[0229] The entity 6220 performs concept identification operations that extend beyond named entity recognition to capture abstract concepts and domain-specific terminology present in the text content. Concept identification detects references to operational procedures, quality standards, regulatory requirements, and technical specifications that represent conceptual elements rather than named entities. The identified concepts are normalized to canonical forms that resolve variations in terminology, abbreviations, and synonymous expressions to consistent concept representations.

[0230] The normalization operations performed by the entity 6220 ensure that references to the same real-world entity or concept across different data chunks are mapped to a single canonical identifier. The normalization process resolves naming variations such as abbreviated forms, alternative spellings, and synonymous terms toApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTunified entity representations. The normalized entity representations enable accurate relationship detection and consistent entity tracking across the document corpus processed by the dynamic context construction system 6200.

[0231] The intent 6225 receives data from the chunk 6210 and captures operational meaning associated with each data chunk. The operational meaning describes the functional purpose of the information contained within a chunk, characterizing whether the chunk provides procedural instructions, parameter specifications, safety guidelines, or descriptive content. The captured operational meaning provides semantic annotations that describe the role of each data element within the broader operational context of the source documentation.

[0232] The intent 6225 captures safety parameters associated with the data chunks processed by the dynamic context construction system 6200. Safety parameters include temperature limits, pressure thresholds, exposure limits, handling precautions, and emergency response procedures extracted from the text content. The safety parameter information is classified and stored as intent attributes associated with each chunk, enabling downstream retrieval operations to identify chunks containing safety-related content.

[0233] The intent 6225 captures operational specifications associated with the data chunks. Operational specifications include process parameters, equipment settings, quality criteria, acceptance limits, and performance requirements extracted from the text content. The operational specification information characterizes chunks that define how processes, equipment, or systems are configured and operated within the domain context.

[0234] The micro track 6130 captures data intent and operational meaning of data chunks such as safety parameters and operational specifications through the processing operations performed by the intent 6225. The captured intent information enriches the contextual graph 6270 by providing semantic annotations that describe the operational role of each data element. The intent classifications enable intent-based filtering during retrieval operations, allowing the retrieval orchestration 6170 to identify and retrieve chunks based on their functional purpose within the operational context.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0235] The three parallel processing paths operate concurrently on the data distributed by the chunk 6210, with each path extracting complementary information from the same source content. The metadata 6215 extracts provenance and positional information that enables traceability and document structure preservation. The entity 6220 extracts semantic entities and concepts that populate the nodes of the contextual graph 6270. The intent 6225 extracts operational meaning and safety parameters that provide semantic annotations for the extracted content. The outputs from all three processing paths are subsequently integrated by the graph builder 6240 to construct the comprehensive contextual graph 6270 that supports Al agent operations.

[0236] The entity 6220 passes data to the relationship 6230, which models connections between entities identified during the named entity recognition and concept identification operations. The relationship 6230 receives entity pairs from the entity 6220 and analyzes the contextual associations between the entities to determine the nature of their connections. The relationship 6230 classifies each entity connection according to relationship type categories that characterize the semantic nature of the association between entity pairs.

[0237] The relationship 6230 models defines relationships that indicate one entity provides definitional or specification information for another entity. A defines relationship connects an entity representing a parameter value, threshold, or specification to an entity representing the component, process, or system to which the specification applies. The defines relationship captures associations where one data element establishes the characteristics, limits, or requirements for another data element within the operational context.

[0238] The relationship 6230 models mentions relationships that indicate one entity references another entity without providing definitional content. A mentions relationship connects entities that appear together in descriptive, procedural, or narrative contexts where one entity discusses or refers to another entity. The mentions relationship captures associations where data elements are contextually related through reference or discussion rather than through specification or definition.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0239] The relationship 6230 models monitors relationships that indicate one entity observes, tracks, or measures another entity. A monitors relationship connects sensor entities, measurement devices, or monitoring systems to the components, processes, or parameters that the monitoring entity observes. The monitors relationship captures associations between data collection elements and the operational elements being monitored within the system context.

[0240] The relationship 6230 analyzes the linguistic context surrounding entity cooccurrences within the data chunks to determine the appropriate relationship type classification. The analysis examines verb phrases, prepositional constructions, and syntactic patterns that connect entity mentions within the text content. The relationship type classification assigns each entity pair to one of the defined relationship categories based on the contextual indicators present in the source text.

[0241] The relationship 6230 generates relationship instances that encode the source entity, target entity, relationship type, and extraction confidence score for each identified connection. The relationship instances represent directed associations between entity pairs, where the direction indicates the semantic flow of the relationship from source to target. The extraction confidence score quantifies the certainty of the relationship classification based on the strength of contextual indicators present in the source data.

[0242] Both the entity 6220 and the relationship 6230 feed into the graph builder 6240, which combines macro and micro outputs to generate the contextual graph 6270. The graph builder 6240 receives entity instances from the entity 6220 and relationship instances from the relationship 6230 as inputs from the micro track processing path. The graph builder 6240 transforms the entity instances into node representations and the relationship instances into edge representations within the graph structure.

[0243] The graph builder 6240 creates nodes for each unique entity identified by the entity 6220, with node attributes capturing the canonical entity name, entity type classification, normalization confidence score, and source chunk references. The graph builder 6240 creates edges for each relationship instance generated by the relationship 6230, with edge attributes capturing the relationship type, extraction confidence score, andApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTsource chunk references. The node and edge representations encode the semantic structure extracted during micro track processing.

[0244] The macro artifact 6235 represents higher-level structural elements including tables, figures, sections, and streams extracted from the raw document 6205. Tables within the macro artifact 6235 comprise structured data organized in row and column formats with defined schemas and data types. Figures within the macro artifact 6235 comprise graphical representations, diagrams, and visual elements that accompany textual content. Sections within the macro artifact 6235 comprise hierarchical document divisions including chapters, subsections, and labeled content blocks. Streams within the macro artifact 6235 comprise continuous data flows such as MQTT topics and sensor data channels that provide real-time operational information.

[0245] The macro artifact 6235 passes data to the structural analysis 6245, which performs schema detection and column profiling operations on the structural elements. The structural analysis 6245 examines tables within the macro artifact 6235 to extract column headers, data types, value distributions, and cardinality statistics. The structural analysis 6245 examines sections within the macro artifact 6235 to identify hierarchical relationships, section boundaries, and organizational patterns. The structural analysis 6245 examines streams within the macro artifact 6235 to extract field names, data types, and value ranges from message payload structures.

[0246] The structural analysis 6245 passes data to the foreign key relation 6255, which analyzes column similarity and value overlap to identify potential relationships between data artifacts. The foreign key relation 6255 compares column characteristics across different tables within the macro artifact 6235 to detect columns that reference related data domains. The foreign key relation 6255 identifies potential join relationships based on high column similarity scores and significant value overlap between column pairs.

[0247] The macro artifact 6235 passes data to the graph builder 6240 in addition to passing data to the structural analysis 6245. The graph builder 6240 receives structural element representations from the macro artifact 6235 and creates corresponding nodes within the graph structure. The graph builder 6240 creates nodes for each table, figure,Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTsection, and stream identified within the macro artifact 6235, with node attributes capturing the artifact type, schema information, and source document references.

[0248] The graph builder 6240 combines macro and micro outputs to generate the contextual graph 6270 as a unified representation of both structural and semantic relationships. The combination process integrates entity nodes and relationship edges from the micro track processing with artifact nodes and structural edges from the macro track processing. The graph builder 6240 establishes cross-level connections between micro-level entity nodes and macro-level artifact nodes based on containment relationships and reference associations.

[0249] The graph builder 6240 creates containment edges that connect macro-level artifact nodes to the micro-level entity nodes contained within those artifacts. When an entity identified by the entity 6220 appears within a section, table, or stream represented by the macro artifact 6235, the graph builder 6240 creates an edge connecting the artifact node to the entity node. The containment edges establish the hierarchical relationship between structural elements and the semantic entities they contain.

[0250] The graph builder 6240 creates reference edges that connect entity nodes to artifact nodes when entities reference or relate to structural elements. When a relationship instance from the relationship 6230 indicates that an entity references a table, section, or specification document, the graph builder 6240 creates an edge connecting the entity node to the corresponding artifact node. The reference edges establish associations between semantic entities and the structural artifacts they reference within the document corpus.

[0251] The graph builder 6240 outputs to the relational store 6260 and the vector store 6250 as two storage components that persist the generated graph structure. The relational store 6260 receives node and edge data from the graph builder 6240 and stores the information in SQL tables with defined schemas for nodes, edges, and associated attributes. The vector store 6250 receives embedding representations of nodes and edges from the graph builder 6240 and stores the vectors along with associated metadata for semantic retrieval operations.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0252] Both the relational store 6260 and the vector store 6250 pass data to the contextual graph 6270, which represents the final output containing nodes for entities and artifacts, and edges representing the discovered relationships between them. The contextual graph 6270 integrates the structural relationships identified through macro track processing with the semantic relationships identified through micro track processing into a unified graph representation. The contextual graph 6270 provides the foundation for context-aware retrieval and reasoning operations performed by downstream components within the framework.

[0253] The structural analysis 6245 receives data from the macro artifact 6235 and performs schema detection operations on tabular data structures extracted from the raw document 6205. Schema detection examines each table within the macro artifact 6235 to identify column headers, column data types, column constraints, and table organization patterns. The schema detection operations extract the structural definition of each table, capturing the names assigned to each column, the data type classification for values stored in each column, and any constraint specifications such as uniqueness requirements or null value permissions.

[0254] The structural analysis 6245 performs column profiling operations that analyze the characteristics of individual columns within each detected table schema. Column profiling extracts statistical attributes from column data including value distributions, cardinality counts, minimum and maximum values, and frequency distributions for categorical data. The column profiling operations compute summary statistics that characterize the data content of each column, enabling subsequent comparison operations to assess similarity between columns across different tables.

[0255] The structural analysis 6245 generates column profile records that capture the extracted attributes for each column within the analyzed tables. Each column profile record includes the column name, the inferred data type, the cardinality indicating the number of distinct values present in the column, and the value distribution statistics computed during profiling. The column profile records provide the input data for cross-table comparison operations performed by the foreign key relation 6255.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0256] The structural analysis 6245 passes the column profile records to the foreign key relation 6255 for cross-artifact relationship detection. The foreign key relation 6255 receives column profiles from multiple tables and performs pairwise comparison operations to identify columns that exhibit similarity characteristics indicative of referential relationships. The comparison operations evaluate both structural similarity based on column attributes and value-based similarity based on the actual data content present in the columns.

[0257] The foreign key relation 6255 analyzes column similarity by comparing the structural attributes of column pairs across different tables. Column similarity analysis examines column name correspondence, where columns with matching or semantically similar names indicate potential relationships between the tables containing those columns. Column similarity analysis examines data type correspondence, where columns with compatible data types are candidates for referential relationships. Column similarity analysis examines constraint correspondence, where columns with similar uniqueness or cardinality characteristics suggest potential primary key to foreign key associations.

[0258] The foreign key relation 6255 analyzes value overlap by comparing the actual data values present in column pairs across different tables. Value overlap analysis computes the intersection of distinct values between two columns and calculates the proportion of values that appear in both columns. A high value overlap percentage indicates that one column contains values that reference or correspond to values in another column, suggesting a foreign key relationship where one table references data contained in another table.

[0259] The foreign key relation 6255 computes value overlap metrics using set intersection operations on the distinct value sets extracted from each column pair under evaluation. For two columns being compared, the value overlap calculation determines the number of values appearing in both columns divided by the total number of distinct values appearing in either column. Columns exhibiting value overlap above a threshold percentage are flagged as candidate foreign key relationships for further validation.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0260] The foreign key relation 6255 generates candidate relationship records that capture the identified potential foreign key associations between tables. Each candidate relationship record specifies the source table name, the source column name, the target table name, the target column name, the column similarity score, and the value overlap percentage computed during the analysis. The candidate relationship records represent potential structural connections between tables that require validation before integration into the contextual graph 6270.

[0261] The candidate relationship records generated by the foreign key relation 6255 proceed to the LLM verification 6124 within the macro track 6115 for semantic validation. The LLM verification 6124 evaluates whether each candidate relationship represents a meaningful data connection rather than coincidental similarity or value overlap. The validation process filters out false positive candidates where column similarity or value overlap occurs due to common data patterns rather than actual referential relationships between the tables.

[0262] The graph builder 6240 receives validated foreign key relationships from the macro track 6115 processing and integrates these structural relationships with the semantic relationships identified through micro track processing. The integration process creates a unified graph structure within the contextual graph 6270 that represents both the structural connections between tables and the semantic connections between entities. The graph builder 6240 creates logical table nodes for each table identified during macro track processing and creates foreign key edges connecting table pairs with validated referential relationships.

[0263] The graph builder 6240 establishes cross-level connections between macro-level table nodes and micro-level entity nodes based on containment and reference associations. When entities identified by the entity 6220 appear within table cells or table headers, the graph builder 6240 creates edges connecting the table node to the corresponding entity nodes. The cross-level connections enable graph traversal operations that navigate from structural table relationships to the semantic entities contained within those tables.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0264] The graph builder 6240 correlates foreign key relationships with entity relationships to identify consistent patterns across structural and semantic levels. When a foreign key relationship connects two tables based on a shared column, and entities extracted from those tables exhibit relationship instances identified by the relationship 6230, the graph builder 6240 reinforces the connection strength between the corresponding nodes. The correlation between structural and semantic relationships provides validation that the identified connections represent meaningful associations within the data corpus.

[0265] The integration of macro-level structural relationships with micro-level entity relationships within the graph builder 6240 produces a multi-layered contextual graph 6270 that supports both structural navigation and semantic reasoning. The structural layer of the contextual graph 6270 enables traversal between tables based on foreign key associations, supporting query operations that span multiple related tables. The semantic layer of the contextual graph 6270 enables traversal between entities based on defines, mentions, and monitors relationships, supporting reasoning operations that follow conceptual associations between domain elements.

[0266] The graph builder 6240 outputs the integrated graph structure to the relational store 6260 and the vector store 6250 for persistence. The relational store 6260 stores the node and edge data in SQL tables that preserve the structural relationships identified through foreign key detection along with the semantic relationships identified through entity relationship extraction. The vector store 6250 stores embedding representations of nodes that enable semantic similarity search across both structural and semantic elements of the contextual graph 6270.

[0267] The graph builder 6240 outputs processed data to the relational store 6260, which provides SQL tables, joins, foreign keys, and schema-based storage capabilities for persisting the generated graph structure. The relational store 6260 receives node data and edge data from the graph builder 6240 and organizes this information into structured database tables with defined schemas that support relational query operations. The SQL tables within the relational store 6260 include node tables that store entity records, artifactApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTrecords, and associated attributes, along with edge tables that store relationship records connecting node pairs.

[0268] The relational store 6260 implements join capabilities that enable query operations spanning multiple related tables within the storage structure. The join capabilities leverage the foreign key relationships identified during macro track processing and validated by the LLM verification 6124. Each foreign key relationship stored in the relational store 6260 specifies the source table, source column, target table, and target column that define the referential connection between related data structures. The join capabilities enable reconstruction of complex data relationships through SQL query operations that traverse the stored foreign key associations.

[0269] The relational store 6260 maintains foreign key constraints that enforce referential integrity between related tables within the storage structure. The foreign key constraints ensure that relationship references stored in edge tables correspond to valid node entries in the associated node tables. The foreign key constraints prevent orphaned relationship records and maintain consistency between the structural and semantic elements of the stored graph data.

[0270] The schema-based storage capabilities of the relational store 6260 provide structured organization for the diverse data types generated by the graph builder 6240. The schema definitions specify column names, data types, constraint specifications, and index configurations for each table within the relational store 6260. The schema-based organization enables efficient query execution through index utilization and query optimization based on the defined table structures. The schema definitions capture the structural characteristics of nodes and edges, including entity type classifications, relationship type labels, confidence scores, and provenance metadata.

[0271] The vector store 6250 handles embeddings that encode semantic representations of nodes and data chunks generated during the enrichment process. The graph builder 6240 outputs embedding vectors to the vector store 6250, where each embedding vector captures the semantic meaning of a corresponding node or data chunk in a high-dimensional vector space. The embedding vectors enable semantic comparisonApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCToperations that assess meaning similarity between data elements based on vector distance calculations rather than exact string matching.

[0272] The vector store 6250 provides semantic search capabilities that retrieve data elements based on meaning correspondence with query inputs. Semantic search operations encode query inputs into vector representations and identify stored vectors that exhibit proximity to the query vector within the embedding space. The semantic search capabilities enable retrieval of contextually relevant data elements even when queries use different terminology or phrasing than the stored content. The semantic search operations return ranked results based on vector similarity scores that quantify the degree of semantic correspondence between query inputs and stored data elements.

[0273] The vector store 6250 implements similarity indexing functions that organize stored vectors for efficient nearest-neighbor retrieval operations. The similarity indexing functions construct index structures that partition the vector space and enable rapid identification of vectors proximate to query vectors without exhaustive comparison against all stored vectors. The index structures support approximate nearest-neighbor search algorithms that balance retrieval accuracy against computational efficiency for large-scale vector collections.

[0274] The similarity indexing functions within the vector store 6250 support both dense vector indexing and sparse vector indexing to enable hybrid retrieval approaches. Dense vector indices organize the high-dimensional embedding vectors generated through neural encoding models. Sparse vector indices organize term-frequency-based representations that capture lexical information from data chunks. The combination of dense and sparse indexing enables retrieval operations that leverage both semantic similarity and lexical matching to identify relevant data elements.

[0275] The relational store 6260 passes data to the contextual graph 6270 by providing structured access to node records and edge records stored in the SQL tables. The contextual graph 6270 receives node data from the relational store 6260 that populates the graph with entity nodes and artifact nodes representing the semantic and structural elements extracted during enrichment processing. The contextual graph 6270 receives edge dataApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTfrom the relational store 5260 that establishes connections between nodes based on the relationship instances identified by the relationship 6230 and the foreign key associations detected by the foreign key relation 6255.

[0276] The vector store 6250 passes data to the contextual graph 6270 by providing semantic representations that enrich the node and edge elements within the graph structure. The contextual graph 6270 receives embedding vectors from the vector store 6250 that associate each node with a corresponding semantic representation in the vector space. The embedding associations enable the contextual graph 6270 to support both graph-based traversal operations and semantic similarity operations on the same underlying data elements.

[0277] The contextual graph 6270 contains nodes for entities and artifacts that represent the semantic and structural elements extracted from the raw document 6205 during processing by the dynamic context construction system 6200. Entity nodes within the contextual graph 6270 correspond to named entities and concepts identified by the entity 6220, with node attributes capturing canonical entity names, entity type classifications, normalization confidence scores, and source chunk references. Artifact nodes within the contextual graph 6270 correspond to structural elements identified within the macro artifact 6235, with node attributes capturing artifact types, schema information, and source document references.

[0278] The contextual graph 6270 contains edges representing discovered relationships between the entity nodes and artifact nodes. Relationship edges within the contextual graph 6270 encode the defines, mentions, and monitors associations identified by the relationship 6230 during micro track processing. Structural edges within the contextual graph 6270 encode the foreign key associations identified by the foreign key relation 6255 during macro track processing. Containment edges within the contextual graph 6270 connect artifact nodes to the entity nodes contained within those artifacts, establishing hierarchical associations between structural elements and their semantic contents.

[0279] The edges within the contextual graph 6270 include edge attributes that capture relationship metadata including relationship type labels, extraction confidence scores, andApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTsource provenance information. The relationship type labels classify each edge according to the semantic nature of the connection between the source and target nodes. The extraction confidence scores quantify the certainty of the relationship identification based on the strength of contextual indicators present in the source data. The source provenance information links each edge to the specific data chunks from which the relationship was extracted, enabling traceability from graph relationships back to the raw document 6205.

[0280] The contextual graph 6270 integrates the outputs from both the relational store 6260 and the vector store 6250 into a unified representation that supports multiple access patterns. Graph traversal operations navigate the contextual graph 6270 by following edge connections between nodes to discover related data elements. Semantic retrieval operations access the contextual graph 6270 through the embedding associations provided by the vector store 6250 to identify nodes based on meaning similarity. Structured query operations access the contextual graph 6270 through the relational tables provided by the relational store 6260 to retrieve nodes and edges based on attribute filtering and join conditions.

[0281] The contextual graph 6270 provides the foundation for context-aware retrieval and reasoning operations performed by downstream components within the framework. The retrieval orchestration 6170 queries the contextual graph 6270 to discover relevant entities, relationships, and data chunks based on the user query 6172. The graph traversal 6178 navigates the edge connections within the contextual graph 6270 to explore hidden connections between anchor chunks identified during the anchor search 6176. The agent execution and response 6180 utilizes the contextual graph 6270 to assemble comprehensive context for generating the final user response 6199.

[0282] Referring to FIG. 3, the doc-type knowledge graph 6300 represents global relationships generated from multiple processed input documents. The doc-type knowledge graph 6300 displays interconnections between various data elements discovered and modeled by the data ingestion and enrichment factory 6102 during processing of the raw documents 6105. The doc-type knowledge graph 6300 provides a visual representation ofApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTthe multi-level relationships established through the macro track 6115 and the micro track 6130 processing operations.

[0283] The tables 6305 are represented as rectangular nodes distributed around the perimeter of the doc-type knowledge graph 6300. Each instance of the tables 6305 corresponds to a logical table structure extracted from the source documents during processing by the logical table stitching 6120 within the macro track 6115. The rectangular node representation of the tables 6305 distinguishes structural data artifacts from semantic entities within the graph visualization. Each rectangular node representing the tables 6305 corresponds to a logical table node 6150 stored within the Apache AGE graph topology 6148, with node attributes capturing table name, column schema, and source document provenance.

[0284] The entity types 6310 are depicted as circular nodes positioned throughout the doc-type knowledge graph 6300. The entity types 6310 represent named entities and concepts identified during processing by the micro track 6130. Each instance of the entity types 6310 corresponds to a concept node 6154 stored within the Apache AGE graph topology 6148. The circular node representation of the entity types 6310 distinguishes semantic entities from structural table artifacts within the graph visualization. The entity types 6310 include equipment identifiers, component names, measurement values, parameter specifications, and operational terms extracted by the NER and concept normalization 6132.

[0285] The doc-type knowledge graph 6300 shows the tables 6305 connected via the table join 6315 edges. Each instance of the table join 6315 connects pairs of the tables 6305 that share structural relationships identified through the column profiling 6122 and validated by the LLM verification 6124. The table join 6315 edges indicate potential join paths discovered through column similarity and value overlap analysis during the macro track 6115 processing. The table join 6315 edges correspond to the foreign key to edge 6156 instances stored within the Apache AGE graph topology 6148, enabling graph traversal operations that navigate between related table structures.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0286] The doc-type knowledge graph 6300 shows the entity types 6310 connected via the co-occurs-with relationship 6320 edges. Each instance of the co-occurs-with relationship 6320 links pairs of the entity types 6310 that frequently appear together within the data chunks processed by the micro track 6130. The co-occurs-with relationship 6320 edges encode the principle of entity co-occurrence, where entities appearing together within localized context windows are identified as contextually related. The co-occurs-with relationship 6320 edges enrich the overall contextual graph 6270 by capturing semantic associations between concepts that do not have explicit structural connections but are contextually related based on their proximity in the source documents.

[0287] The doc-type knowledge graph 6300 shows the tables 6305 connected to the entity types 6310 via the table-relates-to relationship 6325 edges. Each instance of the table-relates-to relationship 6325 establishes associations between structural data artifacts represented by the tables 6305 and the semantic concepts represented by the entity types 6310. The table-relates-to relationship 6325 edges connect table nodes to entity nodes when the tables contain or reference the corresponding entities. The table-relates-to relationship 6325 edges facilitate integration of macro-level structural information with micro-level entity relationships within the doc-type knowledge graph 6300.

[0288] The combination of the table join 6315, the co-occurs-with relationship 6320, and the table-relates-to relationship 6325 within the doc-type knowledge graph 6300 demonstrates the multi-level relationship modeling performed by the data ingestion and enrichment factory 6102. The table join 6315 edges capture structural relationships between tabular data artifacts at the macro level. The co-occurs-with relationship 6320 edges capture semantic associations between entities at the micro level. The table-relates-to relationship 6325 edges bridge the macro and micro levels by connecting structural artifacts to their contained semantic entities. The doc-type knowledge graph 6300 enables the graph traversal 6178 operations performed by the RAG helper agent 6174 to navigate across both structural and semantic relationship types when discovering relevant context for the user query 6172.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0289] The table join 6315 edges within the doc-type knowledge graph 6300 connect pairs of the tables 6305 that share structural relationships identified during the macro track 6115 processing. Each instance of the table join 6315 represents a verified referential connection between two logical table structures extracted from the raw documents 6105. The table join 6315 edges indicate potential join paths that enable query operations to span multiple related tables through their shared column associations. The structural relationships encoded by the table join 6315 edges are discovered through the column profiling 6122 and validated by the LLM verification 6124 before integration into the doctype knowledge graph 6300.

[0290] The column profiling 6122 analyzes column characteristics across different instances of the tables 6305 to detect columns that reference related data domains. The column profiling 6122 computes Jaccard similarity scores by comparing the set of distinct values present in each column pair under evaluation. Columns exhibiting high Jaccard similarity scores indicate potential semantic or structural correspondence between the columns, suggesting that the columns reference related data domains or serve as join candidates. The value overlap analysis performed by the column profiling 6122 examines the actual data values present in columns to identify shared value domains between tables.

[0291] The table join 6315 edges encode the source table name, source column name, target table name, target column name, and join type metadata for each verified relationship. The join type metadata specifies whether the relationship represents a one-to-one, one-to-many, or many-to-many association between the connected tables. The table join 6315 edges enable the graph traversal 6178 operations performed by the RAG helper agent 6174 to navigate between related table structures when assembling context for the user query 6172. The structural relationships captured by the table join 6315 edges support query operations that require data from multiple related tables to be combined through join operations.

[0292] The co-occurs-with relationship 6320 edges within the doc-type knowledge graph 6300 link pairs of the entity types 6310 that frequently appear together within the data chunks processed by the micro track 6130. Each instance of the co-occurs-withApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTrelationship 6320 represents a semantic association between two entities based on their proximity within the source documents. The co-occurs-with relationship 6320 edges encode the principle of entity co-occurrence, where entities appearing together within localized context windows are identified as contextually related. The macro track 6115 processing leverages the entity co-occurrence principle where entities frequently appearing together are encoded as related to enrich the contextual graph 6270.

[0293] The co-occurs-with relationship 6320 edges capture semantic associations between the entity types 6310 that do not have explicit structural connections but are contextually related based on their proximity in the source documents. When two entities appear within the same context window during the micro track 6130 processing, the cooccurrence is recorded and encoded as an edge connecting the corresponding concept node 6154 instances within the Apache AGE graph topology 6148. The frequency of cooccurrence across multiple data chunks strengthens the association weight assigned to each co-occurs-with relationship 6320 edge.

[0294] The co-occurs-with relationship 6320 edges enrich the overall contextual graph 6270 by establishing connections between entities that share contextual relevance without explicit definitional or referential relationships. The enrichment provided by the co-occurs-with relationship 6320 edges enables the graph traversal 6178 to discover related entities based on contextual proximity patterns observed in the source documents. The cooccurrence associations support reasoning operations that identify entities likely to be relevant when one entity in a co-occurring pair is referenced in the user query 6172.

[0295] The table-relates-to relationship 6325 edges within the doc-type knowledge graph 6300 connect instances of the tables 6305 to instances of the entity types 6310. Each instance of the table-relates-to relationship 6325 establishes an association between a structural data artifact represented by a table node and a semantic concept represented by an entity node. The table-relates-to relationship 6325 edges bridge the macro-level structural information captured by the tables 6305 with the micro-level semantic information captured by the entity types 6310.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0296] The table-relates-to relationship 6325 edges are created when the tables 6305 contain or reference the corresponding entity types 6310 within their data content. When an entity identified by the NER and concept normalization 6132 appears within a table cell, table header, or table caption, the table-relates-to relationship 6325 edge connects the table node to the entity node. The table-relates-to relationship 6325 edges also connect table nodes to entity nodes when the table data references entities defined or described elsewhere in the document corpus.

[0297] The table-relates-to relationship 6325 edges facilitate integration of macro-level structural information with micro-level entity relationships within the doc-type knowledge graph 6300. The integration enables the graph traversal 6178 to navigate from structural table artifacts to the semantic entities they contain, and from semantic entities to the tables that reference those entities. The bidirectional navigation supported by the table-relates-to relationship 6325 edges enables comprehensive context assembly that spans both structural and semantic dimensions of the source data.

[0298] The combination of the table join 6315 edges, the co-occurs-with relationship 6320 edges, and the table-relates-to relationship 6325 edges within the doc-type knowledge graph 6300 provides a multi-level relationship structure that supports complex inferential queries. The table join 6315 edges enable navigation between related tables based on structural column associations. The co-occurs-with relationship 6320 edges enable navigation between related entities based on contextual proximity patterns. The table-relates-to relationship 6325 edges enable navigation between tables and entities based on containment and reference associations. The three edge types operate together to support the retrieval orchestration 6170 in discovering relevant context across both structural and semantic relationship dimensions.

[0299] The system can further be described as a system for contextual enrichment and persistence in Al agentic applications, comprising:a. an enrichment factory configured to receive raw data from disparate sources and transform the raw data into a structured context graph, the enrichment factory comprising:Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTb. a micro track processor configured to identify entities within data chunks using named entity recognition and to model first-order relationships between the entities within a localized context window; andc. a macro track processor configured to perform structural analysis on data artifacts and to model second-order relationships between the data artifacts through cross-artifact correlation including detection of column similarity and value overlap between the data artifacts;d. a persistence layer comprising a multi-modal storage architecture configured to store outputs from the enrichment factory, the multi-modal storage architecture comprising:e. a vectorized storage configured to store the data chunks as vector representations to enable semantic retrieval;f. a graph structure storage configured to store the structured context graph representing the first-order relationships and the second-order relationships to enable contextual reasoning; andg. a relational storage configured to store structured records of the entities with pointers to corresponding vector representations in the vectorized storage and corresponding nodes in the graph structure storage; andh. an application layer configured to leverage the structured context graph for Al agent operations.

[0300] The system of the current disclosure, wherein the application layer comprises a retrieval orchestration layer configured to utilize the graph structure storage to discover relevant entities and relationships and to construct a virtual database payload for querying the data chunks.

[0301] The system of the current disclosure, wherein the retrieval orchestration layer operates according to an anchor-traverse-prom ote pattern comprising:a. finding initial data chunks via semantic retrieval from the vectorized storage during an anchor step;Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTb. exploring connections between the initial data chunks by executing graph queries on the graph structure storage during a traverse step; and c. mapping connected data chunks back to parent logical artifacts and assembling the connected data chunks into structured data frames during a promote step.

[0302] The system of the current disclosure, wherein the retrieval orchestration layer constructs the virtual database payload comprising target tables, verified join hints derived from the graph structure storage, and query constraints enabling a SQL agent to perform context-aware join operations.

[0303] The system of the current disclosure, wherein the application layer comprises a generative actions layer configured to integrate the structured context graph to drive autonomous actions and real-time decision-making by an Al agent.

[0304] The system of the current disclosure, wherein the micro track processor utilizes a sliding context window comprising a defined number of data chunks forward and backward to identify neighborhood relationships between the entities, wherein the sliding context window allows relationships to extend across adjacent neighborhoods through window overlap.

[0305] The system of the current disclosure, wherein the macro track processor detects the column similarity using Jaccard similarity by comparing sets of distinct values present in column pairs across different data artifacts.

[0306] The system of the current disclosure, wherein the relational storage acts as a master index for the persistence layer, storing attributes for each entity including a pointer to a corresponding vector representation in the vectorized storage and a pointer to a corresponding node in the graph structure storage.

[0307] The system of the current disclosure, wherein the macro track processor further models the second-order relationships by leveraging entity co-occurrence, wherein entities frequently appearing together within the data chunks are encoded as related within the structured context graph.

[0308] The system of the current disclosure, wherein the graph structure storage stores:Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTa. logical table nodes representing table structures identified during macro track processing;b. chunk nodes representing individual data chunks extracted from source documents; andc. concept nodes representing the entities identified during micro track processing.

[0309] The system of the current disclosure, wherein the graph structure storage stores edge types comprising:a. foreign key edges connecting pairs of the logical table nodes that share verified join relationships;b. contains edges connecting the chunk nodes to the concept nodes indicating which concepts appear within each data chunk; andc. defines specification edges connecting nodes where one data element provides specification information for another data element.

[0310] The system can further be described as a method for enhancing contextual reasoning in Al agentic applications, comprising:a. receiving raw data from disparate sources including documents and data streams;b. processing the raw data through a micro track to identify entities within data chunks and to establish first-order relationships between the entities within a localized context window;c. processing the raw data through a macro track to identify structural relationships between data artifacts through column similarity analysis and value overlap analysis;d. generating a structured context graph that integrates the first-order relationships from the micro track and the structural relationships from the macro track; e. storing the structured context graph in a graph structure storage, storing the data chunks as vector representations in a vectorized storage, and storing entityApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTrecords with pointers to the vector representations and graph nodes in a relational storage; andf. orchestrating retrieval operations by utilizing the structured context graph to guide semantic searches and construct context-aware query environments for Al agents.

[0311] The method of the current disclosure, wherein the orchestrating retrieval operations comprises operating according to an anchor-traverse-promote pattern comprising:a. finding initial data chunks via semantic retrieval from the vectorized storage during an anchor step;b. exploring connections between the initial data chunks by executing graph queries on the graph structure storage during a traverse step; and c. mapping connected data chunks back to parent logical artifacts and assembling the connected data chunks into structured data frames during a promote step.

[0312] The method of the current disclosure, further comprising constructing a virtual database payload comprising target tables, verified join hints derived from the graph structure storage, and query constraints enabling a SQL agent to perform context-aware join operations.

[0313] The method of the current disclosure, wherein processing the raw data through the micro track comprises utilizing a sliding context window comprising a defined number of data chunks forward and backward to identify neighborhood relationships between the entities, wherein the sliding context window allows relationships to extend across adjacent neighborhoods through window overlap.

[0314] The method of the current disclosure, wherein processing the raw data through the macro track comprises detecting the column similarity using Jaccard similarity by comparing sets of distinct values present in column pairs across different data artifacts.

[0315] The method of the current disclosure, further comprising:a. receiving a user query;b. performing an anchor search using the vectorized storage to identify initial data chunks semantically related to the user query;Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTc. performing graph traversal on the graph structure storage to discover additional data elements connected to the initial data chunks through the first-order relationships and the structural relationships;d. assembling a context payload comprising the initial data chunks, the additional data elements, and relationship annotations; ande. generating a response by processing the context payload through at least one of a SQL agent path for structured data operations and a RAG agent path for document context retrieval.

[0316] The system can further be described as a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform operations comprising:a. receiving raw documents and transforming the raw documents into data chunks with associated metadata;b. processing the data chunks through a micro track to identify entities using named entity recognition and to establish first-order relationships between the entities based on co-occurrence within a sliding context window; c. processing data artifacts extracted from the raw documents through a macro track to detect cross-artifact relationships through column profiling and value overlap analysis;d. constructing a structured context graph comprising entity nodes connected by the first-order relationships and artifact nodes connected by the cross-artifact relationships;e. persisting the structured context graph in a graph database, the data chunks as vector embeddings in a vector database, and entity metadata in a relational database; andf. responding to a query by performing an anchor search in the vector database to identify initial data chunks, traversing the structured context graph to discoverApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTrelated entities and artifacts, and assembling a context payload for Al agent execution.

[0317] The non-transitory computer-readable medium of the current disclosure, wherein the operations further comprise:a. processing the context payload through a SQL agent path to generate structured query results with source table and source chunk identifiers for provenance tracking; andb. processing the context payload through a RAG agent path to retrieve document passages with document identifier, page number, and chunk identifier references for traceability.

[0318] The non-transitory computer-readable medium of the current disclosure, wherein the operations further comprise aggregating the structured query results from the SQL agent path with verified text responses from the RAG agent path to produce a synthesized response that integrates quantitative data with explanatory context.

[0319] Referring now to the drawings Fig. 1 - 3, and more particularly to Fig. 1, there is shown the pharma-graph RAG pipeline 6100, which comprises four primary functional sections. The data ingestion and enrichment factory 6102 receives the raw documents 6105 and processes the raw documents 6105 through the chunking and metadata extraction 6110. The chunking and metadata extraction 6110 extracts source, section, and timestamp as metadata attributes from the raw documents 6105. The raw documents 6105 include PDFs, logs, tables, and figures as different document types.

[0320] The data ingestion and enrichment factory 6102 includes the macro track 6115 and the micro track 6130 as parallel processing tracks. The macro track 6115 comprises the logical table stitching 6120, the column profiling 6122, the LLM verification 6124, and the foreign key to edges 6126. The column profiling 6122 uses Jaccard similarity for comparing column characteristics between tables. The LLM verification 6124 validates potential SQL joins between tables identified through structural analysis. The macro track 6115 processesApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTdifferent types of macro artifacts including tables, figures, sections, paragraphs, and MQTT (loT) topics. The macro track 6115 leverages an entity co-occurrence principle where entities frequently appearing together are encoded as related to enrich the contextual graph 6270.

[0321] The micro track 6130 comprises the NER and concept normalization 6132, the concept linking 6134, and the concept edges 6136. The micro track 6130 utilizes a localized context window of 7 data chunks or sentences forward and backward for identifying neighborhood relationships. The concept linking 6134 establishes mentions and defines\_spec relationships between entities and concepts. The micro track 6130 captures data intent and operational meaning of data chunks such as safety parameters and operational specifications. Relationship extraction in the micro track 6130 utilizes either Language Models or rule-based methods to define relationships between entities.

[0322] The storage triad 6140 comprises the PostgreSQL data and registry 6142, the Apache AGE graph topology 6148, and the Qdrant vector index 6160. The storage triad 6140 comprises PostgreSQL for relational data, Apache AGE for graph topology, and Qdrant for vector indexing as specific technology implementations. The PostgreSQL data and registry 6142 contains the logical tables 6144 and the chunk storage 6146. The Apache AGE graph topology 6148 stores the logical table node 6150, the chunk node 6152, and the concept node 6154 as distinct node types. The Apache AGE graph topology 6148 includes the foreign key to edge 6156, the contains edge 6157, the mentions edge 6158, and the defines spec edge 6159 as edge types connecting the nodes. The Qdrant vector index 6160 stores the dense vectors 6162, the sparse vectors 6164, and the enriched payloads 6166. The Qdrant vector index 6160 stores both dense vectors and sparse vectors along with enriched payloads for hybrid retrieval.

[0323] The retrieval orchestration 6170 receives the user query 6172 and includes the RAG helper agent 6174. The RAG helper agent 6174 performs the anchor search 6176, the context pruning and payload construction 6177, and the graph traversal 6178. The RAG helper agent 6174 optionally rewrites the user query 6172 during the anchor phase to improve retrieval accuracy. The graph traversal 6178 explores hidden connections throughApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTmulti-level horizon expansion between anchor chunks. A retrieval plan specifies target tables with verified JOIN hints, key chunks with page ranges, relevant entities, and column lists for query constraint generation. A virtual database payload includes targets as reconstructed logical tables, verified JOIN hints from graph-derived relationships, query constraints with key entities, and contextual guidance with page ranges.

[0324] The agent execution and response 6180 receives the context payload 6190 from the RAG helper agent 6174. The context payload 6190 is formatted as JSON containing specific chunks, concepts, and metadata for agent consumption. The agent execution and response 6180 includes the SQL agent path 6182 and the RAG agent path 6191. The SQL agent path 6182 includes the SQL agent 6186 and the separate SQL queries 6184. The SQL agent path 6182 generates separate SQL queries with source table annotations for provenance tracking. The context payload 6190 provides the specific chunks JSON 6188 to the SQL agent path 6182. The SQL agent 6186 produces the aggregated SQL results 6195.

[0325] The RAG agent path 6191 receives the specific chunks and concepts 6192 from the context payload 6190. The RAG agent path 6191 includes the RAG agent 6194 and the verification and synthesis 6196. The RAG agent 6194 retrieves full text for key chunks and expands retrieval to surrounding pages using page range specifications when broader context is required. The verification and synthesis 6196 validates retrieved text before generating responses and produces the verified text response 6198. The final application layer aggregation 6197 combines the aggregated SQL results 6195 with the verified text response 6198 to produce the final user response 6199. A hybrid execution pattern combines SQL utility for quantitative patterns with RAG utility for explanatory context to produce coherent synthesized answers.

[0326] The pharma-graph RAG pipeline 6100 maintains provenance and auditability by including source\_table and source\_chunk identifiers in structured results and document\_id, page\_number, and chunk\_id references in text passages. The pharmagraph RAG pipeline 6100 is applicable to regulated industries where compliance auditing and explainability are requirements. The framework is designed with modularity allowing new application layers to be plugged in based on evolving use case requirements. SensorApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTdata processing enables temperature sensor readings to be cross-referenced with SOP-defined operating limits to create overheat alert contexts.

[0327] FIG. 2 illustrates the dynamic context construction system 6200, which depicts the relationships and data flow between components involved in transforming raw data into structured contextual information. The dynamic context construction system 6200 begins with the raw document 6205, which includes PDFs, logs, tables, and figures. The raw document 6205 passes data to the chunk 6210, which comprises text snippets and metadata.

[0328] The chunk 6210 passes data to the metadata 6215, the entity 6220, and the intent 6225 as three parallel processing paths. The metadata 6215 stores source information, section identifiers, and timestamps associated with the data chunks. The entity 6220 handles named entity recognition and concept identification. The intent 6225 captures operational meaning and safety parameters associated with the data.

[0329] The entity 6220 passes data to the relationship 6230, which models connections between entities including defines, mentions, and monitors relationships. Both the entity 6220 and the relationship 6230 feed into the graph builder 6240, which combines macro and micro outputs to generate the contextual graph 6270.

[0330] The macro artifact 6235 represents higher-level structural elements including tables, figures, sections, and streams. The macro artifact 6235 passes data to the structural analysis 6245 and the graph builder 6240. The structural analysis 6245 performs schema detection and column profiling operations. The structural analysis 6245 passes data to the foreign key relation 6255, which analyzes column similarity and value overlap to identify potential relationships between data artifacts.

[0331] The graph builder 6240 outputs to the relational store 6260 and the vector store 6250. The relational store 6260 provides SQL tables, joins, foreign keys, and schema-based storage capabilities. The vector store 6250 handles embeddings, semantic search, and similarity indexing functions. Both the relational store 6260 and the vector store 6250 pass data to the contextual graph 6270, which contains nodes for entities and artifacts, and edges representing the discovered relationships between them.Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCT

[0332] FIG. 3 illustrates the doc-type knowledge graph 6300, which represents global relationships generated from multiple processed input documents. The doc-type knowledge graph 6300 comprises the tables 6305 and the entity types 6310 as node types. The tables 6305 are represented as rectangular nodes corresponding to logical table structures extracted from source documents. The entity types 6310 are depicted as circular nodes representing named entities and concepts identified during micro track processing.

[0333] The doc-type knowledge graph 6300 includes three edge types connecting the nodes. The table join 6315 connects the tables 6305 that share structural relationships, indicating potential join paths discovered through column similarity and value overlap analysis during macro track processing. The co-occurs-with relationship 6320 links the entity types 6310 that frequently appear together within the data, encoding the principle of entity co-occurrence to enrich the overall contextual graph. The table-relates-to relationship 6325 connects the tables 6305 to the entity types 6310, establishing associations between structural data artifacts and the semantic concepts they contain or reference. The doc-type knowledge graph 6300 shows the tables 6305 connected via the table join 6315 edges, the entity types 6310 connected via the co-occurs-with relationship 6320, and the tables 6305 connected to the entity types 6310 via the table-relates-to relationship 6325.

[0334] In some embodiments the method or methods described above may be executed or carried out by a computing system including a tangible computer-readable storage medium, also described herein as a storage machine, that holds machine-readable instructions executable by a logic machine (i.e. a processor or programmable control device) to provide, implement, perform, and / or enact the above described methods, processes and / or tasks. When such methods and processes are implemented, the state of the storage machine may be changed to hold different data. For example, the storage machine may include memory devices such as various hard disk drives, CD, or DVD devices. The logic machine may execute machine-readable instructions via one or more physical information and / or logic processing devices. For example, the logic machine may be configured to execute instructions to perform tasks for a computer program. The logic machine may include one or more processors to execute the machine-readable instructions. The computing system mayApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTinclude a display subsystem to display a graphical user interface (GUI) or any visual element of the methods or processes described above. For example, the display subsystem, storage machine, and logic machine may be integrated such that the above method may be executed while visual elements of the disclosed system and / or method are displayed on a display screen for user consumption. The computing system may include an input subsystem that receives user input. The input subsystem may be configured to connect to and receive input from devices such as a mouse, keyboard or gaming controller. For example, a user input may indicate a request that certain task is to be executed by the computing system, such as requesting the computing system to display any of the above described information, or requesting that the user input updates or modifies existing stored information for processing. A communication subsystem may allow the methods described above to be executed or provided over a computer network. For example, the communication subsystem may be configured to enable the computing system to communicate with a plurality of personal computing devices. The communication subsystem may include wired and / or wireless communication devices to facilitate networked communication. The described methods or processes may be executed, provided, or implemented for a user or one or more computing devices via a computer-program product such as via an application programming interface (API).

[0335] Since many modifications, variations, and changes in detail can be made to the described embodiments of the invention, it is intended that all matters in the foregoing description and shown in the accompanying drawings be interpreted as illustrative and not in a limiting sense. Furthermore, it is understood that any of the features presented in the embodiments may be integrated into any of the other embodiments unless explicitly stated otherwise. The scope of the invention should be determined by the appended claims and their legal equivalents.

[0336] In addition, the present invention has been described with reference to embodiments, it should be noted and understood that various modifications and variations can be crafted by those skilled in the art without departing from the scope and spirit of theApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTinvention. Accordingly, the foregoing disclosure should be interpreted as illustrative only and is not to be interpreted in a limiting sense. Further it is intended that any other embodiments of the present invention that result from any changes in application or method of use or operation, method of manufacture, shape, size, or materials which are not specified within the detailed written description or illustrations contained herein are considered within the scope of the present invention.

[0337] Insofar as the description above and the accompanying drawings disclose any additional subject matter that is not within the scope of the claims below, the inventions are not dedicated to the public and the right to file one or more applications to claim such additional inventions is reserved.

[0338] Although very narrow claims are presented herein, it should be recognized that the scope of this invention is much broader than presented by the claim. It is intended that broader claims will be submitted in an application that claims the benefit of priority from this application.

[0339] While this invention has been described with respect to at least one embodiment, the present invention can be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains and which fall within the limits of the appended claims.

Claims

Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTClaim1. A system for contextual enrichment and persistence in Al agentic applications, comprising:an enrichment factory configured to receive raw data from disparate sources and transform the raw data into a structured context graph, the enrichment factory comprising:a micro track processor configured to identify entities within data chunks using named entity recognition and to model first-order relationships between the entities within a localized context window; anda macro track processor configured to perform structural analysis on data artifacts and to model second-order relationships between the data artifacts through cross-artifact correlation including detection of column similarity and value overlap between the data artifacts;a persistence layer comprising a multi-modal storage architecture configured to store outputs from the enrichment factory, the multi-modal storage architecture comprising:a vectorized storage configured to store the data chunks as vector representations to enable semantic retrieval;a graph structure storage configured to store the structured context graph representing the first-order relationships and the second-order relationships to enable contextual reasoning; anda relational storage configured to store structured records of the entities with pointers to corresponding vector representations in the vectorized storage and corresponding nodes in the graph structure storage; and an application layer configured to leverage the structured context graph for Al agent operations.

2. The system of claim 1, wherein the application layer comprises a retrieval orchestration layer configured to utilize the graph structure storage to discover relevantApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTentities and relationships and to construct a virtual database payload for querying the data chunks.

3. The system of claim 2, wherein the retrieval orchestration layer operates according to an anchor-traverse-promote pattern comprising:finding initial data chunks via semantic retrieval from the vectorized storage during an anchor step;exploring connections between the initial data chunks by executing graph queries on the graph structure storage during a traverse step; and mapping connected data chunks back to parent logical artifacts and assembling the connected data chunks into structured data frames during a promote step.

4. The system of claim 3, wherein the retrieval orchestration layer constructs the virtual database payload comprising target tables, verified join hints derived from the graph structure storage, and query constraints enabling a SQL agent to perform context-aware join operations.

5. The system of claim 1, wherein the application layer comprises a generative actions layer configured to integrate the structured context graph to drive autonomous actions and real-time decision-making by an Al agent.

6. The system of claim 1, wherein the micro track processor utilizes a sliding context window comprising a defined number of data chunks forward and backward to identify neighborhood relationships between the entities, wherein the sliding context window allows relationships to extend across adjacent neighborhoods through window overlap.

7. The system of claim 1, wherein the macro track processor detects the column similarity using Jaccard similarity by comparing sets of distinct values present in column pairs across different data artifacts.

8. The system of claim 1, wherein the relational storage acts as a master index for the persistence layer, storing attributes for each entity including a pointer to a correspondingApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTvector representation in the vectorized storage and a pointer to a corresponding node in the graph structure storage.

9. The system of claim 1, wherein the macro track processor further models the second-order relationships by leveraging entity co-occurrence, wherein entities frequently appearing together within the data chunks are encoded as related within the structured context graph.

10. The system of claim 1, wherein the graph structure storage stores:logical table nodes representing table structures identified during macro track processing;chunk nodes representing individual data chunks extracted from source documents; andconcept nodes representing the entities identified during micro track processing.

11. The system of claim 10, wherein the graph structure storage stores edge types comprising:foreign key edges connecting pairs of the logical table nodes that share verified join relationships;contains edges connecting the chunk nodes to the concept nodes indicating which concepts appear within each data chunk; anddefines specification edges connecting nodes where one data element provides specification information for another data element.

12. A method for enhancing contextual reasoning in Al agentic applications, comprising: receiving raw data from disparate sources including documents and data streams;processing the raw data through a micro track to identify entities within data chunks and to establish first-order relationships between the entities within a localized context window;Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTprocessing the raw data through a macro track to identify structural relationships between data artifacts through column similarity analysis and value overlap analysis;generating a structured context graph that integrates the first-order relationships from the micro track and the structural relationships from the macro track;storing the structured context graph in a graph structure storage, storing the data chunks as vector representations in a vectorized storage, and storing entity records with pointers to the vector representations and graph nodes in a relational storage; andorchestrating retrieval operations by utilizing the structured context graph to guide semantic searches and construct context-aware query environments for Al agents.

13. The method of claim 12, wherein the orchestrating retrieval operations comprises operating according to an anchor-traverse-promote pattern comprising:finding initial data chunks via semantic retrieval from the vectorized storage during an anchor step;exploring connections between the initial data chunks by executing graph queries on the graph structure storage during a traverse step; and mapping connected data chunks back to parent logical artifacts and assembling the connected data chunks into structured data frames during a promote step.

14. The method of claim 13, further comprising constructing a virtual database payload comprising target tables, verified join hints derived from the graph structure storage, and query constraints enabling a SQL agent to perform context-aware join operations.

15. The method of claim 12, wherein processing the raw data through the micro track comprises utilizing a sliding context window comprising a defined number of data chunksApplicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTforward and backward to identify neighborhood relationships between the entities, wherein the sliding context window allows relationships to extend across adjacent neighborhoods through window overlap.

16. The method of claim 12, wherein processing the raw data through the macro track comprises detecting the column similarity using Jaccard similarity by comparing sets of distinct values present in column pairs across different data artifacts.

17. The method of claim 12, further comprising:receiving a user query;performing an anchor search using the vectorized storage to identify initial data chunks semantically related to the user query;performing graph traversal on the graph structure storage to discover additional data elements connected to the initial data chunks through the first-order relationships and the structural relationships;assembling a context payload comprising the initial data chunks, the additional data elements, and relationship annotations; and generating a response by processing the context payload through at least one of a SQL agent path for structured data operations and a RAG agent path for document context retrieval.

18. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform operations comprising: receiving raw documents and transforming the raw documents into data chunks with associated metadata;processing the data chunks through a micro track to identify entities using named entity recognition and to establish first-order relationships between the entities based on cooccurrence within a sliding context window;Applicant: Anil Kumar Chandrupatla, et al.Atty. Docket No.: LITEWAVEAI-0007PCTprocessing data artifacts extracted from the raw documents through a macro track to detect cross-artifact relationships through column profiling and value overlap analysis;constructing a structured context graph comprising entity nodes connected by the first-order relationships and artifact nodes connected by the crossartifact relationships;persisting the structured context graph in a graph database, the data chunks as vector embeddings in a vector database, and entity metadata in a relational database; and responding to a query by performing an anchor search in the vector database to identify initial data chunks, traversing the structured context graph to discover related entities and artifacts, and assembling a context payload for Al agent execution.

19. The non-transitory computer-readable medium of claim 18, wherein the operations further comprise:processing the context payload through a SQL agent path to generate structured query results with source table and source chunk identifiers for provenance tracking; and processing the context payload through a RAG agent path to retrieve document passages with document identifier, page number, and chunk identifier references for traceability.

20. The non-transitory computer-readable medium of claim 19, wherein the operations further comprise aggregating the structured query results from the SQL agent path with verified text responses from the RAG agent path to produce a synthesized response that integrates quantitative data with explanatory context.

Images