Description:BACKGROUND
Technical Field
[0001] The present invention generally relates to retrieval-augmented generative artificial intelligence systems and, more particularly, to a method and system for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data.
Description of the Related Art
[0002] Retrieval-Augmented Generation (RAG) systems are increasingly used to improve the performance of large language models (LLMs) by grounding generated outputs in external knowledge sources such as enterprise documents, databases, knowledge repositories, and internal content systems. In conventional implementations, documents are converted into embeddings, candidate passages are retrieved using vector similarity search, and the retrieved passages are appended to prompts submitted to a language model for answer generation. However, they remain subject to significant technical limitations that reduce reliability, security, and scalability in enterprise deployments.
[0003] Existing RAG systems perform retrieval based primarily on similarity scoring rather than semantic admissibility. As a result, materials that are merely topically related may be selected even if they are outdated, unauthorized, low-trust, incomplete, or unsuitable for the requested task. In addition, retrieved context often contains excessive text, duplicated passages, contradictory statements, fragmented records, or semantically incompatible information assembled from multiple sources. This uncontrolled expansion of context windows increases processing cost and can degrade downstream model performance.
[0004] A conventional RAG pipeline generally lacks formal mechanisms for validating whether the retrieved context is logically consistent, temporally coherent, or semantically satisfiable before it is passed to the language model. Contradictory or contaminated context may therefore be submitted directly into generation workflows. Enterprise use also introduces significant data protection concerns because sensitive corporate information, personally identifiable information, confidential records, trade secrets, or regulated data may be included in prompts or retrieved passages transmitted to internal or external model endpoints without adequate semantic inspection or governance controls.
[0005] Many existing retrieval systems operate in a largely static manner, relying on fixed embeddings, ranking heuristics, or manually tuned pipelines that do not continuously adapt to user feedback, hallucination events, policy changes, newly ingested documents, or evolving enterprise priorities. Prompts are also commonly provided as free-form natural language instructions lacking enforceable constraints, provenance controls, or auditable execution policies. As enterprise knowledge bases continue to expand, such approaches become increasingly inefficient and fail to preserve semantic structure at scale.
[0006] Accordingly, there exists a need for an improved retrieval-augmented generation framework that governs retrieval before scoring, compresses semantic knowledge while preserving meaning, certifies context before generation, prevents semantic data leakage, continuously adapts based on enterprise events, and enforces structured prompt governance.
SUMMARY
[0007] In view of the foregoing, there is provided a processor-implemented method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data. The method includes receiving, by a server, a query from a user device associated with a user. The method includes determining, based on a semantic retrieval contract, boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens, wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions. The method includes retrieving, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology. The method includes constructing a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics. The method includes retrieving a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources and mapping the raw enterprise dataset into semantic objects represented as tuples of the ontology-anchored attributes, wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts. The method includes mapping the retrieved ontology-anchored concepts and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes. The method includes verifying, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by performing a formal concept closure operation using closure operators on the formal context to determine a closure-consistent extent and intent, and verifying the derived semantic concepts correspond to the closure-consistent extent and intent. The method includes executing a semantic use case function only when the derived semantic concepts satisfy the closure condition to generate an intent-aligned analytical result. The method includes generating, using a large language model (LLM), a response as a final certified analytical output based on the intent-aligned analytical result. The response includes the data associated with the verified and derived semantic concepts.
[0008] In some embodiments, the method comprises applying a semantic data folding technique to the retrieved ontology-anchored concepts and the derived semantic concepts to transform high-dimensionality semantic representations into compact folded forms that preserve structural invariants and reduce computational complexity, wherein the folded forms are reversibly unfoldable to restore original semantic meaning without loss, wherein the computable semantic metrics represent at least one of an entity concept, an attribute concept, a relationship concept, or a metric concept.
[0009] In some embodiments, the method comprises performing semantic data exfiltration control mediated by at least one of Application Programming Interfaces (APIs), external servers, or agent-to-agent communication protocols before constructing the formal context. The method includes intercepting at least one of the retrieved ontology-anchored concepts, the derived semantic concepts, the query, or a tool invocation. The method includes performing semantic inspection of the intercepted data against ontology-defined sensitivity labels, the extracted user intent, and enterprise policy constraints. The method includes executing an enforcement action comprising at least one of allowing execution, redacting sensitive content, requiring user confirmation, or blocking execution, and logging an event if a violation is detected, and generating an audit-grade semantic trace associated with the enforcement action to provide a certifiable record of AI governance for every enforcement action to provide a certifiable record of semantic data-egress control.
[0010] In some embodiments, the formal context is certified only if the closure-consistent extent and intent of a folded representation is equivalent to the closure-consistent extent and intent of its corresponding unfolded representation, ensuring semantic integrity across computational states.
[0011] In some embodiments, the method comprises compiling the query into an executable prompt contract comprising machine-enforceable constraints for at least one of permitted entities, prohibited inferences, required citations, or confidence thresholds before invoking the LLM, wherein the LLM is invoked only if the formal context satisfies the executable prompt contract, thereby preventing the generation of out-of-domain hallucinations.
[0012] In some embodiments, the method comprises intercepting at least one of the query, the formal context, or the formal concept closure, and performing a semantic inspection against ontology-defined sensitivity labels to determine an enforcement action comprising at least one of redacting sensitive content or blocking execution.
[0013] In some embodiments, the method comprises detecting a semantic event comprising at least one of an FCA rejection or a hallucination detection, folding a history of said semantic events into a recurring event pattern, and automatically suppressing invalid knowledge paths in the domain ontology based on the recurring event pattern without retraining the LLM.
[0014] In some embodiments, the one or more semantic filters are applied to the domain ontology prior to performing a retrieval technique, wherein the one or more semantic filters prune candidate fragments to ensure only semantically admissible data is ranked for retrieval.
[0015] In some embodiments, the semantic use case function is defined as U = f (C, D), wherein the C is the ontology-anchored concepts, D is the derived semantic concepts, and f is a semantic evaluation function.
[0016] In some embodiments, the method further comprises generating the semantic retrieval contract that comprises permissible entities, permissible relationships between the entities, traversal depth for query expansion, and sensitivity constraints for retrieval, and controlling retrieval candidate generation according to the semantic retrieval contract.
[0017] In some embodiments, when the formal context fails to satisfy the closure-consistent extent and intent, the method performs at least one remediation operation before providing the contextual data to the LLM. The remediation operation includes at least one of pruning a semantically inadmissible portion of the formal context, partitioning the formal context into separately certifiable context groups, or rejecting the formal context prior to invoking the LLM.
[0018] In some embodiments, upon detecting a violation of the executable prompt contract, the method performs at least one of blocking execution of the query, rewriting the query or prompt to generate a modified prompt that complies with the prompt contract, or generating, by the LLM, the response limited to permitted data or context and excluding the sensitive content by executing the query.
[0019] In some embodiments, the semantic event comprises at least one of human correction, policy violation, or prompt override.
[0020] In some embodiments, the semantic use case function corresponds to at least one of analytics, anomaly detection, compliance determination, decision intelligence, enterprise copilot execution, or retrieval-augmented reasoning.
[0021] In some embodiments, the data from the raw enterprise dataset associated with the retrieved ontology-anchored concepts is included in a context provided to the LLM, or in the LLM response, only when the derived semantic concepts belong to the certified formal concept satisfying the closure-consistent extent and intent.
[0022] In some embodiments, the verification of semantic consistency is performed using a constraint-based validation model comprising at least one of a graph-based reasoning, a rule-based validation, or a probabilistic constraint satisfaction.
[0023] In some embodiments, the formal context is stored in an append-only semantic event store to maintain auditability and traceability.
[0024] In another aspect, there is provided a system for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data. The system comprises a server that receives a query from a user device associated with a user. The server comprises a memory that comprises a set of instructions and a processor to execute the set of instructions, and is configured to determine, based on a semantic retrieval contract, boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens, wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions. The processor retrieves, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology. The processor constructs a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics. The processor retrieves a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources and maps the raw enterprise dataset into semantic objects/formal concept objects represented as tuples of the ontology-anchored attributes, wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts. The processor maps the retrieved ontology-anchored concepts and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes. The processor verifies, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by performing a formal concept closure operation using closure operators on the formal context to determine a closure-consistent extent and intent, and verifying that the derived semantic concepts correspond to the closure-consistent extent and intent. The processor executes a semantic use case function only when the derived semantic concepts satisfy a closure condition to generate an intent-aligned analytical result. The processor generates, using a large language model (LLM), a response as a final certified analytical output based on the intent-aligned analytical result, wherein the response comprises the data associated with the verified and derived semantic concepts.
[0025] In some embodiments, the formal context is certified only if the closure-consistent extent and intent of a folded representation is equivalent to the closure-consistent extent and intent of its corresponding unfolded representation, ensuring semantic integrity across computational states.
[0026] In another aspect, there is provided a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data. The method includes receiving, by a server, a query from a user device associated with a user. The method includes determining, based on a semantic retrieval contract, boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens, wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions. The method includes retrieving, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology. The method includes constructing a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics, wherein the plurality of derived semantic concepts represents semantic metrics. The method includes retrieving a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources and mapping the raw enterprise dataset into semantic objects/formal concept objects represented as tuples of the ontology-anchored attributes, wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts. The method includes mapping the retrieved ontology-anchored concepts and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes. The method includes verifying, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by performing a formal concept closure operation using closure operators on the formal context to determine a closure-consistent extent and intent, and verifying the derived semantic concepts correspond to the closure-consistent extent and intent. The method includes executing a semantic use case function only when the derived semantic concepts satisfy a closure condition to generate an intent-aligned analytical result; and generating, using a large language model (LLM), a response as a final certified analytical output based on the intent-aligned analytical result, wherein the response comprises the data associated with the verified and derived semantic concepts.
[0027] These other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.
BRIEF DESCRIPTION OF THE DRAWINGS
[0028] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[0029] FIG. 1 is a block diagram that illustrates a system for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, according to some embodiments herein;
[0030] FIG. 2 is a block diagram that illustrates a server, according to some embodiments herein;
[0031] FIG. 3 illustrates a concept lattice generated by the ontology-anchored concepts retrieving module using a Formal Concept Analysis (FCA)-based formal context, according to some embodiments herein;
[0032] FIGS. 4A-4B are flow diagrams that illustrate a method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, according to some embodiments herein; and
[0033] FIG. 5 is a schematic diagram of a computer architecture in accordance with the embodiments herein.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0034] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0035] As mentioned, embodiments herein provide a system and a method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data. Referring now to the drawings, and more particularly to FIGS. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figure’s, preferred embodiments are shown.
[0036] Semantic Data folding: Transformation of ontology-anchored semantic representations into compact folded forms that preserve semantic invariants and are reversibly unfoldable.
[0037] Semantic Retrieval Contract: An executable specification defining permissible entities, relationships, depth, and sensitivity for retrieval.
[0038] Context Certification: Mathematical verification that a set of retrieved semantic fragments forms a valid and admissible semantic concept.
[0039] Prompt Contract: A machine-enforceable constraint specification governing prompt execution and output.
[0040] Semantic Event: An ontology-anchored record describing an occurrence in the AI system lifecycle.
[0041] Formal Concept Analysis (FCA) is a method used to analyze data by discovering and structuring relationships between objects and their attributes. It provides a principled way to derive a concept hierarchy (or ontology) from a dataset, where each concept represents a group of objects sharing common properties. In FCA, data is organized into a structure called a formal context, which consists of three components: a set of objects (G), a set of attributes (M), and a relation (I) indicating which objects have which attributes. Based on this context, FCA identifies formal concepts, each defined as a pair consisting of an extent (the set of objects) and an intent (the set of attributes shared by those objects). These concepts are then arranged into a concept lattice, a hierarchical structure that reveals how concepts relate to one another from more general groupings to more specific ones.
[0042] An ontology lens comprises a query interpretation module configured to map natural language input to ontology nodes using entity recognition, relationship extraction, and constraint inference.
[0043] Structural invariants in a domain model are rules, constraints, or properties that must always remain true within a specific bounded context. They ensure that domain objects never enter an invalid state.
[0044] Semantic data exfiltration control refers to a specialized, context-aware cybersecurity approach designed to prevent the unauthorized transfer or leakage of sensitive information by understanding the meaning, content, and context of the data. The semantic data folding technique used herein represents the process of creation of data lattices using the extracted entities, events and domain specific associations and storing the created data lattices as a view.
[0045] FIG. 1 illustrates a system 100 for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, according to some embodiments herein. The system 100 includes a user device 104 associated with a user 102, a network 106, and a server 108. The server 108 includes a Large Language Model (LLM) 114, a processor 112, and a memory 110. The memory 110 includes a set of instructions. The processor 112 is configured to execute the set of instructions. The server 108 is communicatively connected to the user device 104 through the network 106 to receive a query from the user 102. For example, the query is “Identify products supplied by the same supplier that have different prices across sites.”
[0046] The user device 104, without limitation, may include a mobile phone, a Kindle, a PDA (Personal Digital Assistant), a tablet, a computer, an electronic notebook, or a smartphone. In some embodiments, the network 106 is a wireless network. In some embodiments, the network 106 is a combination of a wired network and a wireless network. In some embodiments, the network 106 is the Internet. The network 106 may support agent-to-agent communication, wherein multiple agents communicate directly with one another to exchange data, coordinate tasks, or perform distributed processing.
[0047] The server 108 determines boundaries by mapping an intent of the query to a domain ontology through an ontology lens (116). The server 108 determines the boundaries based on a semantic retrieval contract (118). The server 108 determines the intent of the query. For example, the intent of the query: "Identify products supplied by the same supplier that have different prices across sites." is to find a product entity related to the supplier and site entity, and the attribute price. The domain ontology defines one or more entities, attributes, semantic constraints, and valid relationships between the entities and the attributes. The boundaries include a target entity, permissible paths, or forbidden regions.
[0048] For example, upon receiving the query from the user device 104, the server 108 interprets the user intent and maps the query into a procurement domain ontology. The procurement domain ontology defines the semantic entities “product”, “supplier”, “site”, and “price”, together with valid relationships such as a supplier supplying a product to one or more sites at a corresponding unit price.
[0049] The “product” refers to the catalogue item or material being purchased, such as a spare part, raw material, or finished good. The product represents the item whose pricing is being analyzed across different locations. The supplier refers to the supplier entity or vendor that provides the product. The site refers to the procurement location, plant, warehouse, branch, or operating unit where the product is purchased or delivered. The price refers to the unit price paid for the product at a given site.
[0050] In some embodiments, the server 108 generates the semantic retrieval contract 118 and controls retrieval candidate generation according to the semantic retrieval contract 118. The semantic retrieval contract 118 may include an executable machine-enforceable retrieval specification that defines permissible entities, permissible relationships between the entities, traversal depth for query expansion, and sensitivity constraints for retrieval.
[0051] The semantic retrieval contract 118 includes certain areas as forbidden, including restricted datasets, prohibited ontology regions, confidential repositories, blocked semantic paths, or excluded enterprise domains. Before permitting retrieval, the server 108 may perform screening on the query. The screening may include validation of user intent, credential checks, policy compliance checks, query classification, sensitivity analysis, ontology-boundary verification, or risk scoring to determine whether the query qualifies for execution.
[0052] In some embodiments, the server 108 identifies and blocks suspicious items from entering the retrieval pipeline. The suspicious items may include malformed queries, prohibited prompts, sensitive attributes, anomalous tool block calls, data exfiltration attempts, unauthorized expansion paths, or policy-violating content. Upon detection, the server 108 may block, quarantine, redact, rewrite, or log the suspicious item.
[0053] The server 108 retrieves one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions. The server 108 retrieves one or more ontology-anchored concepts based on the target entity. The server 108 applies semantic filters to the domain ontology before performing the retrieval. The one or more semantic filters prune candidate fragments to ensure only semantically admissible data is ranked for retrieval. For example, the ontology-anchored concept is represented as C = {Product, Supplier, Site, Price}.
[0054] The server 108 constructs one or more derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics.
[0055] In one implementation, the derived semantic concept is PriceVariance(Product, Supplier) that measures the difference between the highest and lowest price charged by the same supplier for the same product across multiple sites. The PriceVariance is computed as: PriceVariance (Product, Supplier) = max (price across sites) - min (price across sites), to identify whether the supplier is charging inconsistent prices at different procurement locations. For example, if supplier S7 sells Product P100 for 100 at Site S1 and 105 at Site S2, then the PriceVariance is 5.
[0056] The derived semantic concept is SitePriceDifference(Product, Supplier, Site), which measures how much the price at a specific site differs from a selected reference price. The SitePriceDifference is computed as: SitePriceDifference(Product, Supplier, Site) = price(site) - reference_price. The reference price may be the lowest, average price, contract price, or global standard price, i.e., identify whether one site is paying more or less than expected. For example, if the reference price is 100 and Site S2 pays 105, then the SitePriceDifference is +5.
[0057] The derived semantic concept is SupplierPriceConsistency(Product, Supplier) that measures how stable or consistent a supplier’s pricing is across sites. The SupplierPriceConsistency is computed using the statistical variance of prices across sites: SupplierPriceConsistency(Product, Supplier) = variance(price across sites). The low variance means the supplier prices are consistent across locations, while a high variance indicates irregular pricing behavior. This helps in supplier governance, negotiation, and compliance reviews. The computed concepts are grouped into the derived semantic concept set:D = {PriceVariance, SitePriceDifference, SupplierPriceConsistency}
[0058] In some embodiments, the server 108 applies a semantic data folding technique to the retrieved ontology-anchored concepts and the derived semantic concepts to transform high-dimensional semantic representations into compact folded forms that conform to the domain model, using FCA techniques. The folding targets include retrieved ontology-anchored concepts, derived semantic concepts, ontology-anchored document fragments, embedding vectors augmented with semantic labels, event-derived semantic patterns, and prompt and context representations. The compact folded forms preserve structural invariants and reduce computational complexity. The folded forms are reversibly unfoldable to restore original semantic meaning without loss because of the mathematical concept of FCA and well defined domain model. The semantic metrics represent at least one of an entity concept, an attribute concept, a relationship concept, or a metric concept. For example, a semantic metric is as follows: SitePriceDifference(Product, Supplier, Site) = price(site) - reference_price Product, Supplier, Site are entity and together a concept with the attribute price of Site entity that is connected to Supplier and the overall statement including the statement price(site) - reference_price that defines the overall SitePriceDifference metric.
[0059] In one implementation, the semantic data folding technique comprises projecting high-dimensional semantic vectors onto a reduced-dimensional manifold using a structure-preserving transformation function F such that F(x) maintains adjacency relations between ontology-linked entities. The server 108 applies the inverse transformation F⁻¹ to reconstruct the original semantic representation while unfolding. The structure-preserving transformation maintains at least one of adjacency relations, ontology linkage constraints, or attribute co-occurrence relationships.
[0060] The server 108 retrieves a raw enterprise dataset associated with the ontology-anchored concepts from external data sources 120. The raw enterprise dataset refers to data in its original, unprocessed form as it exists within source systems such as databases, files, or external feeds. The raw enterprise dataset may include structured data (like tables in databases), semi-structured data (such as JSON or XML files), and unstructured data (including emails, documents, or images). The external data sources 120 may include third-party providers, public datasets, or industry-specific platforms. The server 108 maps the raw enterprise dataset into semantic objects (G) represented as tuples of the ontology-anchored attributes. The server 108 maps the raw enterprise dataset to the semantic objects (G) by identifying entities within the raw enterprise dataset. The entities represent the objects of interest, such as customers, products, or transactions. At this stage, the data is still unstructured or loosely structured, so the server 108 determines what constitutes a meaningful object. For example, rows in a table might be grouped to represent a single customer, and repeated entries may be consolidated so that each entity is uniquely defined.
[0061] Once the entities are identified, the server 108 extracts their attributes. The attributes define the properties or characteristics of each entity. For the purpose of Formal Concept Analysis (FCA) method, the attributes are transformed into a binary format indicating whether a given entity has a specific property or not. For example, instead of storing “location = XYZ,” the server 108 may represent this as a binary attribute like “is_in_XYZ.” This transformation standardizes the data and prepares it for the FCA.
[0062] After defining entities and attributes, the server 108 constructs what is known as the formal context, which consists of three components a set of objects (entities), a set of attributes, and a relation that links objects to the attributes they possess. The formal context is represented as a matrix where rows correspond to entities and columns correspond to attributes, with entries indicating the presence or absence of each attribute for each entity.
[0063] The raw enterprise dataset includes data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts.
[0064] Table:1 shows an example raw enterprise dataset
Table:1
catalogue_id supplier_id site_id price
P100 S7 S1 100
P100 S7 S2 105
P200 S7 S1 110
P200 S7 S2 115
P300 S8 S1 95

[0065] In this example, each tuple is structured as (product, supplier, site, price), where the first element identifies the product, the second element identifies the supplier, the third element identifies the procurement site, and the fourth element identifies the corresponding unit price. By converting each data record into a tuple format, the server 108 generates machine-interpretable semantic objects suitable for formal reasoning and concept certification.
[0066] For example, the object o1 = (P100, S7, S1, 100) represents a procurement transaction in which Product P100 is supplied by Supplier S7 at Site S1 for a unit price of 100. Similarly, the object o2 = (P100, S7, S2, 105) represents the same product supplied by the same supplier at a different site, site S2, at a unit price of 105. These two tuples enable the system 100 to recognize that the same supplier offers the same product across multiple sites with differing prices.
[0067] The semantic objects are likewise created from the enterprise data. The object o3 = (P200, S7, S1, 110) indicates that Supplier S7 supplies Product P200 at Site S1 for 110, while o4 = (P200, S7, S2, 115) indicates the same product and supplier combination at Site S2 for 115. The object o5 = (P300, S8, S1, 95) represents Product P300 supplied by Supplier S8 at Site S1 for 95. Since only one site record exists for this product-supplier pair (P300, s8), cross-site comparison may be unavailable.
[0068] The server 108 maps the retrieved ontology-anchored concepts and the derived semantic concepts into the formal context. The formal context includes the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes.
[0069] The formal context is represented as {G, M, I}, where G = Set of Objects, G represents the set of formal objects derived from the raw procurement dataset. Each object corresponds to a single transactional record transformed into a semantic tuple, such as (Product, Supplier, Site, Price).
[0070] In this example: G = {o1, o2, o3, o4, o5}
[0071] Where, o1 = (P100, S7, S1, 100), o2 = (P100, S7, S2, 105), o3 = (P200, S7, S1, 110), o4 = (P200, S7, S2, 115), o5 = (P300, S8, S1, 95). These objects are the rows of certified enterprise data used for concept discovery.
[0072] Where M = Set of Attributes. M represents the semantic attributes extracted from the ontology and assigned to the objects.
[0073] In this example:
M={
product=P100,
product=P200,
supplier=S7,
supplier=S8,
site=S1,
site=S2
}
These attributes describe common attributes shared across the objects.
[0074] Where I = Incidence Relation, I represents the relationship between objects in G and attributes in M. It defines which object possesses which attribute.
[0075] For example:
o1 has attributes product=P100, supplier=S7, site=S1
o2 has attributes product=P100, supplier=S7, site=S2
o3 has attributes product=P200, supplier=S7, site=S1
o4 has attributes product=P200, supplierS7, site=S2
o5 has attributes supplier=S8, site=S1 (and product=P300 if included)
[0076] By constructing {G, M, I}, the server 108 converts the ontology-anchored concepts and the derived semantic concepts into the formal context, i.e., raw procurement data into a formal semantic structure. The server 108 executes a Formal Concept Analysis, which can then automatically discover groups of records that share common attributes, such as all records for Product P100 supplied by Supplier S7. These groups become formal concepts used later for certified analytics, such as price variance detection.
[0077] In some embodiments, the server 108 performs semantic data exfiltration control mediated by at least one of Application Programming Interfaces (APIs), external servers, or agent-to-agent communication protocols before constructing the formal context.
[0078] The server 108 performs the semantic data exfiltration control mediated by (i) intercepting at least one of the retrieved ontology-anchored concepts, the derived semantic concepts, the query, or a tool invocation, (ii) performing semantic inspection of the intercepted data against ontology-defined sensitivity labels, the extracted user intent, and enterprise policy constraints, executing an enforcement action includes at least one of allowing execution, redacting sensitive content, requiring user confirmation, or blocking execution and logging an event if a violation is detected, and (iii) generating an audit-grade semantic trace associated with the enforcement action to provide a certifiable record of AI governance for every enforcement action.
[0079] The server 108 intercepts at least one of the query, the formal context, or the formal concept closure, and performs a semantic inspection against ontology-defined sensitivity labels to determine an enforcement action. The enforcement action includes at least one of redacting sensitive content or blocking execution. The server 108 verifies the derived semantic concepts by performing a formal concept closure operation using closure operators on the formal context (G, M, I) to determine a closure-consistent extent (G″) and intent (M″) and verifying the derived semantic concepts correspond to the closure-consistent extent and intent. The extent and intent are determined by identifying overlapped ontology-anchored attributes among the semantic objects based on the entity and the user intent. The intent includes the overlapped ontology-anchored attributes shared by at least one of the semantic objects. The extent includes the semantic objects that overlaps the ontology-defined attributes.
[0080] The closure operator defines the set of objects A ⊆ G, A′ = {m ∈ M | ∀g ∈ A, (g, m) ∈ I}, and A″ = (A′)′, and a formal concept is defined when A = A″.
[0081] The intent and extent step effectively uncovers hidden groupings and relationships within the data by identifying clusters of entities that exhibit similar characteristics. The server 108 organizes the formal concepts into a concept lattice, which provides a hierarchical structure of the data. More general concepts appear higher in the lattice, while more specific ones appear lower. This hierarchy defines how different groups of entities relate to one another based on shared attributes.
[0082] The derived semantic concepts are then evaluated only within the certified extents and intents. For the first certified concept (Intent: relating to Product P100 and Supplier S7, the server 108 computes PriceVariance = 105 - 100 = 5 based on the prices observed at Sites S1 and S2. This means that objects o1 and o2 both share the attributes Product P100 and Supplier S7. In the procurement data, these two records represent the same product supplied by the same supplier across different sites. Therefore, the FCA groups them into a first certified concept. The concept is useful for comparing site-level prices for Product P100 from Supplier S7.
[0083] For the second concept relating to Product P200 and Supplier S7, the server 108 computes PriceVariance = 115 - 110 = 5. This means that objects o3 and o4 both share the attributes Product P200 and Supplier S7. These records correspond to another product supplied by the same supplier across multiple sites. The FCA therefore forms a second certified concept for Product P200 supplied by Supplier S7.
[0084] For the third concept relating to Product P300 and Supplier S8, only one site price exists, and therefore PriceVariance = 0. Since these computations are derived solely from certified ontology-compliant contexts, the resulting metrics are contextually validated. This means object o5 alone possesses the attributes Product P300 and Supplier S8. Since there is only one matching record, the extent contains a single object. This concept indicates that only one site record exists for Product P300 from Supplier S8, so cross-site comparison may not be possible.
[0085] The server 108 performs at least one remediation operation before providing the contextual data to the LLM 114 when the formal context fails to satisfy the closure-consistent extent and intent. The remediation operation includes at least one of pruning a semantically inadmissible portion of the formal context, partitioning the formal context into separately certifiable context groups, or rejecting the formal context before invoking the LLM 114.
[0086] The failure to satisfy the closure-consistent extent and intent may indicate that the retrieved objects and attributes do not form a coherent certified semantic grouping under the Formal Concept Analysis. The failure may arise where unrelated entities, conflicting attributes, mixed jurisdictions, duplicate identities, incompatible business scopes, or improper relationship paths are present in the retrieved context.
[0087] The pruning may include removing objects, attributes, relationships, records, or candidate fragments that cause closure failure or fall outside the ontology-defined intent of the query. For example, where a supplier-risk query intended for Supplier A in AB country retrieves records relating to Supplier A in BC country, the unrelated BC country data may be removed so that the remaining context becomes certifiable.
[0088] In another implementation, the remediation operation includes partitioning the formal context into separately certifiable context groups. The partitioning may divide the retrieved context into multiple smaller semantic subsets based on geography, legal entity, supplier instance, contract scope, business unit, time period, or ontology branch. Each subset may then be independently evaluated for closure satisfaction. For example, records relating to Supplier A in AB country and Supplier A in BC country may be separated into distinct contexts, each capable of separate validation and analysis.
[0089] In a further implementation, the remediation operation comprises rejecting the formal context before invoking the LLM. The rejection may occur when ambiguity, contamination, conflict, or insufficient semantic certainty prevents reliable certification. Upon rejection, the system may block execution, request clarification from the user 102, generate a disambiguation prompt, or instruct the user to specify the intended entity or legal scope. For example, where retrieved records mix multiple legal entities and the intended supplier instance cannot be reliably resolved, the server 108 may refuse response generation until clarification is received.
[0090] In one example, the user query: “Show supplier risk, payment failures, and contract breaches for Supplier A across all subsidiaries.” If retrieval returns mixed records for Supplier A in AB country, Supplier A in BC country, and an unrelated contract from a separate legal entity, the server 108 may prune the unrelated contract data, partition AB country and BC country records into separate certifiable contexts, or reject the query pending clarification regarding the intended legal entity.
[0091] In some embodiments, the server 108 certifies the formal context if the closure-consistent extent and intent of a folded representation is equivalent to the closure-consistent extent and intent of its corresponding unfolded representation, ensuring semantic integrity across computational states.
[0092] The server 108 computes metrics using only the records contained within each concept extent using the certified object groups. For the present example, the derived semantic concept being evaluated is PriceVariance, which measures the difference between the maximum and minimum price of the same product supplied by the same supplier across different sites. For the first concept, corresponding to Product P100 supplied by Supplier S7, the certified records include Site S1 with a price of 100 and Site S2 with a price of 105. The server 108 computes the derived metric as:
[0093] PriceVariance(P100, S7) = 105 - 100 = 5
[0094] This indicates that the same supplier charges a price difference of five units for Product P100 across the two procurement sites.
[0095] For the second concept, corresponding to Product P200 supplied by Supplier S7, the certified records include Site S1 with a price of 110 and Site S2 with a price of 115. The server 108 computes:
[0096] PriceVariance(P200, S7) = 115 − 110 = 5
[0097] This likewise indicates a five-unit cross-site price variation for Product P200.
[0098] For the third concept C, corresponding to Product P300 supplied by Supplier S8, only one certified site record exists, namely Site S1, with a price of 95. Because no second site price is available for comparison, the system computes:
[0099] PriceVariance(P300, S8) = 0
[00100] This indicates that no measurable cross-site variation can be established from the data.
[00101] The server 108 executes the semantic use case function only when the derived semantic concepts satisfy the closure condition (G″, M″) to generate one or more intent-aligned analytical result. The semantic use case function is defined as U = f(C, D), wherein the C is the ontology-anchored concepts, D is the derived semantic concepts, and f is a semantic evaluation function.
[00102] The semantic use case function corresponds to at least one of analytics, anomaly detection, compliance determination, decision intelligence, enterprise copilot execution, or retrieval-augmented reasoning.
[00103] In this example, the semantic use case function determines whether a meaningful cross-site price difference exists for the same product supplied by the same supplier. For example, corresponding to Product P100 supplied by Supplier S7, the function is executed using the verified metric PriceVariance = 5, as represented by: f(P100, S7, Sites, PriceVariance = 5). Because the price variance is greater than zero across multiple sites, the function returns the result Price Variation Detected. This indicates that Product P100 is priced differently across procurement locations.
[00104] Corresponding to Product P200 supplied by Supplier S7, the function is executed as: f(P200, S7, Sites, PriceVariance = 5). Since the verified variance is likewise greater than zero, the function again returns Price Variation Detected, indicating inconsistent pricing across sites for Product P200. For the third concept, corresponding to Product P300 supplied by Supplier S8, the function is executed as: f(P300, S8, Sites, PriceVariance = 0).
[00105] In another example, the server 108 performs anomaly detection to identify when those price variations become abnormal. For example, if a product’s price suddenly spikes far beyond its usual range, the server 108 flags it as an anomaly. This could indicate errors, fraud, or unexpected market behavior.
[00106] In another example, server 108 obtains outputs from analytics and anomaly detection, combined with compliance checks, to recommend decisions such as whether to adjust prices, block a transaction, or trigger an investigation.
[00107] The server 108 generates one or more intent-aligned analytical result after executing the semantic use case function. The semantic use case function is executed to enable a semantic computation over the ontology-anchored concepts and the verified and derived semantic concepts.
[00108] For example, for Product P100 supplied by Supplier S7, the semantic function returns a result indicating price variation detected. For Product P200 supplied by Supplier S7, the semantic function likewise returns that price variation is detected. For Product P300 supplied by Supplier S8, the semantic function returns No variation, since no comparable multi-site pricing exists. Because no measurable price difference exists, and only one comparable site record is available, the function returns No Variation.
[00109] The server 108 generates a response as a final certified analytical output based on the intent-aligned analytical result. The server 108 generates the response using the LLM 114. The response includes the data associated with the verified and derived semantic concepts.
[00110] The final certified analytical output is produced by the LLM 114 using only the validated analytical results associated with certified formal concepts, thereby ensuring that the response is grounded in trusted enterprise data and protected from hallucinated content.
[00111] In the present example, the generated price variation analysis identifies products supplied by the same supplier that exhibit different prices across procurement sites. The certified output indicates that Product P100, supplied by Supplier S7, is procured at Sites S1 and S2 at prices 100 and 105, respectively, resulting in a verified price variance of +5. The output further indicates that Product P200, also supplied by Supplier S7, is procured at Sites S1 and S2 at prices 110 and 115, respectively, likewise resulting in a verified price variance of +5.
[00112] The server 108 may additionally generate an explanatory interpretation layer. In one embodiment, the response states that Product P100 supplied by Supplier S7 shows a price difference of five units across sites, indicating inconsistent location-based pricing. The response further states that Product P200 supplied by Supplier S7 exhibits the same variance pattern, suggesting a recurring supplier pricing discrepancy across multiple products.
[00113] With respect to Product P300 supplied by Supplier S8, the server 108 determines that only one certified site price record is available. Because no multi-site comparison can be performed, the output indicates that no comparable site price variance exists for Product P300.
[00114] The server 108 detects a semantic event as a recurring event pattern, and automatically suppresses invalid knowledge paths in the domain ontology based on the recurring event pattern without retraining the LLM 114. The semantic event includes at least one of an FCA rejection or a hallucination detection, including a history of the semantic events. The semantic event includes at least one of human correction, policy violation, or prompt override.
[00115] The human correction may occur when a user, analyst, reviewer, subject matter expert, or authorized operator determines that a generated result, classification, recommendation, or analytical conclusion is inaccurate, incomplete, outdated, or contextually improper and supplies a corrective action. The corrective action may include modifying labels, replacing facts, confirming alternate entities, adjusting rankings, or approving corrected outputs. The human corrections may be logged as semantic events and folded into recurring event patterns for future suppression of invalid knowledge paths.
[00116] The policy violation may occur when a query, prompt, retrieval request, tool invocation, generated response, or workflow action conflicts with enterprise governance rules, privacy policies, regulatory constraints, sensitivity labels, or access-control restrictions. Examples include requests for restricted patient-linked data, attempts to access confidential supplier banking records, or prohibited cross-domain joins. Such violations may be recorded as semantic events and used to strengthen future enforcement behavior.
[00117] The prompt override may occur when an administrator, compliance officer, security authority, or other privileged user authorizes an exception to a default prompt contract, retrieval restriction, output limitation, or policy rule. The override may be temporary, scoped, logged, or conditioned on a privileged audit workflow. The prompt overrides may likewise be stored as the semantic events for governance traceability and adaptive control.
[00118] For example, in a healthcare copilot deployment, the LLM 114 may determine that a supplier is non-compliant, after which a compliance analyst reviews updated records and manually corrects the result. That correction is recorded as a human correction event. In another scenario, a user requests restricted patient-linked data, causing the server 108 to register a policy violation event. In a further scenario, a compliance administrator authorizes a privileged audit workflow to bypass a normal restriction, thereby generating a prompt override event.
[00119] The server 108 includes the raw enterprise dataset of the retrieved ontology-anchored concepts in the LLM response if the derived semantic concepts. The server 108 compiles the query into an executable prompt contract before invoking the LLM 114. The executable prompt contract includes machine-enforceable constraints for at least one of permitted entities, prohibited inferences, required citations, or confidence thresholds. The server 108 invokes the LLM 114 if the formal context satisfies the executable prompt contract, thereby preventing the generation of out-of-domain hallucinations.
[00120] The server 108 performs at least one of blocking execution of the query, rewriting the query to generate a modified prompt that complies with the prompt contract upon detecting a violation of the executable prompt contract.
[00121] The server 108 generates the response limited to permitted data or context and excluding the sensitive content by executing the query, upon detecting a violation of the executable prompt contract. The server 108 generates the response limited to permitted data by the LLM 114. For example, the server 108 executes a semantic security inspection layer configured to perform semantic governance, privacy enforcement, and controlled data egress checks. The semantic security inspection layer evaluates the query output, formal context, derived semantic concepts, and any data selected for response generation to ensure that sensitive enterprise information is not improperly disclosed.
[00122] The server 108 performs PII and sensitive attribute classification using ontology-defined sensitivity labels and enterprise policy rules. In the example, the field buyer_email is classified as personally identifiable information (PII), and the field supplier_bank_account is classified as financial-sensitive data. Based on the applicable enforcement policies, the server 108 automatically redacts the buyer_email field from any generated output and blocks disclosure of the supplier_bank_account field entirely.
[00123] The server 108 then performs a broader policy enforcement validation before permitting response generation. In one embodiment, the server 108 verifies whether the retrieved data and computed concepts remain within the approved ontology boundaries, resulting in an Ontology Compliance with a PASS determination. The server 108 further verifies that the analytics were produced only from certified formal concepts satisfying the FCA closure condition, resulting in FCA Certification, which is PASS. The server 108 additionally confirms that the generated prompt and response constraints comply with the executable prompt contract, resulting in the prompt contract being PASS.
[00124] The server 108 executes a security layer that performs leakage analysis to determine whether any prohibited sensitive information is present in the pending response. In the example, attempted exposure of protected financial information triggers Sensitive Data Leakage, which is BLOCKED. As a result, the restricted fields are removed or suppressed before the response is returned.
[00125] The server 108 includes the data from the raw enterprise dataset associated with the retrieved ontology-anchored concepts in the context provided to the LLM 114, or in the LLM response, only when the derived semantic concepts belong to the certified formal concept satisfying the closure-consistent extent and intent.
[00126] FIG. 2 is a block diagram that illustrates a server 108, according to some embodiments herein. The server 108 includes a database 200, a query receiving module 202, a boundary determining module 204, ontology-anchored concepts retrieving module 206, a derived semantic concept constructing module 208, a raw enterprise dataset retrieving module 210, a mapping module 212, Formal Concept Analysis (FCA) module 214, a semantic use case function executing module 216, and a Large Language model (LLM) 114.
[00127] The query receiving module 202 receives a query from a user device associated with a user. For example, “Find products supplied by Supplier S1 across sites, with price differences and contract compliance”
[00128] The boundaries determining module 204 determines, based on a semantic retrieval contract, boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens. The domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes. The boundaries comprise a target entity, permissible paths, or forbidden regions.
[00129] The ontology-anchored concepts retrieving module 206 retrieves, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology. The retrieved ontology-anchored concepts are organized into a Formal Concept Analysis (FCA)-based lattice structure that progressively refines the retrieved concepts from general to specific as additional constraints corresponding to the semantic filters, the permissible paths, and the forbidden regions are applied.
[00130] The ontology-anchored concepts retrieving module 206 arranges the formal context into a concept lattice. The top concept corresponds to all ontology-anchored concepts satisfying baseline admissibility constraints, including target matching, permissible path inclusion, exclusion from forbidden regions, and sensitivity compliance. The intermediate concepts correspond to progressively constrained ontology-anchored concepts including entity-specific and relationship-specific combinations. The bottom concept corresponds to a maximally specific ontology-anchored concept satisfying all admissibility constraints and containing all required entities and attributes relevant to the user query. The lattice structure enables systematic narrowing of candidate ontology-anchored concepts by intersecting attribute sets (intent) and corresponding object sets (extent), thereby ensuring that only semantically valid and contextually relevant concepts are propagated to downstream modules. The lattice structure enables progressive refinement of ontology-anchored concepts, such that retrieved concepts become increasingly specific as additional constraints corresponding to semantic filters, permissible paths, and forbidden regions are applied.
[00131] In an example embodiment, the domain ontology corresponds to a procurement domain including entities such as Product, Supplier, Site, Contract, PriceRecord, and RiskSignal.
[00132] The derived semantic concept constructing module 208 constructs a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics. The ontology-anchored concepts retrieving module 206 is configured to receive as input: (i) the user query, (ii) the target entity, (iii) the permissible paths, (iv) the forbidden regions, and (v) one or more semantic filters, and to retrieve only the ontology-anchored concepts that are semantically admissible with respect to the inputs. The derived semantic concept-constructing module 208 constructs derived semantic concepts based on one or more nodes of the concept lattice, including one or more maximally specific concepts corresponding to closure-consistent formal concepts that satisfy A = A″.
[00133] The raw enterprise dataset retrieving module 210 retrieves a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources and maps the raw enterprise dataset into semantic objects/formal concept objects (G) represented as tuples of the ontology-anchored attributes. The raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts.
[00134] The mapping module 212 maps the retrieved ontology-anchored concepts and the derived semantic concepts into a formal context. The formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes.
[00135] In the example embodiment, the objects (G) comprise:
g1 = Product
g2 = Supplier
g3 = Product–Supplier
g4 = Product–Supplier–Site
g5 = Product–Supplier–Site–PriceRecord
g6 = Supplier–Contract
g7 = Supplier–RiskSignal
g8 = Product–Supplier–Site–PriceRecord–Contract
[00136] The attributes (M) comprise:
m1 = matches target entity
m2 = lies on a permissible ontology path
m3 = outside forbidden regions
m4 = passes sensitivity filter
m5 = contains Product
m6 = contains Supplier
m7 = contains Site
m8 = contains PriceRecord
m9 = contains Contract
m10 = suitable for a certified LLM context
[00137] Table 2: illustrates that the between the semantic objects and the ontology-defined attributes
Table:2
Object m1 target match m2 permissible path m3 outside forbidden m4 sensitivity pass m5 Product m6 Supplier m7 Site m8 Price m9 Contract m10 LLM-certified
g1 Product ✓ ✓ ✓ ✓ ✓
g2 Supplier ✓ ✓ ✓ ✓ ✓
g3 Product–Supplier ✓ ✓ ✓ ✓ ✓ ✓
g4 Product–Supplier–Site ✓ ✓ ✓ ✓ ✓ ✓ ✓
g5 Product–Supplier–Site–PriceRecord ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
g6 Supplier–Contract ✓ ✓ ✓ ✓ ✓ ✓ ✓
g7 Supplier–RiskSignal ✓ ✓ ✓ ✓ ✓ ✓
g8 Product–Supplier–Site–PriceRecord–Contract ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

[00138] In the table 2, each object gi is associated with attributes m1–m4 indicating admissibility, and additional attributes corresponding to entity inclusion and LLM suitability, such that: g1 and g2 correspond to base entity concepts, g3–g5 correspond to progressively enriched relational concepts, g6–g7 correspond to alternative supplier-linked concepts an g8 corresponds to a fully compositional concept including Product, Supplier, Site, PriceRecord, and Contract, and is suitable for certified LLM usage.
[00139] The formal context generates a concept lattice comprising a plurality of hierarchical levels, wherein each level represents progressively refined formal concepts characterized by corresponding intents and extents. At a highest level (Level 0), a top concept is defined by an intent including attributes {m1, m2, m3, m4} and an extent including objects {g1, g2, g3, g4, g5, g6, g7, g8}, thereby representing all ontology-anchored concepts that satisfy baseline admissibility constraints including target entity matching, permissible path inclusion, exclusion from forbidden regions, and sensitivity compliance.
[00140] At a next level (Level 1), entity-specific concepts are formed by augmenting the intent with entity-indicative attributes. A product-focused concept is defined by an intent {m1–m5} and an extent {g1, g3, g4, g5, g8}, representing ontology-anchored concepts involving a Product entity. A supplier-focused concept is defined by an intent {m1–m4, m6} and an extent {g2, g3, g4, g5, g6, g7, g8}, representing ontology-anchored concepts involving a Supplier entity.
[00141] At a subsequent level (Level 2), relationship-specific concepts are formed by combining entity attributes. A Product–Supplier concept is defined by an intent {m1–m6} and an extent {g3, g4, g5, g8}, representing ontology-anchored concepts involving Product–Supplier relationships. A Supplier–Contract concept is defined by an intent {m1–m4, m6, m9} and an extent {g6, g8}, representing ontology-anchored concepts involving Supplier–Contract relationships.
[00142] At a further level (Level 3), context-enriched concepts are generated by incorporating additional relational attributes. A Product–Supplier–Site concept is defined by an intent {m1–m7} and an extent {g4, g5, g8}. A product–supplier-site–PriceRecord concept suitable for a certified LLM context is defined by an intent {m1–m8, m10} and an extent {g5, g8}, thereby representing ontology-anchored concepts enriched with pricing data and validated for downstream language model processing.
[00143] At a lowest level (Level 4), a bottom concept is defined by an intent {m1–m10} and an extent {g8}, representing a maximally specific ontology-anchored concept that satisfies all admissibility constraints and includes Product, Supplier, Site, PriceRecord, and Contract attributes, and is suitable for certified LLM usage. This bottom concept corresponds to a fully constrained, semantically admissible, and context-complete representation derived from the formal context.
[00144] The lattice enables semantic pruning, retrieval admissibility determination, and preparation of certified formal concepts for downstream formal-context validation and LLM invocation. The retrieved ontology-anchored concepts are organized into a Formal Concept Analysis (FCA)-based lattice structure that progressively refines the retrieved concepts from general to specific as additional constraints corresponding to the semantic filters, permissible paths, and forbidden regions are applied. The semantic filters include (i) ontology path filters restricting traversal to permissible relationships, (ii) sensitivity filters excluding attributes labelled as restricted, and (iii) temporal filters restricting data to a specified time window.
[00145] The Formal Concept Analysis (FCA) module 214 verifies derived semantic concepts by performing a formal concept closure operation using closure operators (·′, ·″) on the formal context (G, M, I) to determine a closure-consistent extent (G″) and intent (M″) and verifying the derived semantic concepts correspond to the closure-consistent extent and intent.
[00146] The semantic use case function executing module 216 executes the semantic use case function only when the derived semantic concepts satisfy the closure condition (G″, M″) to generate one or more intent-aligned analytical results. The semantic use case function is executed to enable a semantic computation over the ontology-anchored concepts and the verified and derived semantic concepts.
[00147] The Large Language model (LLM) 114 generates a response as a final certified analytical output based on the intent-aligned analytical results. The response comprises the data associated with the verified and derived semantic concepts. The semantic use case function executing module 216 operates on the extent and intent of verified lattice-derived concepts, and the LLM 114 generates the response based only on data associated with the verified and derived semantic concepts corresponding to closure-consistent formal concepts satisfying A = A″ in the concept lattice.
[00148] FIG. 3 illustrates a concept lattice 300 generated by the ontology-anchored concepts retrieving module 206 using a Formal Concept Analysis (FCA)-based formal context, according to some embodiments herein. The concept lattice 300 represents a hierarchical arrangement of ontology-anchored concepts based on progressive refinement of semantic attributes associated with a user query.
[00149] The concept lattice 300 includes a plurality of nodes C0–C7, each corresponding to a formal concept defined by an intent and an extent. The intent comprises a set of shared attributes, and the extent comprises a set of ontology-anchored concepts (objects) sharing the attributes.
[00150] A top node C0 is positioned at an uppermost level of the concept lattice 300 and represents a baseline admissibility concept. The node C0 is associated with an intent including attributes corresponding to target entity matching, permissible path inclusion, exclusion from forbidden regions, and satisfaction of one or more semantic filters, and an extent including all candidate ontology-anchored concepts retrieved from the domain ontology.
[00151] The top node C0 is connected to a plurality of Level 1 nodes, including a Product-focused node C1 and a Supplier-focused node C2. The node C1 represents ontology-anchored concepts, including a Product entity, and the node C2 represents ontology-anchored concepts, including a Supplier entity. Each of the nodes C1 and C2 includes an intent augmented with corresponding entity-specific attributes and an extent reduced relative to the node C0.
[00152] The nodes C1 and C2 converge to a Level 2 node C3 representing a Product–Supplier relationship concept. The node C3 includes an intent comprising attributes corresponding to both Product and Supplier entities and an extent including ontology-anchored concepts that jointly satisfy both attributes.
[00153] The node C3 is connected to a plurality of Level 3 nodes including a node C5 corresponding to a Product–Supplier–Site concept and a node C4 corresponding to a Supplier–Contract concept. The node C5 includes an intent further comprising a Site attribute, and the node C4 includes an intent further comprising a Contract attribute. The node C4 is additionally connected to the node C2, indicating derivation from Supplier-related concepts.
[00154] The node C5 is further connected to a Level 3 node C6 representing a Product–Supplier–Site–PriceRecord concept that is suitable for certified Large Language Model (LLM) processing. The node C6 includes an intent further comprising a PriceRecord attribute and an LLM certification attribute, and an extent including ontology-anchored concepts satisfying such attributes.
[00155] A bottom node C7 is positioned at a lowermost level of the concept lattice 300 and is connected to both the node C6 and the node C4. The node C7 represents a maximally specific ontology-anchored concept and includes an intent comprising all admissibility attributes, including Product, Supplier, Site, PriceRecord, Contract, and LLM certification attributes, and an extent including a minimal set of ontology-anchored concepts satisfying all constraints.
[00156] The concept lattice 300 illustrates progressive refinement of ontology-anchored concepts, wherein traversal from the top node C0 to the bottom node C7 corresponds to incremental addition of attributes to the intent and corresponding reduction of objects in the extent. The concept lattice 300 enables identification of semantically admissible and maximally specific ontology-anchored concepts for downstream processing, including derived semantic concept construction and verification.
[00157] FIGS. 4A-4B are flow diagrams that illustrate a method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, according to some embodiments herein. At step 402, the method includes receiving, by a server, a query from a user device associated with a user. At step 404, the method includes determining, based on a semantic retrieval contract, boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens, wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions.
[00158] At step 406, the method includes retrieving, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology.
[00159] At step 408, the method includes constructing a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics.
[00160] At step 410, the method includes retrieving a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources and mapping the raw enterprise dataset into semantic objects/formal concept objects (G) represented as tuples of the ontology-anchored attributes, wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts.
[00161] At step 412, the method includes mapping the retrieved ontology-anchored concepts and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes.
[00162] At step 414, the method includes verifying, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by: performing a formal concept closure operation using closure operators on the formal context (G, M, I) to determine a closure-consistent extent (G″) and intent (M″), by performing a formal concept closure operation using closure operators on the formal context (G, M, I) to determine a closure-consistent extent (G″) and intent (M″); and verifying that the derived semantic concepts correspond to the closure-consistent extent and intent.
[00163] At step 416, the method includes performing at least one remediation operation before providing the contextual data to the LLM when the derived semantic concepts do not satisfy the closure condition (G″, M″). The remediation operation comprises at least one of pruning a semantically inadmissible portion of the formal context, partitioning the formal context into separately certifiable context groups, or rejecting the formal context prior to invoking the LLM.
[00164] At step 418, the method includes compiling the query into an executable prompt contract comprising machine-enforceable constraints for at least one of permitted entities, prohibited inferences, required citations, or confidence thresholds before invoking the LLM when the derived semantic concepts satisfy the closure condition (G″, M″), to generate one or more intent-aligned analytical results.
[00165] At step 420, the method includes executing the semantic use case function only when the derived semantic concepts satisfy the closure condition (G″, M″) to generate one or more intent-aligned analytical results.
[00166] At step 422, the method includes generating, using a large language model (LLM), a response as a final certified analytical output based on the intent-aligned analytical results. The response comprises the data associated with the verified and derived semantic concepts.
[00167] A representative hardware environment for practicing the embodiments herein is depicted in FIG. 5, with reference to FIGS. 1 through 4A and 4B. This schematic drawing illustrates a hardware configuration of a computer system/server 108 in accordance with the embodiments herein. The computer includes at least one processing device 10 and a cryptographic processor 11. The special-purpose CPU 10 and the cryptographic processor (CP) 11 may be interconnected via system bus 14 to various devices such as a random-access memory (RAM) 15, read-only memory (ROM) 16, and an input/output (I/O) adapter 17. The I/O adapter 17 can connect to peripheral devices, such as disk units 12 and tape drives 13, or other program storage devices that are readable by the system. The computer can read the inventive instructions on the program storage devices and follow these instructions to execute the methodology of the embodiments herein. The system further includes a user interface adapter 20 that connects a keyboard 18, mouse 19, speaker 25, microphone 23, and/or other user interface devices, such as a touch screen device (not shown) to the bus 14 to gather user input. Additionally, a communication adapter 21 connects the bus 14 to a data processing network 26, and a display adapter 22 connects the bus 14 to a display device 24, which provides a graphical user interface (GUI) 30 of the output data in accordance with the embodiments herein, or which may be embodied as an output device such as a monitor, printer, or transmitter, for example. Further, a transceiver 27, a signal comparator 28, and a signal converter 29 may be connected with the bus 14 for processing, transmission, receipt, comparison, and conversion of electric or electronic signals.
[00168] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope.  
, Claims:I/WE CLAIM:
1. A processor-implemented method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, comprising:
receiving, by a server, a query from a user device (104) associated with a user (102);
determining, based on a semantic retrieval contract (118), boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens (116), wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions;
retrieving, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology;
constructing a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics;
retrieving a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources (120) and mapping the raw enterprise dataset into semantic objects represented as tuples of the ontology-anchored attributes, wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts;
mapping the retrieved ontology-anchored concepts, and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes;
verifying, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by:
performing a formal concept closure operation using closure operators on the formal context to determine a closure-consistent extent and intent; and
verifying the derived semantic concepts correspond to the closure-consistent extent and intent;
executing a semantic use case function only when the derived semantic concepts satisfy a closure condition of the closure-consistent extent and intent to generate an intent-aligned analytical result; and
generating, using a large language model (LLM) (114), a response as a final certified analytical output based on the intent-aligned analytical result, wherein the response comprises the data associated with the verified and derived semantic concepts.

2. The method as claimed in claim 1, wherein the method comprises applying a semantic data folding technique to the retrieved ontology-anchored concepts and the derived semantic concepts to transform high-dimensionality semantic representations into compact folded forms that preserve structural invariants and reduce computational complexity, wherein the folded forms are reversibly unfoldable to restore original semantic meaning without loss, wherein the computable semantic metrics represent at least one of an entity concept, an attribute concept, a relationship concept, or a metric concept.

3. The method as claimed in claim 1, wherein the method comprises performing semantic data exfiltration control mediated by at least one of Application Programming Interfaces (APIs), external servers, or agent-to-agent communication protocols before constructing the formal context, by:
intercepting at least one of the retrieved ontology-anchored concepts, the derived semantic concepts, the query, or a tool invocation;
performing semantic inspection of the intercepted data against ontology-defined sensitivity labels, the extracted user intent, and enterprise policy constraints;
executing an enforcement action comprising at least one of allowing execution, redacting sensitive content, requiring user confirmation, or blocking execution and logging an event if a violation is detected; and
generating an audit-grade semantic trace associated with the enforcement action to provide a certifiable record of AI governance for every enforcement action, and to provide a certifiable record of semantic data-egress control.

4. The method of claim 1, wherein the formal context is certified only if the closure-consistent extent and intent of a folded representation is equivalent to the closure-consistent extent and intent of its corresponding unfolded representation, ensuring semantic integrity across computational states.

5. The method of claim 1, wherein the method comprises compiling the query into an executable prompt contract comprising machine-enforceable constraints for at least one of permitted entities, prohibited inferences, required citations, or confidence thresholds before invoking the LLM (114), wherein the LLM (114) is invoked only if the formal context satisfies the executable prompt contract, thereby preventing the generation of out-of-domain hallucinations.

6. The method of claim 1, wherein the method comprises intercepting at least one of the query, the formal context, or the formal concept closure, and performing a semantic inspection against ontology-defined sensitivity labels to determine an enforcement action comprising at least one of redacting sensitive content or blocking execution.

7. The method of claim 1, wherein the method comprises detecting a semantic event comprising at least one of an FCA rejection or a hallucination detection, folding a history of said semantic events into a recurring event pattern, and automatically suppressing invalid knowledge paths in the domain ontology based on the recurring event pattern without retraining the LLM (114).

8. The method of claim 1, wherein the one or more semantic filters are applied to the domain ontology prior to performing a retrieval technique, wherein the one or more semantic filters prune candidate fragments to ensure only semantically admissible data is ranked for retrieval.

9. The method of claim 1, wherein the semantic use case function is defined as U = f (C, D), wherein the C is the ontology-anchored concepts, D is the derived semantic concepts, and f is a semantic evaluation function.

10. The method of claim 1, further comprising generating the semantic retrieval contract (118) that comprises permissible entities, permissible relationships between the entities, traversal depth for query expansion, and sensitivity constraints for retrieval, and controlling retrieval candidate generation according to the semantic retrieval contract (118).

11. The method of claim 1, wherein, when the formal context fails to satisfy the closure-consistent extent and intent, the method performs at least one remediation operation before providing the contextual data to the LLM (114), the remediation operation comprising:
at least one of pruning a semantically inadmissible portion of the formal context, partitioning the formal context into separately certifiable context groups, or rejecting the formal context prior to invoking the LLM (114).

12. The method of claim 5, wherein, upon detecting a violation of the executable prompt contract, the method performs at least one of blocking execution of the query, rewriting the query or prompt to generate a modified prompt that complies with the prompt contract, or generating, by the LLM (114), the response limited to permitted data or context and excluding the sensitive content by executing the query.

13. The method of claim 7, wherein the semantic event comprises at least one of human correction, policy violation, or prompt override.

14. The method of claim 9, wherein the semantic use case function corresponds to at least one of analytics, anomaly detection, compliance determination, decision intelligence, enterprise copilot execution, or retrieval-augmented reasoning.

15. The method of claim 1, wherein the data from the raw enterprise dataset associated with the retrieved ontology-anchored concepts is included in a context provided to the LLM (114), or in the LLM response, only when the derived semantic concepts belong to the certified formal concept satisfying the closure-consistent extent and intent.

16. The method as claimed in claim 1, wherein the method comprises verification of semantic consistency, which is performed using a constraint-based validation model comprising at least one of a graph-based reasoning, a rule-based validation, or a probabilistic constraint satisfaction.

17. The method as claimed in claim 1, wherein the formal context is stored in an append-only semantic event store to maintain auditability and traceability.

18. A system (100) for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, comprising:
a server (108) that receives a query from a user device (104) associated with a user (102), wherein the server (108) comprises:
a memory (110) that comprises a set of instructions;
a processor (112) is configured to execute the set of instructions and is configured to:
determine, based on a semantic retrieval contract (118), boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens (116), wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions;
retrieve, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology;
construct a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics;
retrieve a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources (120) and map the raw enterprise dataset into semantic objects represented as tuples of the ontology-anchored attributes, wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts;
map the retrieved ontology-anchored concepts, and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes;
verify, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by:
performing a formal concept closure operation using closure operators on the formal context to determine a closure-consistent extent and intent; and
verifying the derived semantic concepts correspond to the closure-consistent extent and intent;
execute a semantic use case function only when the derived semantic concepts satisfy a closure condition of the closure-consistent extent and intent to generate an intent-aligned analytical result; and
generate, using a large language model (LLM) (114), a response as a final certified analytical output based on the intent-aligned analytical result, wherein the response comprises the data associated with the verified and derived semantic concepts.

19. The system (100) as claimed in claim 18, wherein the formal context is certified only if the closure-consistent extent and intent of a folded representation is equivalent to the closure-consistent extent and intent of its corresponding unfolded representation, ensuring semantic integrity across computational states.

20. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method for generating a contextually validated response by reducing entity-attribute hallucinations through formal concept certification of retrieved data, comprising:
receiving, by a server, a query from a user device (104) associated with a user (102);
determining, based on a semantic retrieval contract (118), boundaries by determining and mapping an intent of the user query to a domain ontology through an ontology lens (116), wherein the domain ontology defines a plurality of entities, attributes, semantic constraints, and valid relationships between the entities and the attributes, wherein the boundaries comprise a target entity, permissible paths, or forbidden regions;
retrieving, based on the target entity, one or more ontology-anchored concepts by applying one or more semantic filters to the domain ontology in accordance with the permissible paths and excluding the forbidden regions, thereby reducing hallucinations by limiting retrieval to the entities, the attributes, and the relationships defined within the domain ontology;
constructing a plurality of derived semantic concepts by combining the entities and the attributes associated with the retrieved ontology-anchored concepts into computable semantic metrics;
retrieving a raw enterprise dataset associated with the ontology-anchored concepts from a plurality of external data sources (120) and mapping the raw enterprise dataset into semantic objects represented as tuples of the ontology-anchored attributes wherein the raw enterprise dataset comprises data assigned to ontology-anchored entities and ontology-anchored attributes in the ontology-anchored concepts;
mapping the retrieved ontology-anchored concepts, and the derived semantic concepts into a formal context, wherein the formal context comprises the semantic objects, the ontology-defined attributes, and an incidence relation between the semantic objects and the ontology-defined attributes;
verifying, using a Formal Concept Analysis (FCA) method, the derived semantic concepts by:
performing a formal concept closure operation using closure operators on the formal context to determine a closure-consistent extent and intent; and
verifying the derived semantic concepts correspond to the closure-consistent extent and intent;
executing a semantic use case function only when the derived semantic concepts satisfy a closure condition of the closure-consistent extent and intent to generate an intent-aligned analytical result; and
generating, using a large language model (LLM) (114), a response as a final certified analytical output based on the intent-aligned analytical result, wherein the response comprises the data associated with the verified and derived semantic concepts.

Dated this 13th May 2026

Arjun Karthik Bala
(IN/PA 1021)
Agent for Applicant