An artificial intelligence output verification correction method, system, device and medium

Abstract

The present application relates to artificial intelligence output verification and dialogue error correction, and discloses an artificial intelligence output verification and error correction method. The method solidifies the learner's questioning into a questioning event of a binding target message, a target response version and a target span, constructs an isolated verification exchange containing an original task, a target span and a learner's reason according to a field whitelist, and excludes error recognition, defense or self-evaluation text of a service model after receiving the questioning. The server maps the integrity and conflict state of independent evidence into three states of confirming artificial intelligence error, unconfirmed questioning or uncertainty; only when the error is confirmed, conditional writing is performed with an event idempotent key, a target response version and an error correction version, the original span and the corrected span are saved, and the original record is kept and verified when the evidence is insufficient, the conflict or the target version changes, so as to avoid flattery false error recognition and concurrent error correction, and form a replayable evidence chain.

Description

Technical Field

[0001] This invention relates to artificial intelligence output verification and dialogue error correction, specifically to a method, system, electronic device, and computer-readable storage medium by which a computer processor controls versioned data objects, state transitions, generation requests, and access results. Background Technology

[0002] Generative AI has been used for learning dialogue, content assistance, and human collaboration. Existing systems often directly concatenate rules, permissions, supervisory opinions, or historical states into natural language context and deliver it immediately after the model returns the text. This approach mixes deterministic control with probabilistic generation, making it difficult to handle undoings, concurrent updates, duplicate requests, and storage failures that occur during request execution, and also difficult to reconstruct the input version upon which a specific output is based from historical records.

[0003] Specifically, when learners question the model, the service model may feign error to appease incorrect questions, or it may refuse to acknowledge genuine errors. Directly allowing the same generation process to self-evaluate cannot create a reliable error correction record. If implementation is limited to agreed-upon prompts or current status queries, issues such as old result delivery, duplicate consumption of one-time states, unauthorized visibility of roles, or broken audit chains may occur in asynchronous generation and multi-node deployment environments. Summary of the Invention

[0004] Technical problems to be solved

[0005] The technical problem this invention aims to solve is that when learners question a model, the service model may either falsely admit to wrongdoing by catering to erroneous questions or refuse to acknowledge genuine errors; directly allowing the same generation process to self-evaluate cannot form a reliable error correction record.

[0006] Technical solution

[0007] The core of this invention is to solidify learner challenges as challenges events bound to the previous response version and the target span; in an isolated verification context without reading the self-evaluation text after the challenge in the service model, to form three states of results for the target proposition: confirmed error, unconfirmed challenge, or uncertain; and to write the original span-corrected span mapping with the challenge event idempotent key and the target version condition, without rewriting the original record when uncertain.

[0008] The processor performs the following steps:

[0009] 1. Detect AI error challenges in learner messages and solidify the challenged previous outputs or steps into a challenge event with a target response version and target span. 2. Construct an isolated verification exchange containing the original task, target span, learner challenge reasons, and restricted context, excluding the service model's self-evaluation text after challenge. 3. Submit the isolated verification exchange to at least one of the following: independent prompt context, independent model instance, deterministic validator, or external evidence source. 4. Map the server-side to a confirmed AI error, unconfirmed challenge, or uncertain state based on evidence completeness, conflict status, and verification results. 5. Generate a corrected span when an error is confirmed, generate an evidence explanation when unconfirmed, and retain the original record and mark it for verification when uncertain. 6. Write the execution conditions using the challenge event idempotent key and target response version, saving the original span-corrected span mapping and the error-corrected version; points or rewards are only optional subsequent events.

[0010] The steps use the following versioned data objects:

[0011] 1. Questioning event: event idempotency key, session identifier, target message identifier, target response version, target span, learner reason, creation time and event status.

[0012] 2. Isolation Validation Exchange: Exchange identifier, original task summary, target span content, learner rationale, allowed context fields, prohibited fields, evidence request, and validation strategy version.

[0013] 3. Evidence Records: Evidence identifier, source type, content hash, reference location, retrieval time, integrity status, conflict identifier, and validator output.

[0014] 4. Three-state decision record: exchange identifier, evidence set hash, integrity rule version, conclusion status, reason code, and identifier pending manual verification.

[0015] 5. Error correction log: event idempotent key, target response version, original span, corrected span, evidence reference, current error correction version, write status, and update time.

[0016] The model interface only generates candidate results; permission determination, version comparison, state transition, condition consumption, rollback and delivery decisions are all executed by the server program outside the model.

[0017] Beneficial effects

[0018] • Reduce false positives caused by model conformity. • Avoid incorrectly recording validation failures as invalid learner challenges. • Establish an auditable AI error attribution and correction status.

[0019] The aforementioned effects are generated by the data objects, processing order, and transaction conditions, and do not depend on specific model vendors, nor are they based on educational philosophies or business rules as technical contributions. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the system structure.

[0021] Figure 2 This is the flowchart for the core method.

[0022] Figure 3 This is a diagram illustrating the relationship between data objects and their versions.

[0023] Figure 4 This is a schematic diagram of a critical state transition.

[0024] Figure 5 A timing diagram for generation, verification, and condition writing.

[0025] Figure 6 This is a diagram illustrating the decision-making process for handling exceptions.

[0026] Figure 7 This is a diagram illustrating the audit records and historical reconstruction.

[0027] Figure labeling: 100—Processing system; 110—Question detection module; 120—Target localization module; 130—Verification exchange module; 140—Isolation verification module; 150—Three-state decision module; 160—Error correction and auditing module; 200—Versioned data storage; 300—Generation model interface; 400—Audit log; 500—Learner terminal or requester. Detailed Implementation

[0028] The following embodiments are used to illustrate the present invention and do not limit the scope of protection. Modules can be deployed on the same computing node or on different nodes via an authenticated network connection; object storage can employ a relational database, key-value store, or a storage system that provides equivalent atomic conditional update capabilities.

[0029] Terminology Definition

[0030] 1. A challenge event is an immutable record of making erroneous challenges to a specific message version and content span in an existing AI response.

[0031] 2. The target span is the smallest locatable content range in the original response that is being questioned. It can be represented by a character range, a token range, a structured step identifier, or a combination thereof.

[0032] 3. The isolated validation exchange only includes the original task, target span, learner rationale, and constrained context required for the validation objective, and does not include self-evaluation after the service model is challenged.

[0033] 4. The three-state conclusions include confirmed AI errors, unconfirmed doubts, and uncertainty; uncertainty is used for insufficient evidence, conflicting evidence, or verification service anomalies.

[0034] 5. Span-level error correction records preserve the correspondence between the original span and the corrected span, rather than irretrievably overwriting the entire historical message.

[0035] System Structure

[0036] like Figure 1 As shown, the processing system 100 includes a challenge detection module, a target localization module, a verification exchange module, an isolation verification module, a three-state decision module, and an error correction and auditing module. Input records are written to a versioned data storage 200; the generation model interface 300 only receives requests formed after pre-control; the audit record 400 saves input snapshots, rule versions, processing reasons, candidate result hashes, and final delivery status. Modules are associated with immutable request identifiers, and it is prohibited to replace historical inputs with current session values ​​that can be overwritten later.

[0037] Data objects, primary keys, and version relationships

[0038] like Figure 3 As shown, this embodiment adopts the following object pattern:

[0039] 1. Questioning event: event idempotency key, session identifier, target message identifier, target response version, target span, learner reason, creation time and event status.

[0040] 2. Isolation Validation Exchange: Exchange identifier, original task summary, target span content, learner rationale, allowed context fields, prohibited fields, evidence request, and validation strategy version.

[0041] 3. Evidence Records: Evidence identifier, source type, content hash, reference location, retrieval time, integrity status, conflict identifier, and validator output.

[0042] 4. Three-state decision record: exchange identifier, evidence set hash, integrity rule version, conclusion status, reason code, and identifier pending manual verification.

[0043] 5. Error correction log: event idempotent key, target response version, original span, corrected span, evidence reference, current error correction version, write status, and update time.

[0044] Each object must have at least an object identifier, a principal or session identifier, a version number, a creation time, an update time, and a content hash. Objects requiring visibility control also include sets of role, scope, or projection fields. The version number monotonically increments when fields affecting production or delivery are modified; the control version remains unchanged when only non-controlling display fields are updated.

[0045] Normal processing procedure

[0046] like Figure 2 As shown, the processor executes in the following order.

[0047] Step S101

[0048] The processor detects AI error challenges in learner messages and solidifies the previous outputs or steps challenged into a challenge event with a target response version and target span. During this step, the processor reads an input snapshot associated with the request identifier, validates the object identifier, version, scope, and state fields, and writes the processing result to an intermediate record with a content hash. Subsequent processing steps only read intermediate records that have passed validation; if validation fails, the corresponding failure branch is entered, without replacing server-side state control with model-based arbitrary judgment.

[0049] Step S102

[0050] Construct an isolated validation exchange that includes the original task, target span, learner's reasons for questioning, and restricted context, excluding the service model's self-evaluation text after questioning. During this step, the processor reads the input snapshot associated with the request identifier, validates the object identifier, version, scope, and state fields, and writes the processing result to an intermediate record with a content hash. Subsequent processing steps only read intermediate records that have passed validation; if validation fails, the corresponding failure branch is entered, without replacing server-side state control with the model's discretionary judgment.

[0051] Step S103

[0052] The isolated validation exchange is submitted to at least one of the following: an independent prompt context, an independent model instance, a deterministic validator, or an external evidence source. During this step, the processor reads the input snapshot associated with the request identifier, validates the object identifier, version, scope, and state fields, and writes the processing result to an intermediate record with a content hash. Subsequent processing steps only read intermediate records that have passed validation; if validation fails, the corresponding failure branch is entered, without replacing server-side state control with model-based discretionary judgment.

[0053] Step S104

[0054] Based on the completeness of evidence, conflict status, and verification results, the server maps the status to confirmed AI error, unconfirmed question, or uncertain. During this step, the processor reads the input snapshot associated with the request identifier, verifies the object identifier, version, scope, and status fields, and writes the processing result to an intermediate record with a content hash. Subsequent processing steps only read intermediate records that have passed verification; if verification fails, the corresponding failure branch is entered, and server-side state control is not replaced by model-based arbitrary judgment.

[0055] Step S105

[0056] When an error is confirmed, a correction span is generated; when unconfirmed, an evidence explanation is generated; when uncertain, the original record is retained and marked for verification. During this step, the processor reads the input snapshot associated with the request identifier, verifies the object identifier, version, scope, and state fields, and writes the processing result to an intermediate record with a content hash. Subsequent processing steps only read intermediate records that have passed verification; if verification fails, the corresponding failure branch is entered, and server-side state control is not replaced by model-based arbitrary judgment.

[0057] Step S106

[0058] The process writes the execution conditions based on the idempotent key of the challenged event and the target response version, saving the original span-corrected span mapping and the error-corrected version; points or rewards are only optional subsequent events. During this step, the processor reads the input snapshot associated with the request identifier, validates the object identifier, version, scope, and state fields, and writes the processing result to an intermediate record with a content hash. Subsequent processing steps only read intermediate records that have passed validation; if validation fails, the corresponding failure branch is entered, and server-side state control is not replaced by model-based arbitrary judgment.

[0059] Deterministic processing rules

[0060] 1. The challenge detection first identifies the cited message, then determines the target span; if it cannot be uniquely located, it does not initiate verification, but instead asks the learner to select.

[0061] 2. The isolation verification exchange is constructed based on a field whitelist, and the response identifier after the service model is challenged belongs to the prohibited fields.

[0062] 3. The validator can combine deterministic computation, retrieval evidence, and independent models, but each piece of evidence retains its source and integrity status.

[0063] 4. The three-state mapping is executed by the server-side rules based on the sufficiency of evidence and the state of conflict, and does not directly use the free text labels of the verification model.

[0064] 5. Only confirmed error states will proceed to the error correction and writing process; unconfirmed questions will generate evidence explanations, and uncertain states will retain the original records and enter the pending verification queue.

[0065] The rule itself has a version. The request record saves both the object version and the rule version, so that the same input can yield a verifiable processing path.

[0066] Concurrency, Transactions and Idempotency

[0067] 1. For repeated challenges involving the same idempotent key, return existing verification tasks or error correction records, and do not write them into the statistics again.

[0068] 2. When a new version of the target response is generated during the verification process, the error correction conditions of the old version are not met, and the system retains the verification results but does not modify the new version.

[0069] 3. When multiple validators return conflicting conclusions, all evidence is recorded first, and then mapped to uncertainty or manual verification by the integrity rule.

[0070] 4. Error correction records are updated using the current error correction version conditions to prevent two correction results from overwriting each other.

[0071] The transaction boundary overlay of conditional writes affects the status update of delivery eligibility and the writing of audit results. If the storage system cannot complete both within the same transaction, it first writes to an undeliverable state, and then changes it to a deliverable state after the audit is completed by an idempotent compensation task, avoiding the situation of delivering first and then recording later.

[0072] Example

[0073] Example 1

[0074] In Example 1, the learner points out a symbol error in the third step of the mathematical derivation. The system solidifies the target response version and span based on the reference message and step identifier, and submits the original task and the span to the deterministic computation verifier. After the evidence confirms the error, a corrected span is generated and written into the corresponding relationship with the event idempotency key and the target version condition.

[0075] During processing, the request identifier, input version, server time, and reason code are saved. Candidate results are only written to the visible history after the delivery conditions are finally met; if the conditions are not met, the result hash and failure reason are retained, but the restricted text is not saved.

[0076] Example 2

[0077] In Example 2, the learner simply says "You were wrong just now." The system combines the most recent reference relationship and the subsequent reason to obtain two candidate spans. Since it cannot uniquely locate the span, it does not initiate verification and returns a span selection request, thus avoiding using the entire response as a fuzzy verification target.

[0078] During processing, the request identifier, input version, server time, and reason code are saved. Candidate results are only written to the visible history after the delivery conditions are finally met; if the conditions are not met, the result hash and failure reason are retained, but the restricted text is not saved.

[0079] Example 3

[0080] In Example 3, the retrieved evidence conflicts with the conclusions of the independent model. The server-side integrity rule maps the result to uncertainty, without rewriting the original message and learning statistics, only saving the evidence set and the identifier to be verified; subsequent manual verification can add conclusions based on the same exchange identifier.

[0081] During processing, the request identifier, input version, server time, and reason code are saved. Candidate results are only written to the visible history after the delivery conditions are finally met; if the conditions are not met, the result hash and failure reason are retained, but the restricted text is not saved.

[0082] Optional implementation methods

[0083] 1. The target span can be represented using character positions, token positions, structured reasoning step identifiers, or semantic anchors.

[0084] 2. The validator may be a computational tool, a rule engine, a retrieval system, an independent model instance, or a controlled combination thereof.

[0085] 3. The three-state result can expand the sub-reason code, but the top level must retain the uncertain state to accommodate insufficient evidence and conflicts.

[0086] 4. The rewards or points module can subscribe to confirmation error events, but it does not participate in verifying conclusions or writing error correction conditions.

[0087] All optional methods maintain the object association, processing order, and delivery gating relationships described in the claims.

[0088] Exceptions and failure paths

[0089] like Figure 6 As shown, at least the following failure handling is included:

[0090] 1. When the target message or span cannot be uniquely located, the learner is asked to confirm, and the most recent message is not used as an unconditional default.

[0091] 2. Record uncertain states when verification service times out, evidence source is unavailable, or evidence integrity is insufficient.

[0092] 3. If a forbidden field is detected in the verification exchange, the verification process is terminated and the isolation exchange is reconstructed.

[0093] 4. When the target response version changes or there is a conflict in the correction version, write is refused, and the old span mapping is not applied to the new message.

[0094] 5. When error correction storage fails, retry safely with an event idempotent key to avoid generating multiple valid error correction versions.

[0095] Failed branches are treated conservatively, not expanding the visibility of information, and unsuccessful consumption or error correction operations are not marked as completed. Retry must reuse or derive traceable idempotent keys.

[0096] State and Timing

[0097] Figure 4The displayed states are, in order: Questioning and awaiting location, Fixed version and span, Isolation and verification in progress, Three-state decision made, Error corrected or awaiting verification. State transitions are triggered by server-side verification conditions, and direct modification of the control state by candidate text is prohibited. Figure 5 The participants in this process include the learner, the challenge service, the isolation validator, and the error correction storage. Their interactions proceed sequentially as follows: submitting a challenge with a citation, fixing the target version and span, constructing a whitelist for field verification and exchange, returning evidence and integrity status, mapping the server to three states, writing conditions when an error is confirmed, and returning a corrected, explained, or pending verification status. Any asynchronous response first locates the bound snapshot based on the request identifier before performing a pre-delivery review.

[0098] Auditing and Historical Reconstruction

[0099] like Figure 7 As shown, the audit chain includes the challenged event, target version and span, isolated exchange fields, evidence integrity and three-state, and span correction version. During reconstruction, the immutable snapshot and the current rule version are read according to the request identifier, the intermediate state is recalculated, and the result hash is compared; the current configuration must not replace the historical configuration.

[0100] Questioning event generation and deduplication

[0101] In one implementation, the challenge detection module identifies challenge candidates from learner messages, citation relationships, and session state. Challenge candidates are categorized into at least five types: factual errors, calculation errors, reasoning step errors, citation errors, and inability to locate. The detection results only determine whether to establish a verification process, not directly concluding that the AI ​​has made a mistake. Candidates with low confidence or inability to locate can request the learner to confirm the target, rather than misjudging the lack of location as an unconfirmed challenge.

[0102] A challenge event includes an event identifier, learner message identifier, target response identifier, target response version, target span, challenge type, learner reason, reception time, detection rule version, and idempotency key. The idempotency key is formed by the session, learner message, and target response version; network retries return the same event. Learners may raise different spans or reasons for the same response, resulting in different events, but the span overlap is recorded in an association table for subsequent evidence merging.

[0103] Both the question text and the target response text retain separate content summaries. Once an event is created, subsequent edits of learner messages will not overwrite the original question; edits generate a new event version. When the target response is edited or replaced, the old event remains bound to the old version, and a target version condition check is performed before writing the correction.

[0104] Target span positioning

[0105] The target localization module prioritizes using explicit message references, character ranges selected through the interface, or step identifiers. When no explicit range is available, it generates one or more candidate spans based on learner-referenced fragments, ordinal numbers, mathematical expressions, and semantic locations. Each candidate saves the start and end positions of the characters, the start and end positions of the token, the selected text summary, and the localization message status.

[0106] The system selects the smallest span that can be uniquely reproduced in the target response version from the candidates. If the same text appears multiple times, it is disambiguated by combining the context summary and step identifier; if it still cannot be uniquely determined, the event status is "pending location," and the original response is not modified. For structured output, the span can be a tree node path, table cell, or formula node identifier, and is not limited to a plain text character range.

[0107] The target span contains a content summary. When writing corrections, the same position is reread from the target response and the summary is compared. If the target response version or span summary changes, old corrections are refused to be written to the new content to avoid asynchronous validation results overwriting different versions already seen by the user.

[0108] Isolation verification exchange construction

[0109] Validation exchange is not simply copying the entire session to another model. The exchange builder selects allowed fields based on the type of challenge, including the original task, necessary question conditions, target span, its limited context, learner's reasons for challenging, and available external evidence. Prohibited fields include apologies or justifications generated by the service model after receiving a challenge, self-assessment confidence, reward status, learner's historical evaluations, and private conversations unrelated to the current validation.

[0110] Each field includes source, version, purpose, and content summary. The constructor verifies that the task version matches the task version upon which the target response is based; attachments are passed via read-only content references or summaries, and the verifier cannot access the entire session store. The exchange record stores the versions of allowed field sets and the occurrence of prohibited field matches. If a necessary field is missing, a negative conclusion is not reached; instead, the evidence is marked as insufficient.

[0111] For validation tasks that may be anchored to the output of the original service model, only the conclusion types of the original task and the target span can be provided, without providing subsequent self-explanations from the service model. When it is necessary to examine the inference steps, the questioned steps and their preconditions should be provided, without providing the original model's response to the questioning. This isolation reduces circular evidence caused by self-confirmation within the same model.

[0112] Independent validator selection and execution

[0113] The validator registry records the validator type, applicable tasks, input field patterns, version, and availability. For numerical computations, deterministic calculators can be preferred; for code output, isolated executors and test assertions can be selected; for factual questions, evidence retrieval with source restrictions can be chosen; for open reasoning, independent contextual hints or different model instances can be selected. Routing rules are determined by the task type and evidence requirements, and are not specified by the original service model.

[0114] A challenge event can invoke multiple validators in parallel. Each validation result includes a conclusion candidate, evidence citation, target coverage span, validator version, execution status, and result summary. Timeouts, parsing failures, or evidence source unreachability are recorded as execution failures and cannot be converted into "the AI ​​made no mistakes." Results from different validators are merged using pre-registered evidence rules.

[0115] External evidence citations should at least retain the source identifier, retrieval time, and content summary; the location of verifiable segments should be saved when necessary, but large sections of restricted content should not be copied. If evidence changes after verification, the old correction record can still be reconstructed based on the summary at that time, and new challenges should use the new version of evidence.

[0116] Evidence integrity and three-state mapping

[0117] The server first calculates the completeness of the evidence, then maps the conclusion. Completeness checks include whether necessary inputs are complete, whether the target span is unique, whether at least one applicable validator is successful, whether key evidence is readable, and whether there are unresolved conflicts among multiple results. If completeness is not satisfied, the output is uncertain and the unconfirmed challenge is not initiated.

[0118] When complete evidence clearly indicates that the target span is inconsistent with the correct result, it is mapped as confirming an AI error; when complete evidence clearly supports the original span and responds to the learner's reasoning, it is mapped as an unconfirmed challenge; when there are conflicting evidence, multiple solutions to the task itself, validator timeout, or insufficient evidence coverage, it is mapped as uncertain. The three-state reasoning code and the evidence set version are stored simultaneously.

[0119] The three-state result is not a numerical reward rule. Confirmed errors can trigger error correction; unconfirmed questions generate learner-oriented evidence explanations; uncertain states retain the original record and are marked for manual verification. Any adjustments to points, badges, or evaluations are handled by subsequent optional events and cannot reverse the verification conclusion.

[0120] Correcting span generation and condition writing

[0121] After confirming the error, the correction module generates a replacement or supplementary span based on the verified conclusions. The correction record includes the original span summary, the corrected text, the corrected summary, evidence citations, the corrected version, and the display strategy. The corrected text undergoes another validation process to match the task type; the free text from the validation model cannot be used as the final correction.

[0122] The write conditions include at least the following: the idempotent key of the challenged event has not generated a valid correction; the target response version equals the event-bound version; the target span digest has not changed; and the current correction version meets expectations. When the conditions are met, the span mapping is written, the correction version is incremented, and a projection failure event is generated in the same transaction. When the conditions are not met, the verification results are retained, but the correction is not overwritten to the current response.

[0123] The original message can remain immutable, with the original span marked and the correction presented during display via error-correcting projection; alternatively, a new message version can be created, but the mapping from the old version to the new version must be preserved. The learner model history can read the corrected projection according to the policy, and auditing the projection preserves both the original and corrected spans. Original content that has been confirmed to be erroneous should not continue to be used as unmarked facts in future models.

[0124] Concurrency, retries and rollback

[0125] Multiple challenge events can point to the same target span. After the first error is confirmed and written, other events read the current correction version before writing; if their correction digests are the same, they can be associated with the existing correction without creating a new version; if the corrections are different, they enter conflict review, without arbitrarily overwriting. Event handling retry reuses verification exchange identifiers and result digests to avoid repeated calls causing different random conclusions to be written directly.

[0126] When error correction projection update fails, the transaction log retains the reconstructable event, the original response display status remains unchanged, and it is marked as published only after the background idempotent task completes the projection. If the correction verification fails before writing, the challenge result can retain the confirmed error, but the error correction status is pending generation. Unverified replacement text cannot be written to complete the process.

[0127] Further Examples

[0128] In the fourth embodiment, the learner points out an error in the symbol of the second line in the calculation result and selects the expression on the interface. The target localization module directly saves the character span and formula node path. After the deterministic calculator recalculates and confirms the error, the system only replaces the selected span and does not rewrite irrelevant explanatory paragraphs.

[0129] In the fifth embodiment, the learner claims a historical fact is incorrect, and two sources of evidence provide conflicting records. Although one of the verification models tends to support the learner, the integrity rule identifies the key evidence conflict and maps it to uncertainty. The original response is not rewritten, and the supervisor projects the reason for the pending verification.

[0130] In the sixth embodiment, a new version of the original response is generated for other reasons before model validation is completed. The condition write rejects the old correction upon discovering a change in the target version. The system can reposition the target span based on the new version; a correction event for the new version is only established after revalidation or confirmation that the span content summary has not changed.

[0131] Data protection and equivalent implementation

[0132] The verification exchange only saves the fields required to complete the verification, and the access token has short-term usage limitations. The regular log saves the event identifier, version, reason code, and summary, but does not copy the complete learner dialogue. Target spans can be represented by character ranges, token ranges, structure paths, or content-addressed fragments; the validator can be a program, model, or controlled evidence service. Different implementations still maintain the processing chain of target version binding, isolated verification, tri-state mapping, and conditional error correction writes.

[0133] Questioning type adapter

[0134] The factual challenger extracts the target statement, entities, time, and source requirements; the numerical challenger extracts the expression, input quantity, unit, and rounding rules; the reasoning challenger extracts the premise, target step, and subsequent steps; and the code challenger extracts the code version, runtime environment, and failure assertions. The adapter outputs a uniform validation task object, but retains type-specific fields.

[0135] The adapter only reads data from the target response version bound to the event and the allowed context. New facts contained in learner challenges are saved as claims to be verified, rather than being directly added to the original task conditions. When there are unparseable mathematical expressions, missing code environments, or unclear source requirements, the adapter writes missing necessary fields into the integrity state.

[0136] The unified task object includes the verification task identifier, challenge event identifier, target span summary, task type, allowed field references, prohibited field summary, verification requirements, and task version. The validator must return the task identifier and version; results from older tasks cannot be written to new events.

[0137] Deterministic Validator Example

[0138] The numerical computation validator parses allowed expression syntax in an isolated process, performs calculations using explicit precision and rounding rules, and returns a summary of intermediate results. The unit validator checks units and conversions. The code validator executes pre-registered tests in a container with limited network and resources and does not accept production credentials. Structured questions can use the answer key validator, but the answer key version must be consistent with the question version.

[0139] When a deterministic validator encounters an exception, it returns an execution failure and error type, but does not output a negative conclusion. The parser rejects arbitrary system calls, external file paths, and unregistered functions. The execution log stores the task identifier, validator version, resource limits, and a result summary, but does not store learner credentials.

[0140] The same task can invoke multiple complementary validators; for example, the unit validator can first confirm the dimensions, and then the numerical validator can confirm the calculation. The evidence merger determines whether the result is sufficient to support the target span based on the coverage field; the correctness of the entire response cannot be confirmed simply because a partial check is successful.

[0141] Model and Evidence Source Validator

[0142] The model validator uses independent system instructions, independent sessions, and restricted exchanges. Any self-assessment text generated by the service model after challenge is not entered into the exchange. The model returns structured results, including target span judgments, reason fields, evidence citations, and uncertainties; completeness is reduced when parsing fails or evidence citations are missing, rather than using free-text conclusions.

[0143] The evidence retrieval system only accesses registered data sources and query scopes, saving the query summary, source version, time, and hit location. When source authentication is required, the system uses the purpose credentials of the verification service, without writing the credentials to the exchange or model context. After changes to the content of web pages, knowledge bases, or question banks, new verifications use the new source summary, while historical conclusions can still be reconstructed using the old summary.

[0144] Multiple model instances agreeing does not automatically constitute independent evidence; the merger distinguishes between model judgments and external evidence. Completeness is marked as sufficient only when the required type and coverage of evidence as specified by the rule are met.

[0145] Conflict of Evidence Handling

[0146] The evidence graph contains claim nodes, source nodes, and supporting or refuting edges. Each edge stores the validator, coverage span, source version, and strength type. Conflicting edges are handled based on source applicability, version matching, and validation rules, rather than a simple majority vote based on model votes.

[0147] If the conflict can be explained by differences in task versions, the system selects the source that matches the event task version and marks other sources as inapplicable; if the sources are equally applicable and the conflict cannot be resolved, the conclusion is uncertain. Learners' objections are treated as claims to be verified and can be supported by evidence, but they are not considered final evidence in themselves.

[0148] Manual verification can resolve uncertainties. The input for manual verification is also bound to the event, target version, and evidence graph version, and the verifier's corrections are written through conditions; the manual conclusion will not overwrite the original automatic verification record, but will enter the audit chain as a new evidence node.

[0149] Error correction projection and history building

[0150] When the original response remains immutable, the error-correcting projection saves the target message, target version, original span, corrected span, evidence summary, and display status. When learners read the message, the projection builder confirms that the error correction still applies to the current message version, and then displays it by marking, replacing, or supplementing. Supervisor projections can view both the original text and the correction simultaneously, while ordinary learners read the corrected visible text according to the strategy.

[0151] The model history builder does not simply delete the original response. It can retain the original span, error markers, and corrected spans, so that subsequent models know that an error correction occurred; or it can retain only the corrected version, but must save the error correction reference. Unconfirmed uncertain events do not modify the model history facts, but only add a pending verification status.

[0152] Multiple non-overlapping corrections can be combined into the same message projection; when the span overlaps, conflicts are detected based on the correction version and evidence status. Two overlapping corrections cannot be applied in the order they were written; in case of a conflict, the last combined version that has been manually or rule-confirmed is retained, and the excluded correction is recorded.

[0153] Notifications and Learning Status Updates

[0154] After confirming an error, the system can send a correction notification to the learner and an audit notification to the supervisor. Notifications use error correction event identifiers for deduplication, and failure to send the notification does not roll back submitted error correction records. The learner's confirmation of reading only updates the notification status and does not change the verification conclusion.

[0155] Learning status, quality statistics, and rewards belong to downstream consumers. They only consume structured events that confirm errors or unconfirmed questions, and retain the corrected version on which they are based. Uncertain events must not lower or raise learner scores. If a corrected error is later overturned by a higher version, the downstream system recalculates via reverse events, without directly deleting historical statistics.

[0156] Idempotency and Event Recovery

[0157] Each of the following steps—question reception, verification task creation, verification result submission, three-state mapping, and error correction writing—has an independent idempotent key. After a service restart, the recovery task continues the unfinished phase based on the event status. Completed verification results are not re-invoked due to message retries; a new task version is only created when the verification rules or allowed field versions change.

[0158] When error correction is successfully written but projection publication fails, the transaction log saves the error correction event, and the publisher retryes the same projection version. When the target response is deleted or the session is closed, the error correction record retains its audit relationship, but the learner projection is handled according to the deletion policy, and the corrected text is not exposed to other sessions.

[0159] Further Examples

[0160] In the seventh embodiment, the learner challenges a physics calculation involving units. The unit verifier confirms an error in the units, while the numerical verifier confirms that the number is calculated correctly using the incorrect units. Evidence diagrams show that the unit conclusion for the target span is incorrect. The system confirms the AI ​​error and only corrects the units and corresponding numerical values, without rewriting the original question.

[0161] In the eighth embodiment, the learner believes a piece of code outputs an error. The isolated executor discovers that the runtime environment version used by the original response is different from the task requirements, executes with the correct version, and supports the learner's challenge. The error correction log saves the environment version, failure assertion summary, and corrected output; production system credentials do not enter the execution environment.

[0162] In the ninth embodiment, the source of factual evidence is temporarily unavailable, and the model validator assumes the learner may be correct. Due to the lack of source evidence required by the rules, the completeness is insufficient, and the conclusion remains uncertain. Once the data source is restored, a new version of the validation task is created, and the new evidence can advance the event to either confirmed error or unconfirmed challenge.

[0163] Monitoring and Reproduction

[0164] Monitoring metrics include events to be located, validator failures, evidence conflicts, uncertain conclusions, version write conflicts, and projection release retries. Metrics do not include the challenge text or the target response text. The reproduction tool loads the target version, allowed fields, validator version, evidence graph, and mapping rules by event identifier, recalculates the three states, and compares the result summaries.

[0165] Verification Task Database Example

[0166] An implementation method includes setting up a challenge event table, a target span table, a verification exchange table, a verification task table, an evidence node table, a verification result table, a three-state conclusion table, and a correction version table. The challenge event table is set with unique constraints using idempotent keys; the target span table stores the response version and span summary; and the verification task table stores the allowed field set version and the validator version.

[0167] Evidence nodes are linked by event identifiers, supporting the storage of support or rebuttal relationships. The three-state conclusion table stores the evidence graph version, integrity result, mapping rule version, and reason code. The error correction table uses the event idempotency key, target response version, and error correction version to form a conditional write relationship, without directly overwriting the original message table.

[0168] When object storage is used for the text, the table stores read-only references and digests. Validators obtain short-lived tokens that can only read objects permitted by the current task; the tokens expire after the task ends. Audit queries can read the version and digest, but do not automatically obtain text object permissions.

[0169] Isolate execution boundary

[0170] The verification service and the online generation service use different session storage and service identities. The verifier cannot call the session continuation interface of the online generation service, cannot read the self-assessment text after challenge, and cannot write to the learner's history. Its only output is the verification result with a task version, which is processed by the three-state decision module.

[0171] Code or tool verification is performed in a resource-constrained environment, limiting runtime, memory, file system, and network. External evidence retrieval uses domain or data source whitelists. Model verification calls do not carry an online session identifier, only a verification task identifier and allowed fields. Any out-of-bounds access failure results in an indeterminate or task failure state.

[0172] Three-state transition table

[0173] A confirmed error occurs when the evidence is complete, the target is unique, the validator succeeds, and the evidence refutes the original span; a confirmed challenge occurs when the evidence is complete, clearly supports the original span, and responds to the reasons for the challenge; an uncertain challenge occurs when the target is not unique, necessary fields are missing, all validators fail, key sources are unavailable, or evidence conflicts. The transformation conditions are implemented by server-side tables or code and have rule versions.

[0174] Confirming an error requires the corrected candidate to pass the corresponding validation before it can proceed to the publishable error correction stage; otherwise, the conclusion remains confirmed as an error, but the error correction status remains pending generation. Unconfirmed questions only generate evidence explanations and do not mark the learner as incorrect. Regardless of the status, the model's self-reported confidence cannot independently change the transformation result.

[0175] Version competition example

[0176] Event A is bound to response version two and span summary B. After the verification task begins, another process updates the response to version three. The verification result can still be saved to event A, but the error correction write to the comparison version fails. The system does not directly apply the correction position of version two to version three, but instead creates a relocation task; if version three still contains the same content summary, it can associate old evidence and reconfirm it if the rules allow.

[0177] When two events simultaneously confirm the same span error, the first correction is written into version 1. If the correction summaries of the second event are the same, they are associated with version 1; if the summaries are different, a correction conflict is formed, and the issue is verified by a human or stronger validator. The display projection does not overlay the two replacement texts until the conflict is resolved.

[0178] Fault recovery

[0179] When the detection service fails, the original learner message is retained and can be retried later; when the target localization fails, clarification is requested; when the verification exchange construction fails, the validator is not invoked; when the validator times out, it enters indeterminacy; when the evidence graph writing fails, a three-state conclusion is not generated; when the error correction condition writing fails, the projection is not modified.

[0180] After service restart, recovery is based on event status. Completed verification tasks reuse result summaries, tasks without submitted three-state statements are re-executed using rule mappings, and events with submitted error corrections but not yet published projections are published idempotently. The recovery process will not treat failed tasks as unconfirmed challenges by default due to missing stage identifiers.

[0181] Interface output example

[0182] The learner correction projection can return the target message identifier, visible correction, brief evidence description, and status; the supervisor projection can additionally return the original span, validator status, evidence reference, and version chain; the audit projection returns a summary of allowed fields, rule version, and processing sequence. These three projections are constructed using strategies designed for different purposes.

[0183] Learners request that the validator's internal hints, other models' free reasoning text, restricted evidence credentials, or reward decisions not be returned. The points service only receives error correction event identifiers and the final structured state; it cannot access the isolated exchange text, nor can it write back the three-state conclusion.

[0184] Span normalization

[0185] Plain text spans are represented using a uniform character encoding, character start and end positions, and context summaries. When the target response contains rich text, the system first generates a normalized text view while preserving the mapping from normalized positions to the original nodes. Formulas are represented by structure nodes and normalized expressions, code is represented by file, row and column ranges, and code version, and tables are represented by row and column coordinates and cell summaries.

[0186] The normalization process saves the algorithm version. When editing spaces or styles in the display layer, the mapping confirms that the substantive content remains unchanged; when changing characters, formula nodes, or code content, a new response version is generated. If the normalization span cannot be mapped back to the unique display position, the error correction status is "pending location," and corrections cannot be applied to potentially incorrect locations.

[0187] When a challenge references multiple discontinuous segments, the event saves a set of spans and a summary of those spans. The verification task can verify each span separately, and then use evidence rules to determine whether the overall challenge is supported. During write operations, a version and summary comparison is performed for each corrected span; if one fails, the transaction can reject the entire challenge according to the rules, avoiding the result of only correcting half of the segment and altering the original intent.

[0188] Verify the orchestration state machine

[0189] The orchestration status is verified to include three states: received, awaiting location, exchange constructed, under verification, awaiting merging, and mapped; awaiting correction generation; awaiting writing; published; and terminated. Each state transition saves the expected old state, event version, and reason code. The work queue only retrieves tasks corresponding to its stage and cannot skip integrity checks to directly enter error correction writing.

[0190] After location is complete, the swap constructor atomically writes the allowed field set and swap digest. When multiple validators run in parallel, each result is set with a unique key based on the validation task and validator version. The merger waits for required validators to complete or exceed their deadlines before calculating the evidence graph; timeouts of required validators result in insufficient integrity, while timeouts of optional validators are recorded according to rules but not necessarily blocked.

[0191] After the three-state mapping is completed, confirmed errors proceed to correction generation, unconfirmed questions proceed to explanation generation, and uncertainties proceed to pending verification. Explanation generation also uses evidence citations to prevent the service model from freely fabricating reasons. If an unrecoverable schema error occurs at any stage, the event terminates while retaining the error summary, without modifying the original response.

[0192] Correct content verification

[0193] The corrections must pass the same or stronger verification rules as the original challenge. Numerical corrections involve recalculating and checking units; code corrections require running relevant tests in an isolated environment; factual corrections involve checking the source and task timing; and reasoning corrections confirm the relationship between premises and conclusions. The correction verification results and the original error verification results are saved separately; the confirmation of an error in the original text does not presume that any replacement will be correct.

[0194] Revisions only cover the necessary span. When the generator proposes a complete rewrite, the difference analyzer calculates the scope of the revision and checks for any unverified new claims. Content exceeding the target span and lacking supporting evidence is excluded or requires additional verification. This mechanism reduces the introduction of a second error during correction and facilitates the subsequent display of the correspondence between the original and revised spans.

[0195] Manual review interface

[0196] Uncertain events can be queued for manual review. The review interface projects the original task, target scope, learner's rationale, permissible evidence, and reasons for conflict through a supervisory purpose projection, but does not display self-assessments of service models prohibited by isolation rules. When selecting a conclusion, reviewers must associate it with at least one evidence node or an explanation that the matter cannot be determined.

[0197] Manual review submissions include the event version, evidence graph version, and expected three-state version. If the event or target response changes during the process, the condition write fails, and the interface loads the latest version. The manual conclusion, as a high-privilege evidence node, enters the same three-state mapping and correction verification process, directly rewriting the learner message without bypassing any side-channels.

[0198] Retention and Deletion Policies

[0199] The retention period for challenge events, target versions, three-state reasons, and error correction mappings can be longer than the isolation exchange body. After the exchange body expires, field summaries, validator versions, and evidence citations are retained to demonstrate the processing order. When external evidence is access restricted, only legitimate source identifiers and content summaries are retained.

[0200] After a learner deletes a session, they can delete or de-identify the main text and display projection; the statistics system only retains structured events without main text. The deletion operation does not change confirmed errors to unconfirmed, nor does it copy already published error content to the deletion log. After backup and recovery, the projection is rebuilt based on the error correction version and release number; outdated error correction displays cannot be restored.

[0201] End-to-end concurrency example

[0202] The learner questions the formula span in response version four, and event A is linked to summary B. The numerical validator and unit validator execute in parallel, both confirming the error; the three-state module generates version one, confirming the error. The correction generator proposes a new formula and passes both types of validation. Before writing, another event only modifies irrelevant paragraphs in the response and generates version five.

[0203] The system, based on the span summary mapping rules, found that the target formula's content and position mapping remained unchanged in version five, but still did not directly use the old write. It established a reconfirmation record for version five, compared the task version, span summary, and evidence applicability, and generated a correction transaction bound to version five. If irrelevant edits caused the position mapping to be non-unique, it remained pending location. This process ensured that asynchronous correction would not overwrite the content of the new version.

[0204] Scalable Validator Protocol

[0205] Adding a new validator requires registering its input mode, output mode, applicable tasks, required permissions, version, and failure semantics. Failure semantics explicitly distinguish between unsupported, insufficient input, execution failure, and uncertain conclusion. The orchestrator only assigns tasks explicitly supported by the validator and verifies the returned target span summary and task version.

[0206] Validator protocols can be implemented via message queues, synchronous interfaces, or local functions, but the results are all converted to the same evidence node structure. After a validator is updated, the new version is used, while old events still reference the old version's results. High-risk validators can be configured for dual execution or deterministic verification, but cannot read the entire online session for ease of deployment.

[0207] Reference three-state program

[0208] The program reads the target span location status, the list of necessary fields, and the validator results. If the target is not unique or a necessary field is missing, it returns an uncertain reason directly; if no applicable validator succeeds, it returns uncertain; if there are unresolved conflicts between the results, it returns uncertain. Only when a complete set of evidence explicitly refutes the original span will it return a confirmed error; only when complete evidence explicitly supports the original span and responds to the reasons for the challenge will it return an unconfirmed challenge.

[0209] The return value includes the conclusion version, rule version, evidence graph summary, and reason code. Subsequent correction procedures only accept confirmed error states, explanation procedures only accept unconfirmed challenge states, and the manual queue accepts indeterminate states. The caller cannot replace enumerated values ​​with free text, nor can it omit the evidence graph summary.

[0210] Error correction and release invariants

[0211] Each published correction is bound to a unique challenge event, target response version, original span summary, correction summary, and bug-correction version; if the target response changes, the old correction will not be automatically applied; any uncertain event will not modify the original bug statistics and learning status; any confirmed bug event will not have its replacement text published until the correction is verified.

[0212] The audit task can scan message projections and correction tables to verify that each correction in the projection has a success condition written to the record. If a correction with no record is found or the version is inconsistent, the projection reverts to the original immutable message and displays a pending verification status, instead of selecting a potentially incorrect correction to continue displaying.

[0213] Pattern Evolution and Compatibility

[0214] When adding a new challenge type or validator, register the task mode and failure semantics. Existing events continue to use the old mapping rules. When the target span representation is upgraded from a character range to a structured path, the migration record simultaneously saves both representations and a content summary; events that cannot be uniquely migrated enter the pending localization stage.

[0215] When older clients do not support error correction flags, the server can return a corrected visible message and an error correction presence flag, but will still retain the original span mapping. Clients cannot request old error text as current fact by not sending an error correction version; this should be used for separate authorized purposes when historical auditing is required.

[0216] System, device and storage medium implementation

[0217] The system of claim 7 may consist of microservices, modular monoliths, or edge nodes. The electronic device of claim 9 includes at least one processor, memory, network interface, and system clock; when the program in the memory is executed by the processor, steps S101 to S106 are implemented. The medium of claim 10 may be a non-transitory computer-readable medium, whose program instructions include object parsing, version comparison, state calculation, generation request, delivery review, and audit write instructions.

[0218] Reproducible verification scheme

[0219] The following validations can be performed in an isolated environment that does not rely on real user data:

[0220] 1. For inquiries containing explicit citations and step identifiers, verify the target message version and span location results.

[0221] 2. Scan for prohibited fields in the isolation verification exchange and verify that the service model does not exist. Self-evaluation text is then used to address any questions raised.

[0222] 3. Construct scenarios with sufficient evidence, insufficient evidence, and conflicting evidence, and verify the three-state mapping.

[0223] 4. During the verification process, update the target response version and verify that old error correction records have not been written to the new version.

[0224] 5. Submitting the same idempotent key repeatedly will only result in one valid error correction version and one statistical event.

[0225] Each verification records the input constructor method, object version, rule version, server time, concurrency level, expected state, and actual state. Verifications not yet executed do not record numerical results; this invention does not rely on fabricated experimental data.

Claims

1. An artificial intelligence output verification and error correction method, characterized in that, Executed by at least one processor, including: S101, detect AI error challenges in learner messages and solidify the challenged previous outputs or steps into challenge events with target response versions and target spans; S102. Construct an isolated verification exchange that includes the original task, target span, learner's reasons for questioning, and limited context, excluding the service model's self-evaluation text after questioning. S103. Submit the isolated verification exchange to at least one of the following: independent prompt context, independent model instance, deterministic validator, or external source of evidence; S104. Based on the completeness of evidence, conflict status, and verification results, the server maps the status to confirmed AI error, unconfirmed question, or uncertain status. S105. When an error is confirmed, a correction span is generated; when no error is confirmed, an evidence explanation is generated; when uncertain, the original record is retained and marked for verification. S106. Write the execution conditions with the idempotent key of the questioning event and the target response version, and save the original span-corrected span mapping and error correction version.

2. The method according to claim 1, characterized in that, The target span is determined by the target message identifier, reference relationship, character or token range and semantic positioning result, and is written into the challenge event along with the target response version.

3. The method according to claim 1, characterized in that, The isolation verification exchange settings include allowed and prohibited fields, and do not use the apology, defense, or self-evaluation text generated by the service model after receiving a challenge as verification evidence.

4. The method according to claim 1, characterized in that, When verification services are abnormal, evidence is insufficient, or different evidence sources conflict, the server-side evidence integrity rules will map the result to an uncertain state, and verification failure will not be mapped to an unconfirmed challenge.

5. The method according to claim 1, characterized in that, When an AI error is confirmed, the original span, the corrected span, and the evidence citations are saved; in uncertain states, the original error statistics, learning status, or learner evaluations are not modified.

6. The method according to claim 1, characterized in that, Writes are performed based on the idempotent key of the challenge event, the target response version, and the current correction version. Only one valid correction version is generated for the same challenge event, and writes are rejected when the target version changes.

7. An artificial intelligence output verification and error correction system, characterized in that, The system includes a challenge detection module, a target location module, a verification exchange module, an isolation verification module, a three-state decision module, and an error correction audit module. The challenge detection module and the target location module are configured to generate challenge events that bind the target response version and the target span. The verification exchange module and the isolation verification module are configured to construct an isolation verification exchange of self-evaluation text after excluding challenges from the service model. The three-state decision module is configured to map three-state conclusions based on independent evidence. The error correction audit module is configured to write span-level error correction records based on the event idempotency key and the target response version condition.

8. The system according to claim 7, characterized in that, The isolation verification module only provides the verifier with the set of allowed fields and excludes the self-evaluation text after service model questioning; the three-state decision module maps insufficient evidence or conflict to an uncertain state; and the error correction audit module writes span-level error correction records based on the event idempotency key and the target response version condition.

9. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images