User visible evidence closure admission method, system, device, and readable storage medium

Abstract

The application discloses a user-visible evidence closed-loop access method, system, device and readable storage medium, relates to the field of artificial intelligence and data science, and specifically comprises the following steps: determining a first evidence package and a corresponding first evidence identifier based on an original output result; receiving an adoption request sent by an intelligent agent, wherein the adoption request comprises a target evidence identifier corresponding to a target evidence; calling a target evidence package according to the target evidence identifier and generating a calling result, wherein the target evidence package comprises normalized data, a target hash value and target source information; calling an adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier and the calling result to obtain a verification result; and based on the verification result, confirming whether to add the target evidence identifier to a rendering white list of a current session, so as to realize user-visible evidence closed-loop access. The application ensures that evidence components displayed on a user interface are strictly derived from traceable and verified candidate evidences.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and data science, specifically to a user-visible evidence closed-loop access method, system, device, and readable storage medium. Background Technology

[0002] With the development of artificial intelligence technology, large language models are being used more and more widely in the field of enterprise data analysis. Business users hope to use natural language interaction to allow data analysis agents to automatically call query tools, analysis functions, or code execution tools to complete data acquisition, analysis, and result display. Especially in scenarios such as manufacturing, mold making, equipment maintenance, quality management, and supply chain management, such systems can effectively reduce the technical threshold for users to access complex databases and improve decision-making efficiency.

[0003] In related technologies, data analysis agents typically receive natural language requests from users, parse the intent, call the corresponding data tools to perform queries or calculations, obtain the execution results, and then a large language model generates a natural language response based on the execution results. The data is then directly embedded into the response content in the form of Markdown (Lightweight Markup Syntax) tables, charts, JSON configurations, or text summaries, and finally rendered and displayed through the user interface.

[0004] However, in the existing multi-tool data analysis chain, there is a lack of mandatory access verification mechanism between the actual execution results of the data tools, the final answer generated by the agent, and the evidence components in the user interface. This allows unverified data to directly enter the evidence components in the user interface, making it impossible to guarantee that the visual evidence ultimately seen by the user comes from traceable candidate evidence that cannot be arbitrarily rewritten by the agent. This presents technical problems such as difficulty in ensuring data consistency and difficulty in tracing the source.

[0005] Therefore, how to provide a closed-loop admission method for user-visible evidence to ensure that the evidence components displayed in the user interface are strictly derived from traceable and verified candidate evidence is an urgent problem to be solved. Summary of the Invention

[0006] This application provides a user-visible evidence closed-loop admission method, system, device, and readable storage medium that can ensure that the evidence components displayed on the user interface are strictly derived from traceable and verified candidate evidence.

[0007] In a first aspect, embodiments of this application provide a user-visible evidence closed-loop access method, including: The first evidence package and its corresponding first evidence identifier are determined based on the original output results, wherein the original output results are generated by the data analysis tool invoked by the user; The agent receives an acceptance request, which is generated when the agent determines to show the target evidence to the user. The acceptance request includes a target evidence identifier corresponding to the target evidence. The target evidence package is retrieved based on the target evidence identifier, and a retrieval result is generated. The target evidence package includes normalized data, target hash value, and target source information. The acceptance verifier is invoked to verify the target evidence identifier in the acceptance request based on the first evidence package, the first evidence identifier, and the retrieval result, and the verification result is obtained. Based on the verification results, determine whether to add the target evidence identifier to the rendering whitelist of the current session in order to achieve closed-loop access control for user-visible evidence.

[0008] In conjunction with the first aspect, in one implementation, determining the first evidence package and its corresponding first evidence identifier based on the original output results includes: Based on the original output results, determine the first source information, normalized data, and their basic hash values ​​respectively; The standardized data, basic hash value, and first source information are used as the first evidence package, and a first evidence identifier corresponding to the first evidence package is generated.

[0009] In conjunction with the first aspect, in one implementation, the call to the acceptance verifier verifies the target evidence identifier in the acceptance request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain a verification result, including: Determine whether the target evidence package exists in the retrieved results, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the base hash value. If so, the verification result is determined to be successful; If not, the verification result is determined to be verification failure.

[0010] In conjunction with the first aspect, in one implementation, the step of confirming whether to add the target evidence identifier to the rendering whitelist of the current session based on the verification result includes: If the verification result is successful, the target evidence identifier will be added to the rendering whitelist of the current session. If the verification result is a verification failure, the request will be rejected and the target evidence identifier will not be added to the rendering whitelist.

[0011] In conjunction with the first aspect, in one embodiment, the method further includes: Extract the target evidence identifier from the agent's response text and determine whether the target evidence identifier exists in the rendering whitelist; If so, then normalized data is obtained from the target evidence package based on the target evidence identifier for rendering; If not, then the presentation of evidence based on data embedded in the response text is prohibited.

[0012] Secondly, embodiments of this application provide a user-visible evidence closed-loop access system, the user-visible evidence closed-loop access system comprising: The first processing module is used to determine the first evidence package and its corresponding first evidence identifier based on the original output result, wherein the original output result is generated by the data analysis tool invoked by the user; The second processing module is used to receive an adoption request sent by the intelligent agent. The adoption request is generated when the intelligent agent determines to show the target evidence to the user. The adoption request includes a target evidence identifier corresponding to the target evidence. The third processing module is used to retrieve the target evidence package based on the target evidence identifier and generate the retrieval result. The target evidence package includes normalized data, target hash value and target source information. The fourth processing module is used to call the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain the verification result; The fifth processing module is used to determine whether to add the target evidence identifier to the rendering whitelist of the current session based on the verification results, so as to achieve closed-loop access control for user-visible evidence.

[0013] In conjunction with the second aspect, in one implementation, the first processing module is specifically used for: Based on the original output results, determine the first source information, normalized data, and their basic hash values ​​respectively; The standardized data, basic hash value, and first source information are used as the first evidence package, and a first evidence identifier corresponding to the first evidence package is generated.

[0014] In conjunction with the second aspect, in one implementation, the fourth processing module is specifically used for: Determine whether the target evidence package exists in the retrieved results, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the base hash value. If so, the verification result is determined to be successful; If not, the verification result is determined to be verification failure.

[0015] Thirdly, embodiments of this application provide a user-visible evidence closed-loop access device, the user-visible evidence closed-loop access device including a processor, a memory, and a user-visible evidence closed-loop access program stored in the memory and executable by the processor, wherein when the user-visible evidence closed-loop access program is executed by the processor, it implements the steps of the user-visible evidence closed-loop access method as described in any of the preceding claims.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a user-visible evidence closed-loop admission procedure, wherein when the user-visible evidence closed-loop admission procedure is executed by a processor, it implements the steps of the user-visible evidence closed-loop admission method as described in any of the preceding claims.

[0017] The beneficial effects of the technical solutions provided in this application include: The system generates a first evidence package and a first evidence identifier from the original output results, and receives an adoption request from the agent containing only the target evidence identifier, cutting off the path for the agent to tamper with the data payload at the instruction transmission level. Then, it retrieves the target evidence package based on the target evidence identifier, generating a retrieval result to ensure that the rendered data originates from trusted storage solidified after tool execution, thus guaranteeing traceability. Subsequently, it calls the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result, obtaining a verification result and forcibly implementing pre-display access verification. Finally, based on the verification result, it adds the target evidence identifier to the rendering whitelist of the current session, restricting the user interface to only render trusted data within the whitelist. This achieves closed-loop access for user-visible evidence, ensuring that the evidence components displayed on the user interface strictly originate from traceable and verified candidate evidence, effectively solving the technical problems of difficulty in ensuring data consistency and tracing the source. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an embodiment of the user-visible evidence closed-loop access method in this application. Figure 2 A detailed flowchart illustrating the user-visible evidence closed-loop access method embodiment of this application; Figure 3 This is a schematic diagram of the functional modules of the user-visible evidence closed-loop access system embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of the user-visible evidence closed-loop access device involved in the embodiments of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0021] In a first aspect, embodiments of this application provide a user-visible evidence closed-loop access method.

[0022] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the user-visible evidence closed-loop admission method of this application. Figure 1 As shown, the user-visible evidence closed-loop admission method includes: Step S10: Determine the first evidence package and its corresponding first evidence identifier based on the original output results, wherein the original output results are generated by the data analysis tool invoked by the user.

[0023] As an example, in the embodiments of this application, the original output result refers to the data directly returned by the data analysis tool, such as the row records queried from the database, the print content of the code sandbox, or the API interface response. This data has not been processed by the intelligent agent and retains the most original authenticity. The first evidence package is a credible data unit formed by processing the original output result. The first evidence identifier is an index string uniquely bound to the evidence package, such as a UUID, which is used to reference the evidence package in subsequent processes without having to transmit the data itself.

[0024] Specifically, the original output is the direct product of tool execution. Compared with the natural language responses generated by the agent, it has the highest authenticity and credibility. By solidifying it into the first evidence package and generating the first evidence identifier, the separation of data content and display instructions can be achieved. This ensures that subsequent agents can only refer to the evidence through the identifier and cannot tamper with the data content. At the same time, it provides an immutable benchmark for the comparison and verification of the basic hash value. This solves the technical problems of difficulty in tracing the source of evidence and inconsistency in the displayed data in large model data analysis from the source, and ensures the homogeneity and reliability of the evidence displayed in the user interface.

[0025] Step S20: Receive an acceptance request sent by the agent. The acceptance request is generated when the agent determines to show the target evidence to the user. The acceptance request includes a target evidence identifier corresponding to the target evidence.

[0026] In this embodiment of the application, as an example, when a data analysis agent determines, based on inference logic, that specific data evidence needs to be presented to the user during the processing of a user's natural language request, it triggers the generation process of an adoption request. This adoption request is structurally represented as an "Adoption Request," indicating the agent's request to adopt candidate evidence. The agent sends this adoption request through a standardized interface provided by the system. The request content must include a target evidence identifier corresponding to the target evidence to be presented, and may also include an adoption reason to explain the business intent of presenting the evidence. It should be noted that the message structure of this adoption request is strictly limited to containing only index information and must not carry any new chart sequences, table rows, indicator value sets, or detailed samples, thereby ensuring that the agent can only initiate presentation instructions and cannot inject or tamper with data content during the request phase. After receiving the request, the system uses it as input for subsequent access verification, preparing to retrieve and verify the evidence package.

[0027] Step S30: Retrieve the target evidence package based on the target evidence identifier and generate a retrieval result. The target evidence package includes normalized data, target hash value, and target source information.

[0028] In this embodiment, as an example, normalized data refers to the data content after standardizing the original output results returned by the data analysis tool. The processing includes sorting data rows by primary key, standardizing field name formats, and removing redundant whitespace characters to ensure that data with the same semantics generates the same standardized string, providing a consistent benchmark for hash calculation. The target hash value refers to the digital fingerprint calculated based on the normalized data, usually generated using hash algorithms such as SHA-256, and is used to verify whether the data content has been tampered with, ensuring the integrity of the evidence package. The target source information refers to the metadata set describing the background of the target evidence package, used to achieve full-link traceability of the data. Its content covers dimensions such as tool identifier, execution instructions, session identifier, timestamp, and processing rules.

[0029] Specifically, the system first parses the target evidence identifier from the adoption request. This identifier serves as a query key, pointing to a specific storage location in the trusted storage module. Next, the system uses this target evidence identifier to retrieve the corresponding evidence package record from the database or object storage. If the retrieval is successful, the system reads the normalized data, target hash value, and target source information stored in the target evidence package, assembles this information into a retrieval result, and returns it to the adoption validator for subsequent verification. If the retrieval fails, a null retrieval result is generated, indicating that the target evidence package does not exist. This process ensures that the validator can obtain solidified evidence content that strictly corresponds to the request identifier, providing a data foundation for subsequent consistency verification.

[0030] Step S40: Call the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain the verification result.

[0031] In this exemplary embodiment, the first evidence package and the first evidence identifier represent the original credible state of the data captured and solidified by the system at the moment the tool is executed, serving as the baseline truth value for verification. The retrieval result reflects the actual persistence state of the target evidence package in the current storage system, while the target evidence identifier in the adoption request represents the display intent initiated by the agent. Specifically, by comparing the intent identifier in the request with the original identifier generated by the system and the storage state, it is possible to effectively identify whether the agent has requested non-existent evidence, whether the evidence identifier has been tampered with, and whether the integrity of the source information has been compromised. This verification step is a key control point for achieving closed-loop access control for user-visible evidence. It enforces pre-display access verification, ensuring that only evidence that has undergone source consistency confirmation can enter the rendering whitelist, thereby fundamentally preventing unverified data from entering the user interface and solving the technical problems of difficulty in evidence tracing and inconsistent displayed data in large model data analysis.

[0032] Step S50: Based on the verification results, confirm whether to add the target evidence identifier to the rendering whitelist of the current session to achieve closed-loop access for user-visible evidence.

[0033] In this exemplary embodiment, the verification result represents whether the evidence has passed rigorous scrutiny regarding its existence, completeness, consistency, and source. Only target evidence identifiers that pass the scrutiny are qualified to enter the display stage. If the identifier is added to the whitelist without considering the verification result, the access mechanism will be rendered ineffective, unable to intercept untrusted or tampered data, rendering the previous verification work meaningless. Specifically, adding the target evidence identifier to the rendering whitelist of the current session establishes a temporary, session-level trusted permission list in system memory. This list is the only bridge connecting backend verification and frontend rendering. The frontend interface is forced to respond only to requests for identifiers within the whitelist. That is, the frontend component must query the whitelist before rendering, and only identifiers that match the whitelist are allowed to trigger data retrieval and rendering actions. Data directly embedded in the agent's reply text is automatically ignored because it cannot pass the whitelist verification.

[0034] It should be understood that source data is generated and solidified by the tool, process data is verified for credibility by a verifier, access data is controlled by a whitelist, and terminal display is forcibly locked by the front end. Any unverified data cannot bypass the whitelist restrictions to enter the user's view, and any data outside the whitelist cannot be rendered by the front end. This mechanism ensures that the evidence components displayed in the user interface are strictly derived from traceable and verified candidate evidence, cutting off the path for large-scale model illusions or tampered data to directly enter the display layer, thereby achieving the same source and consistency guarantee of evidence display at the system architecture level.

[0035] This application generates a first evidence package and a first evidence identifier from the original output results, and receives an adoption request from an agent containing only the target evidence identifier, cutting off the path for the agent to tamper with the data payload at the instruction transmission level; then, it retrieves the target evidence package based on the target evidence identifier, generating a retrieval result to ensure that the rendered data originates from trusted storage solidified after tool execution, thus guaranteeing traceability; subsequently, it calls the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result, obtaining a verification result and forcibly implementing pre-display access verification; finally, based on the verification result, it adds the target evidence identifier to the rendering whitelist of the current session, restricting the user interface to only render trusted data within the whitelist, thereby achieving closed-loop access for user-visible evidence, ensuring that the evidence components displayed on the user interface strictly originate from traceable and verified candidate evidence, effectively solving the technical problems of difficulty in ensuring data consistency and difficulty in tracing the source.

[0036] Further, in one embodiment, determining the first evidence package and its corresponding first evidence identifier based on the original output result includes: Based on the original output results, determine the first source information, normalized data, and their basic hash values ​​respectively; The standardized data, basic hash value, and first source information are used as the first evidence package, and a first evidence identifier corresponding to the first evidence package is generated.

[0037] As an example, the system first performs result normalization on the original output. For instance, if the original result is a set of rows returned by a database query, the system will sort the rows in ascending order according to the primary key, uniformly lowercase the field key names, and remove all unnecessary whitespace characters to ensure that the same data content can generate a unique normalized string regardless of the order in which it is returned. Subsequently, the system calculates the basic hash value on the normalized data string. In this embodiment, the SHA-256 algorithm is preferably used to calculate the hash value, which will serve as a "digital fingerprint" for subsequent verification of data integrity.

[0038] It should be noted that the primary source information is metadata generated within the same tool execution context as the original output. Specifically, when the underlying system framework intercepts the original output returned by the data analysis tool, it synchronously captures the context information of that execution process as the primary source information to ensure a strict one-to-one correspondence between the source information and the original output. The primary source information specifically includes: (1) Tool identifier: For example, Tool_SQL_Production_01.

[0039] (2) Execution instruction: The actual SQL statement sent to the database, such as SELECT rate FROM quality_table WHERE date>'2023-01-01'.

[0040] (3) Session ID: The Session ID of the current user's interaction with the agent.

[0041] (4) Timestamp: The server system time when the tool finishes execution.

[0042] It should be understood that this information is automatically recorded by the underlying framework of the system, rather than generated by a large language model, in order to ensure the authenticity of the traceability information.

[0043] It should be noted that the system encapsulates the aforementioned normalized data, basic hash value, and primary source information into a JSON object, namely the primary evidence packet. The primary evidence packet is represented by an Evidence Packet in data structure, which is used to represent the data basis and candidate evidence set solidified after a tool execution. Its key fields include at least packet_id (primary evidence identifier), normalized_data (normalized data), basis_hash (basic hash value), and proofance (source information). Furthermore, the evidence packet may also include extended fields such as query_run_id (query run identifier), tool_type (tool type), analysis_summary (analysis summary), and evidence_candidates (candidate evidence set). Among them, basis_hash (basic hash value) is calculated from normalized_data (normalized data) after deterministic serialization, and proofance (source information) can record traceability information such as tool_type (tool type). Simultaneously, the system generates a globally unique first evidence identifier for the first evidence package (e.g., a string in UUID format, ev_550e8400-e29b...); finally, the system stores the first evidence package in a trusted storage module (such as Object Storage Service (OSS) or a tamper-proof database) and establishes an index relationship from the "first evidence identifier" to the "first evidence package" so that it can be quickly retrieved later using the identifier.

[0044] Furthermore, when a user continues to ask follow-up questions based on the previous round's answer, the system can reuse the evidence adopted in the previous round or generate a new derived first evidence package based on it. The derived first evidence package records at least one of the following: the identifier of the preceding evidence package, the preceding base hash value, the new query run identifier, the new base hash value, the derivation rule, and the derived base hash value. This mechanism is used to prevent the secondary extraction of evidence data from the previous round's natural language response text in multi-round dialogues, ensuring that each round's evidence package originates from the original output result of the tool execution.

[0045] It should be understood that, in cases where the original output result is empty or weak, the system can generate review suggestions. However, review suggestions must not change the original query facts, nor can they forcibly rewrite 0-row results into non-zero evidence. The review module reads the time field, filter field, object granularity, and relationship path in the query. The system queries the non-empty rate or coverage of candidate fields. At most, one high-priority review candidate is generated for the same empty result. Fields with a non-empty rate lower than a preset threshold cannot be used as high-priority candidates. Review suggestions are only used as the direction for the next query step and do not change the normalized data and basic hash value in the original first evidence package, ensuring the authenticity of the empty result evidence package.

[0046] For example, when the data analysis tool is a code sandbox tool, the system generates a Sandbox Evidence Manifest as normalized metadata in the process of generating the first evidence package for the raw output results produced by the code sandbox. This includes the sandbox run ID, code hash, runtime hash, input digest, interface exclusion ID (std out_excluded_from_ui), normalizer ID, and normalized result hash. The normalized result hash will serve as the base hash in the first evidence package, ensuring consistency in hash tracing. Setting the interface exclusion ID (std out_excluded_from_ui) to true explicitly specifies the standard output (std... (out) data must not be used as a data source for user evidence components and can only be used as internal analysis input for the agent. If the sandbox results need to be displayed to the user, the results normalization module must extract the structured results and generate candidate evidence to ensure that all data entering the first evidence package are normalized structured data that meet the requirements of the first evidence package for normalized data and basic hash values.

[0047] It should be understood that in industrial embodiments such as mold manufacturing, the system can use a business ontology to constrain the objects, fields, and relationships of the data tools. For example, it can define objects such as molds, product tasks, planned processes, executed processes, machines, work reports, corrective action orders, and quality inspection tasks. This ontology is used to help the tools generate more stable query and source fields, ensuring that the query objects and filtering conditions in the first source information have clear business semantics. However, the core of this application is still the closed-loop access of the user interface evidence component.

[0048] Further, in one embodiment, the invocation of the acceptance verifier verifies the target evidence identifier in the acceptance request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain a verification result, including: Determine whether the target evidence package exists in the retrieved results, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the base hash value. If so, the verification result is determined to be successful; If not, the verification result is determined to be verification failure.

[0049] As an example, in this embodiment, the verifier queries the trusted storage module based on the target evidence identifier in the adoption request. If no corresponding record is found in the database (i.e., the retrieval result is empty), the verifier determines that the target evidence package does not exist, and the verification fails. This prevents the agent from requesting a false evidence ID that has never been generated. Furthermore, the verifier reads the target source information in the retrieved target evidence package and compares it with the first source information standard. Specifically, it checks whether the target source information contains necessary fields (such as tool identifier, execution instructions, and timestamps). If any necessary field is empty or missing, the verifier determines that the target source information is incomplete relative to the first source information, and the verification fails. This ensures that the evidence is traceable.

[0050] It should be noted that the verifier compares the target evidence identifier in the acceptance request with the first evidence identifier stored in the evidence package. If the two strings are not completely identical, the first evidence identifier is determined to be inconsistent with the target evidence identifier, and the verification fails. This prevents ID spoofing or tampering. The verifier extracts normalized data from the target evidence package and recalculates the hash using the same algorithm (such as SHA-256) as when it was generated to obtain the first hash value. The recalculated hash value is compared with the base hash value stored in the first evidence package. If the two are inconsistent, it indicates that the stored data may have been tampered with, and the first hash value is determined to be inconsistent with the base hash value, and the verification fails. If all the above conditions are met (the target evidence package exists, the target source information is complete, the first evidence identifier is consistent with the target evidence identifier, and the first hash value is consistent with the base hash value), the verification result is considered successful.

[0051] It should be understood that after verification, the system can generate an Adoption Record to indicate that the verification result is successful. The Adoption Record is associated with the rendering whitelist or serves as persistent storage for the rendering whitelist. The user interface evidence component is configured to read evidence data based on the Adoption Record or the rendering whitelist. When the front-end renders the chart, it can only read data from the evidence package in the trusted storage module based on the Adoption Record or the whitelist. It cannot retrieve data from the Markdown table, chart JSON, number list, or code sandbox std out in the agent's final answer, thereby ensuring that the data source for front-end rendering is strictly bound to the verification result.

[0052] Furthermore, in one embodiment, the step of confirming whether to add the target evidence identifier to the rendering whitelist of the current session based on the verification result includes: If the verification result is successful, the target evidence identifier will be added to the rendering whitelist of the current session. If the verification result is a verification failure, the request will be rejected and the target evidence identifier will not be added to the rendering whitelist.

[0053] In this exemplary embodiment, if the verification result returned by the acceptance verifier is successful, the system performs an "admission" operation, appending the target evidence identifier in the acceptance request to the rendering whitelist of the current session. Simultaneously, the system sets the expiration time of the whitelist (e.g., consistent with the session timeout, such as 30 minutes) to ensure the security of temporary admission. If the verification result returned by the acceptance verifier is a verification failure, the system performs a "blocking" operation, rejecting the acceptance request and returning an error code (e.g., ERROR_EVIDENCE_INVALID) to the agent. The system does not add the target evidence identifier to the rendering whitelist. Furthermore, the system can record a security log, recording the failed evidence identifier, the reason for failure (e.g., hash inconsistency), and the request time for subsequent auditing. Since the target evidence identifier is not in the whitelist, the subsequent front-end rendering process will be unable to obtain the evidence data, thus physically blocking the display of untrusted evidence.

[0054] Furthermore, in one embodiment, the method further includes: Extract the target evidence identifier from the agent's response text and determine whether the target evidence identifier exists in the rendering whitelist; If so, then normalized data is obtained from the target evidence package based on the target evidence identifier for rendering; If not, then the presentation of evidence based on data embedded in the response text is prohibited.

[0055] As an example, in this embodiment, the front end (e.g., the user interface) receives the response text (typically Markdown or a specific JSON format) returned by the agent. The evidence display component parses the response text and extracts the target evidence identifier embedded therein (e.g., parsing specific tags). <evidence id="ev_123" / >The evidence display component calls the front-end interface to query the rendering whitelist of the current session and determine whether the extracted target evidence identifier exists in the rendering whitelist. If it does (exists in the whitelist), the component obtains standardized data from the target evidence package based on the target evidence identifier for rendering. Specifically, the component sends an API request to the backend trusted storage service (e.g., GET / api / evidence / ev_123). After the backend confirms that the ID is in the whitelist, it returns the data. The frontend uses the returned data to draw charts or tables. This process ensures that the data displayed by the frontend comes directly from trusted storage, rather than the text response of the intelligent agent.

[0056] It should be understood that if not (not on the whitelist), the component prohibits evidence display based on data embedded in the reply text. Specifically, even if the agent directly embeds complete JSON data or Markdown tables in the reply text, the evidence display component will ignore this content and not render any charts. For example, the interface may display a placeholder message indicating "Data source failed verification" or leave it blank. This mechanism forcibly cuts off the path for the agent to directly inject false data through text replies, ensuring "what you see is what you get (tool execution result)".

[0057] It should be noted that if a user inquires about "the distribution of work orders delayed by more than 3 days in the injection molding workshop in May 2025 and the reasons for the delays," the system first calls a structured query tool to execute the query. Based on the original output, it determines the first evidence packet and its corresponding first evidence identifier. After the tool returns the results, the system performs normalization processing such as sorting, field trimming, and format standardization to obtain normalized data. Then, based on the normalized results, it generates an analysis summary, candidate evidence for the delay reason distribution map, and candidate evidence for the delayed work order details table. It also calculates the basic hash value (basis_hash) on the normalized data and records source information such as tool type, execution time, query object, filtering conditions, aggregation rules, and time window. Subsequently, the system solidifies this content into a first evidence packet. If the agent wants to display the "delay reason distribution map" on the user interface, it cannot carry the chart data, table rows, or indicator values ​​itself, but can only generate an adoption request. This adoption request includes the target evidence identifier (e.g., evidence_id) and the adoption reason corresponding to the target evidence, and the adoption request does not contain the data content of the target evidence.

[0058] It should be understood that after receiving a request, the acceptance verifier retrieves the corresponding target evidence package based on the target evidence identifier and performs the verification steps: determining whether the target evidence package exists, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the basic hash value; only after the verification passes, the system adds the target evidence identifier to the rendering whitelist of the current session based on the verification result; the front-end interface extracts the target evidence identifier from the agent's reply text, determines whether it exists in the rendering whitelist, and if so, obtains standardized data from the target evidence package based on the target evidence identifier for rendering; otherwise, it prohibits the display of evidence based on the data content embedded in the reply text, thereby achieving closed-loop access for user-visible evidence.

[0059] It should be noted that, referring to Figure 2 As shown, in this embodiment, the system first receives a natural language question from a user, and the data analysis agent parses the intent and selects the corresponding data analysis tool. Then, the tool performs analysis and generates raw output results. Based on the raw output results, the system determines a first evidence package and its corresponding first evidence identifier. The first evidence package includes standardized data, a basic hash value, and source information, thus completing the solidification of the evidence. Subsequently, when the agent determines to display the target evidence to the user, it generates an adoption request. The adoption request includes the target evidence identifier corresponding to the target evidence and the adoption reason, but does not contain the data content of the target evidence. After receiving the adoption request, the system retrieves the corresponding target evidence package based on the target evidence identifier and calls the adoption verifier to verify the target evidence identifier based on the first evidence package, the first evidence identifier, and the retrieval result to obtain a verification result. The verification content includes whether the evidence package exists, whether the evidence identifier is consistent, whether the basic hash value is consistent, and whether the source information is complete.

[0060] It should be understood that if the verification result is a failure, the request will be rejected and the target evidence identifier will not be added to the rendering whitelist. It is explicitly prohibited to display evidence based on the agent's final answer text, temporary tables, chart data text, number lists, or sandbox printed text. If the verification result is a pass, the target evidence identifier will be added to the rendering whitelist of the current session or an acceptance record will be generated. Then, the user interface evidence component will read the corresponding normalized data from the trusted storage module according to the rendering whitelist or acceptance record for rendering, and finally display the natural language answer and trusted evidence. This achieves closed-loop access for user-visible evidence and ensures that the evidence components displayed in the user interface are strictly derived from traceable and verified candidate evidence.

[0061] Secondly, embodiments of this application also provide a user-visible evidence closed-loop access system.

[0062] In one embodiment, reference is made to Figure 3 , Figure 3This is a functional module diagram of an embodiment of the user-visible evidence closed-loop access control system of this application. Figure 3 As shown, the user-visible evidence closed-loop access control system includes: The first processing module is used to determine the first evidence package and its corresponding first evidence identifier based on the original output result, wherein the original output result is generated by the data analysis tool invoked by the user; The second processing module is used to receive an adoption request sent by the intelligent agent. The adoption request is generated when the intelligent agent determines to show the target evidence to the user. The adoption request includes a target evidence identifier corresponding to the target evidence. The third processing module is used to retrieve the target evidence package based on the target evidence identifier and generate the retrieval result. The target evidence package includes normalized data, target hash value and target source information. The fourth processing module is used to call the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain the verification result; The fifth processing module is used to determine whether to add the target evidence identifier to the rendering whitelist of the current session based on the verification results, so as to achieve closed-loop access control for user-visible evidence.

[0063] Furthermore, in one embodiment, the first processing module is specifically used for: Based on the original output results, determine the first source information, normalized data, and their basic hash values ​​respectively; The standardized data, basic hash value, and first source information are used as the first evidence package, and a first evidence identifier corresponding to the first evidence package is generated.

[0064] Furthermore, in one embodiment, the fourth processing module is specifically used for: Determine whether the target evidence package exists in the retrieved results, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the base hash value. If so, the verification result is determined to be successful; If not, the verification result is determined to be verification failure.

[0065] Furthermore, in one embodiment, the fifth processing module is specifically used for: If the verification result is successful, the target evidence identifier will be added to the rendering whitelist of the current session. If the verification result is a verification failure, the request will be rejected and the target evidence identifier will not be added to the rendering whitelist.

[0066] Furthermore, in one embodiment, the fifth processing module is specifically used for: Extract the target evidence identifier from the agent's response text and determine whether the target evidence identifier exists in the rendering whitelist; If so, then normalized data is obtained from the target evidence package based on the target evidence identifier for rendering; If not, then the presentation of evidence based on data embedded in the response text is prohibited.

[0067] This application generates a first evidence package and a first evidence identifier from the original output results, and receives an adoption request from an agent containing only the target evidence identifier, cutting off the path for the agent to tamper with the data payload at the instruction transmission level; then, it retrieves the target evidence package based on the target evidence identifier, generating a retrieval result to ensure that the rendered data originates from trusted storage solidified after tool execution, thus guaranteeing traceability; subsequently, it calls the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result, obtaining a verification result and forcibly implementing pre-display access verification; finally, based on the verification result, it adds the target evidence identifier to the rendering whitelist of the current session, restricting the user interface to only render trusted data within the whitelist, thereby achieving closed-loop access for user-visible evidence, ensuring that the evidence components displayed on the user interface strictly originate from traceable and verified candidate evidence, effectively solving the technical problems of difficulty in ensuring data consistency and difficulty in tracing the source.

[0068] The functions of each module in the aforementioned user-visible evidence closed-loop access system correspond to the steps in the aforementioned user-visible evidence closed-loop access method embodiment, and their functions and implementation processes will not be described in detail here.

[0069] Thirdly, embodiments of this application provide a user-visible evidence closed-loop access device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0070] Reference Figure 4 , Figure 4 This is a schematic diagram of the hardware structure of the user-visible evidence closed-loop access control device involved in the embodiments of this application. In this embodiment, the user-visible evidence closed-loop access control device may include a processor, a memory, a communication interface, and a communication bus.

[0071] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0072] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the user-visible evidence closed-loop access control device, as well as interfaces used for interconnecting the user-visible evidence closed-loop access control device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0073] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0074] The processor can be a general-purpose processor, which can call the user-visible evidence closed-loop admission procedure stored in memory and execute the user-visible evidence closed-loop admission method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the user-visible evidence closed-loop admission procedure is called can be referred to the various embodiments of the user-visible evidence closed-loop admission method of this application, and will not be repeated here.

[0075] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0076] Fourthly, embodiments of this application also provide a readable storage medium.

[0077] The present application stores a user-visible evidence closed-loop admission procedure on a readable storage medium, wherein when the user-visible evidence closed-loop admission procedure is executed by a processor, it implements the steps of the user-visible evidence closed-loop admission method as described above.

[0078] The method implemented when the user-visible evidence closed-loop admission procedure is executed can be referred to in various embodiments of the user-visible evidence closed-loop admission method of this application, and will not be repeated here.

[0079] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "objective," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "objective," and "third" to different types.

[0080] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0081] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0082] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0083] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0085] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A user-visible evidence closed-loop admission method, characterized in that, include: The first evidence package and its corresponding first evidence identifier are determined based on the original output results, wherein the original output results are generated by the data analysis tool invoked by the user; The agent receives an acceptance request, which is generated when the agent determines to show the target evidence to the user. The acceptance request includes a target evidence identifier corresponding to the target evidence. The target evidence package is retrieved based on the target evidence identifier, and a retrieval result is generated. The target evidence package includes normalized data, target hash value, and target source information. The acceptance verifier is invoked to verify the target evidence identifier in the acceptance request based on the first evidence package, the first evidence identifier, and the retrieval result, and the verification result is obtained. Based on the verification results, determine whether to add the target evidence identifier to the rendering whitelist of the current session in order to achieve closed-loop access control for user-visible evidence.

2. The user-visible evidence closed-loop admission method as described in claim 1, characterized in that, The process of determining the first evidence package and its corresponding first evidence identifier based on the original output results includes: Based on the original output results, determine the first source information, normalized data, and their basic hash values ​​respectively; The standardized data, basic hash value, and first source information are used as the first evidence package, and a first evidence identifier corresponding to the first evidence package is generated.

3. The user-visible evidence closed-loop admission method as described in claim 2, characterized in that, The call to the acceptance verifier verifies the target evidence identifier in the acceptance request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain a verification result, including: Determine whether the target evidence package exists in the retrieved results, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the base hash value. If so, the verification result is determined to be successful; If not, the verification result is determined to be verification failure.

4. The user-visible evidence closed-loop admission method as described in claim 1, characterized in that, The step of determining whether to add the target evidence identifier to the rendering whitelist of the current session based on the verification result includes: If the verification result is successful, the target evidence identifier will be added to the rendering whitelist of the current session. If the verification result is a verification failure, the request will be rejected and the target evidence identifier will not be added to the rendering whitelist.

5. The user-visible evidence closed-loop admission method as described in claim 1, characterized in that, The method further includes: Extract the target evidence identifier from the agent's response text and determine whether the target evidence identifier exists in the rendering whitelist; If so, then normalized data is obtained from the target evidence package based on the target evidence identifier for rendering; If not, then the presentation of evidence based on data embedded in the response text is prohibited.

6. A user-visible evidence closed-loop access control system, characterized in that, The user-visible evidence closed-loop access control system includes: The first processing module is used to determine the first evidence package and its corresponding first evidence identifier based on the original output result, wherein the original output result is generated by the data analysis tool invoked by the user; The second processing module is used to receive an adoption request sent by the intelligent agent. The adoption request is generated when the intelligent agent determines to show the target evidence to the user. The adoption request includes a target evidence identifier corresponding to the target evidence. The third processing module is used to retrieve the target evidence package based on the target evidence identifier and generate the retrieval result. The target evidence package includes normalized data, target hash value and target source information. The fourth processing module is used to call the adoption verifier to verify the target evidence identifier in the adoption request based on the first evidence package, the first evidence identifier, and the retrieval result to obtain the verification result; The fifth processing module is used to determine whether to add the target evidence identifier to the rendering whitelist of the current session based on the verification results, so as to achieve closed-loop access control for user-visible evidence.

7. The user-visible evidence closed-loop access control system as described in claim 6, characterized in that, The first processing module is specifically used for: Based on the original output results, determine the first source information, normalized data, and their basic hash values ​​respectively; The standardized data, basic hash value, and first source information are used as the first evidence package, and a first evidence identifier corresponding to the first evidence package is generated.

8. The user-visible evidence closed-loop access control system as described in claim 7, characterized in that, The fourth processing module is specifically used for: Determine whether the target evidence package exists in the retrieved results, whether the target source information is complete relative to the first source information, whether the first evidence identifier is consistent with the target evidence identifier, and whether the first hash value is consistent with the base hash value. If so, the verification result is determined to be successful; If not, the verification result is determined to be verification failure.

9. A user-visible evidence closed-loop access control device, characterized in that, The user-visible evidence closed-loop admission device includes a processor, a memory, and a user-visible evidence closed-loop admission program stored in the memory and executable by the processor, wherein when the user-visible evidence closed-loop admission program is executed by the processor, it implements the steps of the user-visible evidence closed-loop admission method as described in any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a user-visible evidence closed-loop admission procedure, wherein when the user-visible evidence closed-loop admission procedure is executed by a processor, it implements the steps of the user-visible evidence closed-loop admission method as described in any one of claims 1 to 5.

Images