A candidate knowledge generation and credible handover method and system based on engineering evidence snapshots and knowledge assumption adjudication

Abstract

This invention relates to engineering knowledge data processing, and discloses a method and system for candidate knowledge generation and trusted transfer based on engineering evidence snapshots and knowledge hypothesis adjudication. The processor acquires standardized engineering evidence units, establishes knowledge formation context snapshots and engineering evidence participation snapshots, generates a set of knowledge hypotheses and a relationship graph, and forms knowledge formation decisions based on evidence support, effect correlation, hypothesis conflict, boundary integrity, and cross-sample stability, generating valuable knowledge candidates. The system calculates the seven-dimensional trusted state of the candidates, and combines candidate conflict decisions, trusted transfer fingerprints, and interface compatibility verification to form a joint access control system; subsequent knowledge governance input eligibility is granted only when the interface is actually successfully written. The system also performs isolated replay, difference attribution, and candidate version evolution based on immutable snapshots.

Description

Technical Field

[0001] This invention relates to the fields of computer data processing, engineering knowledge engineering, engineering value analysis, graph structure relationship determination, state machine control, and replayable computing, and particularly to a method, system, electronic device, and non-transitory computer-readable storage medium for candidate knowledge generation and trusted transfer based on engineering evidence snapshots and knowledge hypothesis adjudication.

[0002] This invention takes a standardized engineering evidence unit that has been formed and has evidence identification, source binding, engineering object binding, data version and evidence summary as input, and protects the candidate knowledge formation control before formal knowledge governance. It does not re-execute the original data source location, engineering object identification, field normalization, unit conversion or standardized engineering evidence unit generation within the process of this invention. Background Technology

[0003] 2.1 The technical gap between existing standardized engineering evidence and the formation of candidate knowledge

[0004] The engineering construction system can form standardized engineering evidence units that are linked to projects, individual projects, unit projects, specialties, lists of items, materials, equipment, technical parameters, and engineering outcome indicators. These evidence units address the traceability issues of evidence content, source, object, and version, but they do not automatically determine which type of knowledge should be formed, which evidence should be used, how to handle multiple competing interpretations, or whether candidates can enter the subsequent knowledge governance process.

[0005] If the processor directly forms knowledge conclusions based on a single piece of evidence or a single model output, it will be difficult to reproduce historical conclusions when the scope of evidence selection, applicable boundaries, formation rules, and versions change; conflicting candidates may also enter the formal knowledge governance system without completing adjudication and credibility verification.

[0006] 2.2 Existing technologies lack the context and evidence necessary for freezing [the data / process].

[0007] The same set of standardized engineering evidence may support different conclusions depending on the scope of different engineering objects, time periods, target candidate knowledge types, constraint versions, and processing versions. Existing processing methods typically only save query conditions or result sets, lacking a mechanism to freeze the current formation boundary, actual participation evidence, and their binding relationships as objects that cannot be modified in situ.

[0008] 2.3 Existing technologies lack multi-hypothesis relationship adjudication and dual-state access control.

[0009] Existing systems typically output a single candidate or a continuous score, making it difficult to simultaneously express supporting evidence, effect correlations, competing relationships, boundary constraints, and cross-sample stability. Furthermore, candidate generation permission and transfer permission may be controlled by the same state or the same score, leading to the mistaken assumption that a candidate is ready for formal transfer as soon as it has been generated.

[0010] 2.4 Existing technologies lack a closed loop for candidate domain conflict, replay, and evolution.

[0011] Multiple candidates that have not yet entered the formal knowledge governance process may conflict in terms of object scope, applicable conditions, variable sources, candidate actions, or effect outputs. Without candidate conflict records, handover fingerprints, replay packages, and immutable snapshot evolution rules, the system cannot determine the cause of the block, reproduce the formation process, or explain the differences between the old and new candidate versions. Summary of the Invention

[0012] 3.1 Technical problems to be solved

[0013] This invention aims to address the technical problems of existing standardized engineering evidence lacking a boundary formation mechanism, evidence freezing mechanism, multi-hypothesis machine adjudication mechanism, candidate credible state mechanism, candidate conflict control mechanism, credible transfer record mechanism, and replayable evolution mechanism before entering formal knowledge governance.

[0014] 3.2 Technical Solution

[0015] step Processing content S101 Obtain existing standardized engineering evidence units; each evidence unit must have at least an evidence identifier, source binding, engineering object binding, data version, and evidence summary, without modifying its content or existing binding relationships. S102 Create a knowledge formation context snapshot, bind the scope of the project object, the scope of evidence selection, the time range, the target candidate knowledge type, the constraint set, the constraint version, and the processing version, and freeze the snapshot. S103 Based on the knowledge-forming context snapshot, perform scope, completeness, and version checks on existing standardized engineering evidence units; add evidence that passes the check to the evidence participation set, exclude evidence that fails the check, and record the evidence identifier, exclusion reason code, and check rule version. S104 Calculate evidence participation summaries for evidence participation sets, exclusion records, and binding relationships, and generate engineering evidence participation snapshots in the FROZEN state; after freezing, do not modify participating evidence, exclusion records, or binding relationships in situ. S105 Based on engineering evidence, a set of knowledge hypotheses and a knowledge hypothesis relationship graph are generated from snapshots. The judgment values ​​of evidence support, effect correlation, knowledge hypothesis conflict, boundary integrity, and cross-sample stability are calculated, and the machine state is mapped according to the judgment rule version. S106 Generate knowledge hypothesis judgment records and knowledge formation decisions; the knowledge formation decisions transition sequentially between the PENDING, EVALUATING, CONFIRMED, and CANDIDATE_GENERATED states. S107 When the knowledge formation decision is CONFIRMED, a valuable knowledge candidate is generated, the candidate is persisted and bound to the context snapshot, evidence participation snapshot, hypothesis set, relational graph and formation decision, and then the knowledge formation decision is set to CANDIDATE_GENERATED. S108 After candidate generation, a seven-dimensional candidate knowledge credible state vector and a candidate knowledge credible state transition decision are formed; the seven-dimensional state includes evidence, context, pattern, effect, boundary, stability and version consistency state. S109 Perform candidate conflict comparison within the candidate domain to generate candidate conflict relationship records and candidate conflict decision records; at the same time, generate trusted transfer fingerprints and TransferInterfaceCompatibilityCheckRecord to verify the target interface, target interface version, target data mode version, and candidate payload mode version. S110 When the joint access control is satisfied, the candidate trusted state is changed to TRANSFER_READY and the target knowledge governance interface is called; the actual interface call or write result is received and a KnowledgeTransferRecord is generated. Formal knowledge governance input eligibility is granted only when the write is successful; if the write fails, the reason for the failure is recorded and eligibility is not granted.

[0016] Knowledge formation decisions only control the generation of valuable knowledge candidates, not their transfer. The candidate trust states are, in order, INITIAL, EVALUATING, TRUST_SUPPORTED, TRANSFER_READY, and INVALIDATED. TRANSFER_READY is controlled by independent candidate trust state transition decisions.

[0017] When each basic trust dimension has reached a supported, ready, or stable state, but candidate conflict handling, trusted handover fingerprint review, or target interface compatibility verification has not been fully completed, the candidate trust status enters TRUST_SUPPORTED; when any pre-handover verification has been completed but failed, the candidate remains TRUST_SUPPORTED and records the corresponding blocking reason, and must not enter TRANSFER_READY; when the failure result is determined to be unrecoverable, or the candidate basis, knowledge formation decision, or candidate version becomes invalid, the candidate trust status is converted to INVALIDATED.

[0018] TRANSFER_READY requires at least the following: EvidenceTrustState, PatternTrustState, and EffectTrustState are all SUPPORTED; ContextTrustState, BoundaryTrustState, and VersionConsistencyState are all READY; StabilityTrustState is STABLE; the knowledge formation decision is CANDIDATE_GENERATED; there are no unhandled blocking candidate conflicts; the trusted handover fingerprint is consistent; and the target interface and data schema are compatible. Reaching TRANSFER_READY only indicates that a handover call is allowed; only when the target knowledge governance interface actually returns a successful write result is the candidate granted the qualification to enter the formal knowledge governance process.

[0019] 3.3 Systems, electronic devices, and storage media

[0020] The present invention also provides a corresponding system, including an existing engineering evidence acquisition module, a knowledge formation context construction module, an evidence participation selection and freezing module, a knowledge hypothesis set and relationship graph construction module, a knowledge hypothesis adjudication and formation decision module, a value knowledge candidate generation module, a candidate trustworthy state control module, a candidate conflict handling module, a trustworthy handover control module, a candidate replay module, and a candidate version evolution module.

[0021] The present invention also provides an electronic device and a non-transitory computer-readable storage medium, wherein the above steps are performed when a processor executes a computer program in the memory or medium.

[0022] 3.4 Beneficial Effects

[0023] This invention fixes the boundaries and participation evidence of a candidate formation through two immutable snapshots, processes multiple competing hypotheses through relationship graphs and machine state mapping, eliminates the circular dependency between candidate generation and handover permission through independent formation decision state machines and candidate trust state machines, and achieves blocking, reproducible and attributable candidate knowledge formation control through candidate conflict records, trust handover fingerprints, interface compatibility verification, replay packets and candidate version relationships. Attached Figure Description

[0024] Figure 1 This is a flowchart of the overall process for candidate knowledge generation and trusted transfer.

[0025] Figure 2 To create contextual snapshots of knowledge and engineering evidence, participate in the snapshot relationship graph.

[0026] Figure 3 A flowchart for screening existing standardized engineering evidence, excluding records, and participating in snapshot freezing.

[0027] Figure 4 This is a structural diagram of the knowledge hypothesis set and the knowledge hypothesis relationship diagram.

[0028] Figure 5 This is a flowchart of knowledge hypothesis judgment values, state mapping, and knowledge formation decision-making process.

[0029] Figure 6 A state machine diagram for knowledge formation and decision-making is generated.

[0030] Figure 7 This represents a seven-dimensional candidate knowledge trusted state vector and a candidate trusted state machine diagram.

[0031] Figure 8 A joint access control diagram consisting of candidate conflict, handover fingerprint, and interface compatibility verification.

[0032] Figure 9 A flowchart for knowledge transfer record generation and failure handling.

[0033] Figure 10 A flowchart illustrating the evolution of candidate replay, difference attribution, and immutable candidate versions. Detailed Implementation

[0034] The present invention will now be described in conjunction with the accompanying drawings and embodiments. The identifiers, values, thresholds, and interface names used in the embodiments are illustrative data, intended to demonstrate the executable record chain and state transitions of the processor, and do not represent actual project performance or experimental conclusions, nor do they limit the scope of protection.

[0035] 5.1 Overall Processing Boundaries and Immutable Rules

[0036] Standardized engineering evidence units have already been formed before this method begins. This method only reads their content, binding relationships, version, and summary, and performs screening and checks based on the knowledge-forming context. Any changes in the selection results, exclusion reasons, or context boundaries are expressed by generating a new snapshot, without modifying the historical FROZEN snapshot.

[0037] Value knowledge candidates are those that precede formal knowledge governance. Only successful knowledge transfer records that actually return a successful write result from the target knowledge governance interface are granted the candidate the qualification to enter the target knowledge governance process; failed knowledge transfer records are only used for auditing, fault attribution, and idempotent retries, and do not grant the candidate the qualification to enter the process. Even if the transfer is successful, the record does not automatically make the candidate a formal knowledge content version, release configuration, or formal project output.

[0038] 5.2 Core Object Data Structure

[0039] object At least the fields to include Functions and Invariable Constraints KnowledgeFormationContextSnapshot contextSnapshotId; objectScope; evidenceSelectionScope; timeRange; targetCandidateType; constraintSet; constraintVersion; processingVersion; contextState; stateVersion; parentContextSnapshotId; exclusionPolicy; formedAt; contextDigest Limit the objects, evidence, time, target, and version boundaries of a single candidate formation; once FROZEN is applied, it cannot be modified in its original location. Engineering Evidence Unit evidenceId; sourceBinding; objectBinding; dataVersion; evidenceType; evidencePayloadRef; evidenceDigest; formedAt; immutableFlag The existing input object of this method will not be regenerated or rewritten in this method. Evidence Participation Record participationRecordId; evidenceId; contextSnapshotId; checkResult; exclusionReasonCode; checkRuleVersion; checkedAt; recordDigest Record whether evidence was included in this participation group and the reasons for exclusion. EvidenceParticipationSnapshot participationSnapshotId; contextSnapshotId; includedEvidenceIds; excludedParticipationRecordIds; sourceBindingDigest; objectBindingDigest; dataVersionSet; snapshotState; stateVersion; parentParticipationSnapshotId; formedAt; participationDigest Freeze the evidence collection, exclusion records, and binding relationships actually involved in the adjudication. KnowledgeHypothesis hypothesisId; hypothesisVersion; factorSet; targetResultIndicator; applicableConditionSet; exclusionConditionSet; effectHypothesis; supportEvidenceIds; counterEvidenceIds; hypothesisState; parentHypothesisId; hypothesisDigest Express a candidate interpretation that can be compared and adjudicated by the processor. KnowledgeHypothesisSet hypothesisSetId; contextSnapshotId; participationSnapshotId; hypothesisIds; setVersion; generationRuleVersion; formedAt; hypothesisSetDigest Save multiple competing hypotheses from the same formation task. HypothesisRelationGraph graphId;graphVersion;hypothesisNodeSet;evidenceNodeSet;resultNodeSet;supportEdgeSet;effectEdgeSet;competitionEdgeSet;boundaryEdgeSet;parentGraphId;formedAt;graphDigest Expressing hypotheses, evidence of participation, outcome indicators, competition, and boundary constraints. HypothesisDecisionRecord decisionRecordId; hypothesisId; supportValue; effectValue; hypothesisConflictValue; boundaryValue; stabilityValue; mappedSupportState; mappedEffectState; mappedConflictState; mappedBoundaryState; mappedStabilityState; thresholdSet; decisionRuleVersion; blockingReasons; formedAt; recordDigest Save the judgment value, threshold, state mapping and blocking reason. KnowledgeFormationDecision formationDecisionId; contextSnapshotId; participationSnapshotId; hypothesisSetId; graphId; targetHypothesisId; excludedHypothesisIds; decisionRecordIds; decisionConstraintSet; decisionRuleVersion; decisionState; stateVersion; parentDecisionId; formedAt; formationDecisionDigest Controls only candidate generation; status is PENDING, EVALUATING, CONFIRMED, or CANDIDATE_GENERATED. ValueKnowledgeCandidate candidateId; candidateVersion; candidateType; applicableObjectScope; triggerConditionSet; exclusionConditionSet; candidateAction; variableBindings; affectedObjects; expectedEffectModel; technicalConstraintSet; evidenceBindings; formationChainBindings; candidateState; parentCandidateVersion; formedAt; candidateDigest Save candidate content that has not yet entered the formal knowledge governance process and form a complete chain of bindings. CandidateTrustStateVector trustVectorId;candidateId;candidateVersion;EvidenceTrustState;ContextTrustState;PatternTrustState;EffectTrustState;BoundaryTrustState;StabilityTrustState;VersionConsistencyState;dimensionEvidenceRefs;mappingRuleVersion;stateVersion;blockingReasons;formedAt;trustStateDigest The seven-dimensional machine can determine the trustworthy state and does not replace state access control with a single continuous score. CandidateTrustTransitionDecision transitionDecisionId; candidateId; candidateVersion; previousTrustState; currentTrustState; trustVectorId; transitionConditions; pendingGateItems; blockingReasons; transitionRuleVersion; stateVersion; formedAt; transitionDigest Controls the conversions INITIAL, EVALUATING, TRUST_SUPPORTED, TRANSFER_READY, and INVALIDATED. CandidateConflictRelationRecord conflictRelationId;leftCandidateIdVersion;rightCandidateIdVersion;comparisonScope;overlapFields;conflictType;blockingLevel;comparisonRuleVersion;relationState;formedAt;relationDigest Record both candidates, comparison fields, conflict type, and blocking level. CandidateConflictDecisionRecord conflictDecisionId;relationIds;inputCandidateSetDigest;handlingAction;handlingState;retainedCandidateIds;rejectedCandidateIds;decisionRuleVersion;blockingResolvedFlag;outputCandidateSetDigest;formedAt;decisionDigest Handle the options of keeping, merging, prioritizing, splitting, or rejecting, and clearly define whether blocking resolves the issue. Transfer Fingerprint Record fingerprintRecordId;candidateIdVersion;contextDigest;participationDigest;hypothesisSetDigest;graphDigest;formationDecisionDigest;candidateDigest;trustStateDigest;transitionDigest;conflictDecisionDigest;schemaVersion;normalizationRuleVersion;digestAlgorithmVersion;fingerprint;verifiedAt;verificationResult A trusted handover fingerprint is formed by using a fixed field order, array sorting, and character encoding. TransferInterfaceCompatibilityCheckRecord compatibilityCheckRecordId; targetGovernanceInterfaceId; targetInterfaceVersion; targetSchemaVersion; candidatePayloadSchemaVersion; requiredFieldCheckResult; fieldTypeCheckResult; variableBindingCheckResult; compatibilityRuleVersion; compatibilityResult; failureReason; checkDigest; checkedAt Solidify interface-compatible access control records into replayable records; distinguish between unverified, compatible, and incompatible results. KnowledgeTransferRecord transferRecordId; transferAttemptId; candidateId; candidateVersion; targetGovernanceInterfaceId; targetInterfaceVersion; targetSchemaVersion; compatibilityCheckRecordId; transferFingerprint; payloadDigest; formationDecisionState; candidateTru stState; conflictResolutionState; interfaceCompatibilityResult; interfaceResponseCode; interfaceWriteResult; transferResult; failureReasonCode; retryIdempotencyKey; retryOfTransferRecordId; qualificationGrantedFlag; transferredAt; recordDigest Each record separately stores the handover attempt, compatibility record, actual write result, failure reason, idempotent retry relationship, and input qualification granting effect; qualification is granted only when the write is successful. CandidateFormationReplayPackage replayPackageId; contextSnapshotRef; participationSnapshotRef; hypothesisSetRef; graphRef; decisionRecordRefs; formationDecisionRef; candidateRef; trustVectorRef; transitionDecisionRef; conflict tDecisionRef; fingerprintRef; compatibilityCheckRecordRef; historicalTransferRecordRef; targetInterfaceVersionSnapshot; targetDataSchemaVersionSnapshot; packageVersion; packageDigest; formedAt Restore the candidate formation process prior to formal knowledge governance in isolated, read-only, or independent replay namespaces without generating side effects from writing to formal interfaces. ReplayTransferDecisionRecord replayTransferDecisionId; replayPackageId; historicalTransferRecordRef; simulatedCompatibilityResult; simulatedWriteResult; qualificationGrantedFlag; differenceDigest; formedAt Only the handover judgment and differences in the replay environment are saved; the formal write interface is not called, and the qualificationGrantedFlag is fixed to ungranted. CandidateReplayDeviationRecord deviationRecordId; replayPackageId; historicalCandidateVersion; replayCandidateVersion; deviationType; deviationObject; historicalDigest; replayDigest; reasonCode; ruleVersion; formedAt; deviationDigest Record the differences and attributions between the replay results and the historical results. CandidateEvolutionTriggerRecord triggerRecordId; sourceType; sourceRef; objectBinding; sourceVersion; triggerScope; triggerDigest; formedAt When engineering application feedback only triggers a re-inspection, the source, object, version, and summary are saved, and they are not used directly as the basis for unbound formation. CandidateFormationEvolutionDecision evolutionDecisionId; sourceCandidateVersion; changeScope; changeReason; evolutionType; newContextSnapshotId; newParticipationSnapshotId; newHypothesisSetId; newGraphId; newFormationDecisionId; ruleVersion; blockingReasons; formedAt; evolutionDigest The decision is made to expand, modify, split, replace, or discard the old version; first, a new snapshot is referenced and hypotheses and decisions are reformulated, and only after CONFIRMED is a new candidate version formed. CandidateFormationVersionRelation versionRelationId; sourceCandidateIdVersion; targetCandidateIdVersion; relationType; sourceContextSnapshotId; targetContextSnapshotId; sourceParticipationSnapshotId; targetParticipationSnapshotId; createdByEvolutionDecisionId; formedAt; relationDigest Establish candidate version relationships forming a chain; these are not version relationships of formal knowledge content.

[0040] 5.3 Relationship Graph Nodes, Edges, and Decision Matrix

[0041] Nodes or edges Key fields Technical meaning HypothesisNode hypothesisId, version, factorSet, conditionDigest, effectDigest It represents a knowledge hypothesis. EvidenceNode evidenceId, dataVersion, evidenceDigest, participationState Only existing evidence from the snapshots is cited. ResultNode resultIndicatorId, objectBinding, valueOrRange, unit, version Indicates the engineering outcome indicators that need to be explained. EvidenceSupportEdge evidenceId→hypothesisId; supportDirection; supportWeight; ruleVersion It indicates a relationship of support or dissent. EffectRelationEdge hypothesisId→resultIndicatorId; effectDirection; effectRange; modelVersion This indicates the relationship between the hypothesis and the outcome indicator. CompetitionEdge leftHypothesisId↔rightHypothesisId; conflictField; conflictLevel It indicates competition or mutual exclusion. Boundary Constraint Edge hypothesisId→conditionId; conditionType; requiredFlag Indicates the applicable or excluded boundary.

[0042] The EvidenceSupportMatrix stores support directions and weights according to hypotheses and evidence; the EffectRelationMatrix stores effect directions and correlation values ​​according to hypotheses and outcome metrics; and the ConflictMatrix stores conflict types and blocking levels according to hypothesis pairs. All matrices are bound to graph versions, calculation rule versions, and summaries.

[0043] 5.4 Mapping of Decision Values, Thresholds, and Machine States

[0044] Judgment item Input factor examples Machine state mapping Evidence Support Value Support for evidence integrity, independence of source, number of counter-evidence, and consistency of evidence versions Complete input that meets the support threshold → SUPPORTED; Complete input but does not meet the threshold → UNSUPPORTED; Input is missing → INCOMPLETE Effect correlation judgment value Consistency of effect direction, overlap rate of effect intervals, and correlation of target indicators If the input is complete and the effect threshold is met, the result is ASSOCIATED; if the input is complete but the effect threshold is not met, the result is UNASSOCIATED; if the required input is missing, no definite ASSOCIATED or UNASSOCIATED conclusion is output, and the corresponding effect confidence status is set to INCOMPLETE. Knowledge Assumption Conflict Judgment Value Mutually exclusive conditional hit, opposite variable actions, opposite effect directions If the conflict threshold is reached, the message will be CONFLICTED; otherwise, it will be NON_CONFLICTED. Boundary integrity determination value Coverage of required conditions, coverage of excluded conditions, number of missing variables Reaching the full threshold → COMPLETE; otherwise → INCOMPLETE Cross-sample stability determination value Consistency ratio, fluctuation range, and outlier ratio across project or object samples Once the stable threshold is reached, STABLE; otherwise, UNSTABLE.

[0045] A processor-executable knowledge hypothesis generation method is as follows: Read the engineering object binding, evidence type, field values ​​or ranges, units, source versions, and evidence summaries of each evidence unit in the engineering evidence participant snapshot; group the participating evidence according to the target result indicator and the scope of the engineering object; extract candidate influencing factors and common factor combinations from the evidence in the same group, forming an applicable condition set, an exclusion condition set, and an effect hypothesis, respectively; write supporting evidence identifiers, counter-evidence identifiers, and target result indicators into the knowledge hypothesis; calculate the hypothesis summary by sorting by field name and object identifier, generating a KnowledgeHypothesis with a version number; when the same formation task generates at least two comparable hypotheses, add them to the KnowledgeHypothesisSet, and establish evidence support edges, effect association edges, competing edges, and boundary constraint edges. The above process only reads the already formed standardized engineering evidence units and does not perform evidence unit generation.

[0046] A decision calculation method that does not rely on preset learning weights is as follows: Evidence support is determined by the ratio of the number of supporting evidence satisfying the source, object, version, and summary integrity checks to the total number of participating supporting and counter-evidence pieces; Effect correlation is determined by the ratio of the number of evidence whose direction aligns with the target result indicator and whose effect interval intersects with the number of participating evidence pieces with an effect field; Knowledge hypothesis conflict is determined by the ratio of the number of mutually exclusive conditions, opposite variable actions, or opposite effect directions hit to the total number of conflicting items checked; Boundary integrity is determined by the ratio of the number of assigned necessary applicable conditions, exclusion conditions, and variable binding items to the total number of necessary items specified in the rule version; Cross-sample stability is determined by the ratio of the number of samples satisfying the same applicable boundary and consistent direction to the number of valid samples included in the check. When the denominator is zero or a necessary input is missing, it is not replaced with zero but mapped to INCOMPLETE; all ratios, thresholds, comparison operators, and state mappings are saved by the decision rule version.

[0047] The decision rule version stores thresholds, comparison operators, missing value handling methods, rule priorities, and state mapping rules. For evidence support decisions, if the input is complete but does not meet the threshold, it is mapped to UNSUPPORTED; for effect association decisions, if the input is complete but does not meet the threshold, it is mapped to UNASSOCIATED; when the required input for either type of decision is missing, the corresponding confidence state is set to INCOMPLETE. All of the above states block TRANSFER_READY, but for different reasons. Any change in thresholds or mappings creates a new rule version, without rewriting historical knowledge hypothesis decision records.

[0048] 5.5 Non-cyclic dual-state machine and correct processing timing

[0049] state machine state Entry conditions Output or Limit Knowledge formation decision PENDING The task and necessary objects have been created. Candidates must not be generated. Knowledge formation decision EVALUATING Snapshot freeze complete and hypothetical ruling begins Records of the judgment must be kept and not transferred. Knowledge formation decision CONFIRMED The target assumption is that the formation threshold is met and there is no formation-level blockage. Allows the generation and persistence of value knowledge candidates. Knowledge formation decision CANDIDATE_GENERATED The candidate has been persisted and chain binding has been completed. Allow the commencement of candidate trusted state computation. Candidate Trusted State INITIAL Candidates have been generated, but the seven-dimensional state has not yet been computed. It must not be transferred. Candidate Trusted State EVALUATING Start calculating the seven-dimensional state The access control remains closed under any blocking state. Candidate Trusted State TRUST_SUPPORTED The seven-dimensional basic status meets the requirements, but conflict, fingerprint, or interface compatibility checks have not been fully completed; or any pre-handover check has been completed but failed and can still be fixed. The process cannot be transferred; if incomplete, it will wait for the access control item; if it fails, the reason for the block will be recorded and entry into TRANSFER_READY will be prohibited. Candidate Trusted State TRANSFER_READY All seven-dimensional state, conflict, fingerprint, and interface compatibility tests passed. Allows initiating API calls; input eligibility is granted only if the API is actually successfully written. Candidate Trusted State INVALIDATED Candidate failure, inconsistent chain formation, invalid candidate basis, or irreversible blockage in pre-transfer verification. Transfer is prohibited.

[0050] The processor executes the process strictly in the following order: CONFIRMED → Generate ValueKnowledgeCandidate → Persist and complete chain binding → CANDIDATE_GENERATED → Generate CandidateTrustStateVector and initialize the candidate trusted state to INITIAL → EVALUATING → TRUST_SUPPORTED → TRANSFER_READY. CandidateTrustStateVector must not be a prerequisite for entering CANDIDATE_GENERATED.

[0051] 5.6 Seven-Dimensional Trusted State and Handover Blocking Rules

[0052] State Dimension State value READY or SUPPORTED conditions EvidenceTrustState SUPPORTED / UNSUPPORTED / INCOMPLETE Input is complete and the evidence meets the threshold, which is called SUPPORTED; input is complete but does not meet the threshold, which is called UNSUPPORTED; input is missing, which is called INCOMPLETE. ContextTrustState READY / INCOMPLETE / VERSION_MISMATCH The candidate and frozen context boundaries are consistent. PatternTrustState (relation schema trust state) SUPPORTED / CONFLICTED The knowledge assumption relational structure does not contain any unresolved assumption conflicts; here, "schema" does not refer to the interface data schema. EffectTrustState SUPPORTED / UNSUPPORTED / INCOMPLETE Input is complete and the effect is relevant enough to reach the threshold, which is called SUPPORTED; input is complete but does not reach the threshold, which is called UNSUPPORTED; input is missing, which is called INCOMPLETE. BoundaryTrustState READY / INCOMPLETE Applicability, exclusion, and complete variable boundaries. StabilityTrustState STABLE / UNSTABLE Cross-sample stability determination reaches the rule threshold. VersionConsistencyState READY / VERSION_MISMATCH Context, participating evidence, graph, rules, model, and candidate version are compatible.

[0053] UNSUPPORTED, INCOMPLETE, CONFLICTED, UNSTABLE, or VERSION_MISMATCH are all transition blocking states. UNSUPPORTED indicates that the input for the decision is complete but the evidence or effect is clear and has not reached the threshold. INCOMPLETE indicates that the input required for the decision is missing. The reason for blocking is written to CandidateTrustStateVector and CandidateTrustTransitionDecision, and cannot be allowed to proceed directly by lowering a single score or skipping the state mapping.

[0054] 5.7 Candidate Conflict Comparison, Resolution, and Access Control

[0055] The candidate comparison scope is jointly determined by the target candidate knowledge type, overlapping engineering object scope, overlapping applicable or exclusion conditions, overlapping variable source bindings, and candidate action or effect output relationships. Once at least one comparison field is matched, the processor loads both candidate versions and forms a chain summary to perform the comparison.

[0056] Conflict Types Example of judgment condition Blocking rules Conditional conflict For the same object and candidate type, the applicable conditions and exclusion conditions overlap. When it affects the same operating range, it is considered a blocking effect. Variable dependency conflict Two candidates read or write the same variable and are required to be incompatible. Blocks when there is a reverse write or version incompatibility. Action conflict Candidate actions perform mutually exclusive changes on the same object Block before prioritization, splitting, or rejection is determined. Effect conflict The same object and conditions may produce opposite effects or have incompatible ranges. Blocking when it affects the handover conclusion. Substitution The new candidate statement replaces the old candidate, but the replacement boundary is incomplete. Blocking before the scope of replacement and version relationship are confirmed.

[0057] A blocking conflict is considered resolved only when the handlingState of the candidate conflict decision record is RESOLVED, the blockingResolvedFlag is true, and the output candidate set summary is consistent with the current candidate set. This record is read by the candidate trusted state transition decision and controls TRANSFER_READY.

[0058] 5.8 Trusted handover fingerprints, interface compatibility, and failure handling

[0059] The processor arranges the context digest, evidence participation digest, hypothesis set digest, relationship graph digest, formation decision digest, candidate digest, trusted state digest, state transition digest, and conflict decision digest in ascending order of field name or in a predetermined order. It sorts the set fields by object identifier and version, serializes them using UTF-8 or equivalent fixed encoding, and generates trusted handover fingerprints using SHA-256 or equivalent deterministic digest algorithms.

[0060] The target knowledge governance interface is identified by `targetGovernanceInterfaceId` and stores the target interface version, target data schema version, and candidate transfer payload schema version. Before calling the interface, the processor generates a `TransferInterfaceCompatibilityCheckRecord`, which stores the verification results for required fields, field types, variable source bindings, and compatibility rule versions. Candidate transfer payloads must include at least the candidate identifier and version, candidate content references or content, chain-forming references, seven-dimensional trusted state, conflict decision references, trusted transfer fingerprints, and payload digests.

[0061] Interface compatibility verification results and interface call or write results are recorded separately. The processor generates `transferAttemptId` and `retryIdempotencyKey` for each call, and receives `interfaceResponseCode` and `interfaceWriteResult`. Only when the target interface actually returns a successful write result is `KnowledgeTransferRecord.transferResult` recorded as `SUCCESS` and `qualificationGrantedFlag` as `granted`. In case of network errors, interface rejection, data schema incompatibility, digest inconsistency, or target service anomalies, `transferResult` is recorded as `FAILURE`, `qualificationGrantedFlag` is recorded as `not granted`, and `failureReasonCode` is recorded. Retrying generates a new `KnowledgeTransferRecord`, references the previous failed record using `retryOfTransferRecordId`, and reuses or associates it with an idempotent key, without modifying historical failed records.

[0062] 5.9 Snapshot Immutability, Candidate Replay, and Version Evolution

[0063] A new EvidenceParticipationSnapshot is generated when the evidence set changes; a new KnowledgeFormationContextSnapshot is generated when the scope of the project object, the scope of evidence selection, the time range, the target candidate type, the constraint version, or the processing version changes. Historical FROZEN snapshots must not be modified in situ.

[0064] After candidate evolution is triggered, the processor first generates a new KnowledgeFormationContextSnapshot or EvidenceParticipationSnapshot, then regenerates the KnowledgeHypothesisSet and HypothesisRelationGraph, re-executes the knowledge hypothesis determination, and generates a new KnowledgeFormationDecision. Only when the new knowledge formation decision reaches CONFIRMED is a new ValueKnowledgeCandidate version generated and a CandidateFormationVersionRelation established. The new candidate version then re-executes the seven-dimensional trusted state, candidate conflict, trusted transfer fingerprint, and transfer gate, and must not inherit the TRANSFER_READY state, successful knowledge transfer record, or input qualification of the historical candidate version. The candidate version relationship only describes the evolution of the candidate formation chain and does not belong to the formal knowledge content version relationship.

[0065] When engineering application feedback is only used to trigger candidate re-examination, the processor generates a versioned CandidateEvolutionTriggerRecord, saving the feedback source, engineering object binding, source version, trigger scope, and trigger summary. When engineering application feedback is directly used as the basis for forming new candidate content or effect models, a standardized engineering evidence unit with source fragment location, engineering object binding, source version binding, and deterministic summary is pre-formed by an independent evidence generation system. This method obtains the already formed standardized engineering evidence unit and incorporates it into the newly generated EvidenceParticipationSnapshot. Engineering application feedback that has not formed the above bindings and summaries must not directly rewrite valuable knowledge candidates, effect models, or historical frozen snapshots.

[0066] During replay, the `CandidateFormationReplayPackage.packageDigest` is first validated. Then, in an isolated replay environment, a read-only environment, or a separate replay namespace, the context, participation evidence, relationship graph, rules, and state objects are restored according to the package version. The replay process does not call the target knowledge governance interface with formal write side effects, or it calls the simulation interface without side effects. Its transfer output is a `ReplayTransferDecisionRecord`, which is only used for historical result comparison and does not form a formally valid `KnowledgeTransferRecord`, nor does it grant formal knowledge governance input eligibility. If the replay result differs from the historical result, a `CandidateReplayDeviationRecord` is generated, which does not overwrite historical candidates or historical transfer records.

[0067] 5.10 End-to-End Replayable Example

[0068] In an illustrative electromechanical engineering candidate knowledge formation task, the processor creates a knowledge formation context snapshot with contextSnapshotId=CTX-001 and stateVersion=1. The target candidate type is "Material Substitution Condition Rule," the engineering object scope is object OBJ-MEP-01, the evidence selection time range is T1 to T2, the constraint version is CV-3, and the processing version is PV-2. The context summary is denoted as DC-001.

[0069] Evidence identification Version Content Citation Notes Participation in inspection results EV-101 DV-5 Material price range evidence for object OBJ-MEP-01 INCLUDED EV-102 DV-2 Evidence of technical performance constraints of the same object INCLUDED EV-103 DV-4 Historical effect interval evidence under the same conditions INCLUDED EV-104 DV-1 Comparative evidence from different subjects and outside the time frame EXCLUDED: OUT_OF_SCOPE

[0070] The processor generates participationSnapshotId=EPS-001, includedEvidenceIds are EV-101, EV-102 and EV-103, excludes record EPR-104, saves EV-104 and reason code OUT_OF_SCOPE, snapshot status is FROZEN, and participating digest is DE-001.

[0071] Assumption illustrate Support value Effect value Conflict value Boundary values Stable value Mapping conclusions H-01 Price differences and technological constraints together support conditional substitution. 0.86 0.82 0.12 0.91 0.78 SUPPORTED / ASSOCIATED / NON_CONFLICTED / COMPLETE / STABLE H-02 Interpreting results solely from changes in quantities 0.61 0.58 0.18 0.72 0.66 UNSUPPORTED / UNASSOCIATED / NON_CONFLICTED / INCOMPLETE / UNSTABLE H-03 Direct substitution without distinguishing the scope of the object 0.55 0.69 0.74 0.43 0.52 UNSUPPORTED / UNASSOCIATED / CONFLICTED / INCOMPLETE / UNSTABLE

[0072] Version DR-1 of the decision rule specifies: a support value of 0.75 or higher is mapped to SUPPORTED; an effect value of 0.70 or higher is mapped to ASSOCIATED; a conflict value of 0.30 or higher is mapped to NON_CONFLICTED, and a value higher than 0.30 is mapped to CONFLICTED; a boundary value of 0.80 or higher is mapped to COMPLETE; and a stable value of 0.70 or higher is mapped to STABLE. The processor generates HypothesisDecisionRecords for the three hypotheses respectively, selecting H-01 as the target hypothesis, and H-02 and H-03 are added to the exclusion set.

[0073] KnowledgeFormationDecision FD-001 sequentially enters PENDING, EVALUATING, and CONFIRMED. The processor generates and persists candidate CAND-001 / V1, saving the candidate object range OBJ-MEP-01, trigger conditions, exclusion conditions, candidate actions, variable bindings, effect models, technical constraints, and evidence bindings from EV-101 to EV-103. After completing the binding with CTX-001, EPS-001, hypothesis set HS-001, relationship graph HG-001, and FD-001, FD-001 enters CANDIDATE_GENERATED.

[0074] In candidate trusted state vector TV-001, EvidenceTrustState, PatternTrustState, and EffectTrustState are SUPPORTED, ContextTrustState, BoundaryTrustState, and VersionConsistencyState are READY, and StabilityTrustState is STABLE. Candidate trusted states progress from INITIAL to EVALUATING; however, since candidate conflict and interface compatibility checks are not yet complete, they first enter TRUST_SUPPORTED.

[0075] The processor compares CAND-001 / V1 with CAND-007 / V2 within the comparison range, generating a candidate conflict relationship record CCR-001. The object ranges of the two partially overlap, but the candidate actions are not mutually exclusive; the relationship type is compatible, and the blocking level is NON_BLOCKING. Based on CCR-001, the processor generates a candidate conflict decision record CCD-001, with the processing action KEEP_BOTH, the processing status RESOLVED, and the blocking resolution flag set to true. The processor then binds CCR-001, CCD-001, and the processed candidate set summary to the trusted state transition and trusted handover fingerprint formation process of CAND-001 / V1.

[0076] The processor generates a fingerprint record TFR-001, saving DC-001, DE-001, hypothesis set summary, relationship graph summary, decision-forming summary, candidate summary, trusted state summary, state transition summary, and CCD-001 summary. It then uses normalization rule NR-1, UTF-8 encoding, and the SHA-256 algorithm to form the fingerprint FP-001. The processor generates a compatibility check record TIC-001: the target interface is candidateGovernanceIngest, the target interface version is 1, the target data mode version is 1, the candidate payload mode version is 1, all required fields, field types, and variable source binding checks pass, the compatibility rule version is ICR-1, and the compatibilityResult is COMPATIBLE.

[0077] After all departments pass the ban, the candidate trusted state enters TRANSFER_READY. The processor calls the target interface with the transfer attempt identifier TA-001 and idempotent key IK-001. The interface returns a response code 200 and a write success result. Based on this, the processor generates a KnowledgeTransferRecord KTR-001, with its candidate identifier and version being CAND-001 / V1, the trusted transfer fingerprint being FP-001, the transfer result being SUCCESS, and the qualificationGrantedFlag being granted. Only this successful record grants CAND-001 / V1 the qualification to enter the formal knowledge governance process. The above record and digest together constitute a replayable chain.

[0078] In another handover branch, the interface compatibility check record TIC-002 returns COMPATIBLE, but the first call to TA-002 times out and fails to achieve a successful write result. The processor generates a failure record KTR-002 with interfaceWriteResult set to FAILURE, failureReasonCode set to TIMEOUT, and qualificationGrantedFlag set to ungranted. The processor initiates a second call to TA-003 using the idempotent key IK-002, generating a new record KTR-003 and referencing KTR-002 with retryOfTransferRecordId. Only when the second call returns a successful write result is KTR-003's transferResult recorded as SUCCESS and input qualification granted; KTR-002 remains unmodifiable.

[0079] When evidence participation fails, the processor does not modify the evidence unit but generates an exclusion record. When the judgment input is complete but the evidence support value does not reach the threshold, EvidenceTrustState is UNSUPPORTED, and when the required input is missing, it is INCOMPLETE; both block the transfer. When the relational graph or summary version is inconsistent, VersionConsistencyState is VERSION_MISMATCH; when the cross-sample stability value does not reach the threshold, StabilityTrustState is UNSTABLE. When candidate conflict, fingerprint, or interface compatibility verification has been completed but failed and can still be repaired, the candidate remains TRUST_SUPPORTED and the reason for blocking is recorded; when the failed result is irrecoverable or the candidate basis is invalid, the candidate enters INVALIDATED.

[0080] 5.11 Implementation of Abnormal and Blocking Methods

[0081] When evidence participation in the check fails, the processor does not modify the evidence unit but generates an exclusion record; if the required evidence is insufficient, EvidenceTrustState is set to INCOMPLETE and transfer is blocked. When the relational graph or summary version is inconsistent, VersionConsistencyState is VERSION_MISMATCH. When the cross-sample stability value does not reach the threshold, StabilityTrustState is UNSTABLE. When candidate conflicts are unresolved, PatternTrustState can be CONFLICTED or the candidate trust state can remain TRUST_SUPPORTED; neither should enter TRANSFER_READY.

[0082] 5.12 System Deployment and Alternative Implementation Methods

[0083] The system can be deployed in enterprise private environments, cloud-based tenant-isolated environments, or monitoring computing environments. Existing standardized engineering evidence units can be stored in relational databases, document databases, graph databases, object storage, or event logs; relational graphs can be implemented using graph databases, adjacency lists, relational tables, sparse matrices, or in-memory graphs.

[0084] Knowledge hypotheses can be generated by rule induction, statistical analysis, vector retrieval, constrained generative models, knowledge graph reasoning, causal analysis, expert structured input, or combinations thereof, but they must enter the hypothesis set, relationship graph, decision record, decision formation, and candidate credible state control chain of this invention.

[0085] Knowledge transfer records with granted qualifications and successful transfer results can be used as input to an independent formal knowledge governance system; failed knowledge transfer records are only used for auditing, fault attribution, and retries. Subsequent systems can perform formal knowledge verification, content version freezing, release configuration, runtime feedback, or formal engineering output; these subsequent processes do not alter the immutability of the candidate domain objects and historical snapshots of this invention.

Claims

1. A method for generating and reliably transferring candidate knowledge based on engineering evidence snapshots and knowledge assumption adjudication, characterized in that, Executed by at least one processor of an electronic device, including: Acquire multiple standardized engineering evidence units that have been formed. Each standardized engineering evidence unit has at least an evidence identifier, source binding, engineering object binding, data version, and evidence summary. Create a knowledge formation context snapshot, which is used to limit the scope of engineering objects, the scope of evidence selection, the type of target candidate knowledge, the set of constraints, the constraint version, and the processing version corresponding to this candidate knowledge formation process; Based on the knowledge, a context snapshot is formed. From the multiple standardized engineering evidence units, engineering evidence units that participate in this candidate knowledge formation process are selected to form an evidence participation set, and the generated engineering evidence participation snapshot is frozen. Based on the aforementioned engineering evidence, a set of knowledge hypotheses is generated through snapshot generation, and a knowledge hypothesis relationship graph is constructed. Based on the knowledge formation context snapshot, the engineering evidence participation snapshot, and the knowledge hypothesis relationship graph, calculate the evidence support judgment value, effect association judgment value, knowledge hypothesis conflict judgment value, boundary integrity judgment value, and cross-sample stability judgment value corresponding to each knowledge hypothesis. Map each judgment value to a machine-decidable state according to the judgment rule version, and generate a knowledge formation decision to determine the target knowledge hypothesis. When the knowledge formation decision is in the CONFIRMED state, a candidate of valuable knowledge that has not yet entered the formal knowledge governance process is generated based on the target knowledge assumption, and the knowledge formation decision is converted to the CANDIDATE_GENERATED state; the candidate of valuable knowledge includes at least machine-executable applicable conditions, machine-executable exclusion conditions, variable and source binding, candidate knowledge content, effect model and evidence reference set, and is bound to the knowledge formation context snapshot, engineering evidence participation snapshot, knowledge assumption relationship diagram and knowledge formation decision; Generate a candidate knowledge credibility state vector of the value knowledge candidate, and generate a candidate knowledge credibility state transition decision based on the candidate knowledge credibility state vector; The candidate value knowledge is compared with other untransferred candidate value knowledge that have the same type as the target candidate knowledge and overlap in terms of engineering object scope, applicable conditions, exclusion conditions, variable source binding, or candidate effect output, and a candidate conflict relationship record is generated or updated. A candidate conflict decision record is generated based on the candidate conflict relationship record and the candidate conflict decision rule version, and it is determined whether there are any unprocessed blocking candidate conflicts based on the blocking identifier and conflict handling status in the candidate conflict decision record. A trusted transfer fingerprint is generated based on the summary and version information of the knowledge formation context snapshot, engineering evidence participation snapshot, knowledge hypothesis set, knowledge hypothesis relationship graph, knowledge formation decision, candidate value knowledge, candidate knowledge trusted state vector, and candidate knowledge trusted state transition decision. When the knowledge formation decision is in the CANDIDATE_GENERATED state, the current candidate trusted state in the candidate knowledge trusted state transition decision is in the TRANSFER_READY state, the trusted handover fingerprint verification is consistent, it is determined from the candidate conflict decision record that there are no unprocessed blocking candidate conflicts, and the target knowledge governance interface identifier, target interface version, and handover data mode version pass the compatibility verification, a candidate handover payload is allowed to be generated and the target knowledge governance interface is called to perform writing. A knowledge handover record is generated based on the interface call or writing result. Only when the target knowledge governance interface returns a successful writing result, the handover result of the knowledge handover record is set to successful and the valuable knowledge candidate is given the input qualification to enter the subsequent formal knowledge governance process. When the interface call or writing fails, the handover result of the knowledge handover record is set to failure and the reason for failure is recorded, and the input qualification is not granted. If any other access control condition is not met, the valuable knowledge candidate is prohibited from entering the subsequent formal knowledge governance process.

2. The method according to claim 1, characterized in that, The knowledge formation context snapshot includes context identifier, scope of engineering objects, scope of evidence selection, target candidate knowledge type, constraint set, constraint version, processing version, context state, and context summary; The context states include at least the CREATED state, BOUND state, FROZEN state, and USED_FOR_FORMATION state; The CREATED state represents knowledge forming a context snapshot, which is then created. The BOUND status indicates that the scope of the project object, the scope of evidence selection, the target candidate knowledge type, the constraint version, and the processing version have been bound together. The FROZEN state indicates that the boundaries of the knowledge forming a context snapshot have been determined and in-situ modification is not allowed; The USED_FOR_FORMATION state indicates that the knowledge formation context snapshot has been used as a constraint input for knowledge hypothesis adjudication and knowledge formation decision.

3. The method according to claim 1 or 2, characterized in that, The engineering evidence units selected from the plurality of standardized engineering evidence units to participate in this candidate knowledge formation process include: Standardized engineering evidence units with corresponding engineering object binding relationships are selected based on the scope of the engineering objects. Based on the aforementioned evidence selection range, standardized engineering evidence units that meet the requirements of source type, evidence type, time range, and data version are selected. Perform checks on the existence of evidence summaries, the validity of source bindings, the consistency of engineering object bindings, and the compatibility of data versions on the standardized engineering evidence units obtained from the screening process. Standardized engineering evidence units that pass the inspection are added to the evidence participation set, while standardized engineering evidence units that fail the inspection are excluded, and the corresponding reasons for exclusion are recorded. The selection and inspection do not change the content, source binding, engineering object binding, data version, or evidence summary of the standardized engineering evidence unit.

4. The method according to claim 1 or 3, characterized in that, The engineering evidence participation snapshot is used to freeze the set of evidence participants and their binding relationships that actually participated in this knowledge hypothesis adjudication and knowledge formation decision-making. The engineering evidence participation snapshot includes participation snapshot identifier, knowledge formation context identifier, participation evidence identifier set, participation evidence set summary, exclusion evidence identifier and exclusion reason mapping, engineering object binding relationship set, source binding relationship set, data version set, constraint version, processing version, snapshot status, and participation snapshot summary; The engineering evidence snapshot does not generate new standardized engineering evidence units, nor does it modify existing standardized engineering evidence units.

5. The method according to claim 4, characterized in that, Before freezing the generated engineering evidence for snapshot participation, a snapshot participation freeze verification is performed, which includes at least the following: The scope of the project objects is consistent with the binding relationship between the project objects corresponding to the evidence of participation; The scope of evidence selection should be consistent with the source type, type of evidence, time range, and data version of the evidence used. The set of evidence identifiers, the identifiers of excluded evidence, and the mapping of reasons for exclusion have all been determined; A summary of the evidence set has been generated; The constraint version and the processing version are already bound; When the snapshot freeze verification passes, the engineering evidence snapshot is set to FROZEN state. Once the engineering evidence participation snapshot is in the FROZEN state, it is prohibited to add, delete, or replace participating evidence in situ, and it is prohibited to modify the corresponding engineering object binding relationship, source binding relationship, and data version; if any of the above changes occur, a new engineering evidence participation snapshot will be generated.

6. The method according to claim 1 or 4, characterized in that, Based on the engineering evidence, the knowledge hypothesis set is generated through snapshot generation, including: Candidate influencing factors are extracted based on the characteristics, technical parameters, engineering result indicators, and effect feedback information of the engineering objects corresponding to the evidence involved. Multiple knowledge hypotheses are generated based on different candidate influencing factors, combinations of candidate influencing factors, or candidate causal paths. Multiple knowledge hypotheses that bind the same knowledge to form a context snapshot and the same engineering evidence to participate in the snapshot are grouped into the knowledge hypothesis set. The knowledge hypothesis set includes a knowledge hypothesis set identifier, a knowledge formation context identifier, an engineering evidence participation snapshot identifier, a knowledge hypothesis identifier set, a set version, and a set summary. Each knowledge hypothesis should include at least the hypothesis identifier, a set of candidate influencing factors, target engineering result indicators, applicable conditions, effect hypothesis, set of supporting evidence, hypothesis version, and hypothesis summary.

7. The method according to claim 6, characterized in that, The knowledge hypothesis relationship graph includes knowledge hypothesis nodes, evidence support edges, effect association edges, competition relationship edges, and boundary constraint edges. The evidence support edge is used to associate standardized engineering evidence units with corresponding knowledge assumptions; The effect association edge is used to associate knowledge assumptions with corresponding engineering result indicators; The competitive relationship edge is used to indicate that multiple knowledge hypotheses cannot be simultaneously true for the same engineering result indicator, that the explanations are mutually exclusive, or that the candidate action paths conflict with each other. The boundary constraint edges are used to associate knowledge assumptions with their applicable conditions, exclusion conditions, or the scope of the engineering object. Based on the knowledge hypothesis relationship graph, the evidence support judgment value, effect association judgment value, knowledge hypothesis conflict judgment value, boundary integrity judgment value, and cross-sample stability judgment value of each knowledge hypothesis are calculated, and mapped to the SUPPORTED or UNSUPPORTED state, ASSOCIATED or UNASSOCIATED state, CONFLICTED or NON_CONFLICTED state, COMPLETE or INCOMPLETE state, and STABLE or UNSTABLE state, respectively, according to the threshold range or combination judgment conditions specified in the judgment rule version. The judgment value, threshold range, mapping result, judgment rule version, and input summary together form the knowledge hypothesis judgment record.

8. The method according to claim 7, characterized in that, The knowledge formation decision includes a decision identifier, a knowledge formation context snapshot identifier, an engineering evidence participation snapshot identifier, a knowledge hypothesis set identifier, a knowledge hypothesis relationship diagram identifier, a knowledge hypothesis judgment record set, a target knowledge hypothesis, an excluded knowledge hypothesis set, a decision constraint set, a decision rule version, a decision status, a decision version, and a formed decision summary; The decision states include at least the PENDING state, EVALUATING state, CONFIRMED state, and CANDIDATE_GENERATED state. The PENDING state indicates that the knowledge formation decision object has been created but the knowledge hypothesis adjudication has not yet begun. The EVALUATING state indicates that a knowledge hypothesis ruling is being performed based on the knowledge hypothesis judgment record set; The CONFIRMED state indicates that the target knowledge assumption has been determined and the corresponding blocking decision constraints are satisfied. The CANDIDATE_GENERATED state indicates that valuable knowledge candidates have been generated based on the target knowledge hypothesis; The decision state does not include the candidate knowledge transfer permission state. Whether candidate knowledge can be transferred is independently controlled by the candidate knowledge trust state transition decision.

9. The method according to claim 8, characterized in that, Before generating the value knowledge candidates based on the target knowledge assumption, a decision fingerprint is generated; The decision fingerprint formation includes at least a knowledge formation context summary, a set of participating evidence summary, a set of knowledge assumptions summary, a knowledge assumption relationship graph summary, a set of knowledge assumption judgment records summary, a decision constraint summary, a decision rule version, and a decision formation summary. When each summary in the formation decision fingerprint is consistent with the corresponding summary bound when the knowledge formation decision is generated, and the knowledge formation decision is in the CONFIRMED state, the generation of the value knowledge candidate is allowed and the knowledge formation decision is converted to the CANDIDATE_GENERATED state. Otherwise, the generation of the aforementioned value knowledge candidate is rejected; The value knowledge candidate includes at least a candidate identifier, a candidate version, a target knowledge hypothesis identifier, an applicable engineering object scope, machine-executable applicable conditions, machine-executable exclusion conditions, candidate knowledge content, variable and source binding, an effect model, an evidence citation set, a decision fingerprint, and a candidate summary, and the value knowledge candidate does not belong to the formal knowledge content version.

10. The method according to claim 1 or 9, characterized in that, The candidate knowledge credibility state vector is used to represent the machine-determinable state of the candidate value knowledge before it enters the subsequent formal knowledge governance process, rather than just representing continuous numerical scores. The candidate knowledge credibility state vector includes at least the evidence credibility state, context credibility state, pattern credibility state, effect credibility state, boundary credibility state, stable credibility state, and version consistency state. Each state dimension is set according to the corresponding judgment value, knowledge hypothesis judgment record, blocking condition, and state mapping rule version. Specifically: when the evidence support judgment result is SUPPORTED, the evidence credibility state is set to SUPPORTED; when the effect association judgment result is ASSOCIATED, the effect credibility state is set to SUPPORTED; when the knowledge hypothesis conflict judgment result is NON_CONFLICTED, the pattern credibility state is set to SUPPORTED; when the boundary integrity judgment result is COMPLETE, the boundary credibility state is set to READY; when the cross-sample stability judgment result is STABLE, the stability credibility state is set to STABLE; when version verification passes, the version consistency state is set to READY; when the evidence support judgment result is UNSUPPORTED, the evidence credibility state is set to U. When the effect association determination result is UNASSOCIATED, the effect credibility status is set to UNSUPPORTED; when the input required for evidence or effect determination is incomplete, the corresponding credibility status is set to INCOMPLETE; when the knowledge hypothesis conflict determination result is CONFLICTED, the pattern credibility status is set to CONFLICTED; when the boundary integrity determination result is INCOMPLETE, the boundary credibility status is set to INCOMPLETE; when the cross-sample stability determination result is UNSTABLE, the stability credibility status is set to UNSTABLE; when the version verification fails, the version consistency status is set to VERSION_MISMATCH; the context credibility status is set to READY, INCOMPLETE, or VERSION_MISMATCH. The candidate knowledge trusted state vector includes a value knowledge candidate identifier, a candidate version, each state dimension and its corresponding judgment criteria, a state mapping rule version, a state vector version, and a trusted state summary.

11. The method according to claim 10, characterized in that, The candidate knowledge trusted state transition decision includes transition identifier, value knowledge candidate identifier, candidate version, state vector version, previous candidate trusted state, current candidate trusted state, state transition condition, state transition basis, blocking reason set, transition rule version, and transition summary; The candidate trusted states include at least the INITIAL state, EVALUATING state, TRUST_SUPPORTED state, TRANSFER_READY state, and INVALIDATED state; When the state transition determination is started based on the candidate knowledge trust state vector, the candidate trust state is changed from INITIAL state to EVALUATING state. When the evidence trust status, pattern trust status, and effect trust status are all SUPPORTED, the context trust status, boundary trust status, and version consistency status are all READY, and the stable trust status is STABLE, but at least one of the candidate conflict verification, trust transfer fingerprint verification, or target knowledge governance interface verification has not been completed, the candidate trust status will be converted to TRUST_SUPPORTED. When the evidence trustworthiness state, pattern trustworthiness state, and effect trustworthiness state in the candidate knowledge trustworthiness state vector are all SUPPORTED, the context trustworthiness state, boundary trustworthiness state, and version consistency state are all READY, the stable trustworthiness state is STABLE, the knowledge formation decision is in the CANDIDATE_GENERATED state, the trustworthy transfer fingerprint verification is consistent, there are no unprocessed blocking candidate conflicts, and the target knowledge governance interface identifier, target interface version, and transfer data pattern version all pass the compatibility verification, the candidate trustworthiness state is allowed to be converted to the TRANSFER_READY state; any blocking state dimension is UNSUPPORTED or INCOMPLE. When the state is TE, CONFLICTED, UNSTABLE, or VERSION_MISMATCH, it must not be converted to the TRANSFER_READY state. When all basic trust states in the candidate knowledge trust state vector have reached the corresponding support, ready, and stable states, but any pre-transfer verification has been completed and failed, the TRUST_SUPPORTED state is maintained, the corresponding blocking reason is recorded, and it must not be converted to the TRANSFER_READY state. When the failed pre-transfer verification is determined to be unrecoverable, or the candidate basis is revoked, the decision-making fails, or the candidate version is explicitly discarded, the candidate trust state is converted to the INVALIDATED state.

12. The method according to claim 11, characterized in that, When performing a trusted handover determination, a trusted handover fingerprint is generated; The trusted handover fingerprint includes at least the following: knowledge formation context summary, participation evidence set summary, knowledge hypothesis set summary, knowledge hypothesis relationship graph summary, knowledge hypothesis judgment record set summary, formation decision summary, formation decision fingerprint, candidate summary, trusted state summary, transition summary, and version set summary; Only when the knowledge formation decision is in the CANDIDATE_GENERATED state, the candidate trusted state is in the TRANSFER_READY state, the stable trusted state is STABLE, the trusted transfer fingerprint is consistent with the digest recalculated from the currently bound object and version, and it is determined from the candidate conflict decision record that there are no unprocessed blocking candidate conflicts for the value knowledge candidate, and the target knowledge governance interface identifier, target interface version, and transfer data mode version all pass the compatibility verification, a candidate transfer payload is generated and the target knowledge governance interface is called to perform writing, and a knowledge transfer record is generated based on the interface call or writing result; If the interface compatibility check fails, the candidate transfer payload will not be generated or written; if the interface call or writing fails, the transfer result of the knowledge transfer record will be set to failure and the reason for failure will be recorded. The knowledge transfer record includes a transfer record identifier, a transfer attempt identifier, a value knowledge candidate identifier, a candidate version, a target knowledge governance interface identifier, a target interface version, a transfer data pattern version, a candidate transfer payload summary, a trusted transfer fingerprint, a decision-making state, a candidate trusted state, a transfer time, an interface response code, an interface call or write result, a failure reason, a retry idempotency key, a qualification grant identifier, a transfer result, and a transfer record summary; Only when the target knowledge governance interface returns a write success result, the transfer result of the knowledge transfer record is set to success and the qualification granting identifier is set to granted, so that the valuable knowledge candidate obtains the input qualification to enter the subsequent formal knowledge governance process; When an interface call or write fails, the qualification granting flag is set to ungranted; the knowledge transfer record does not automatically make the valuable knowledge candidate become a formal knowledge content version, formal release configuration, or formal project output.

13. The method according to claim 9, characterized in that, After generating multiple candidate value knowledge that have not yet entered the formal knowledge governance process, a candidate conflict relationship record is generated for any two candidate value knowledge that meet the comparison range, and a candidate conflict relationship diagram is formed by the candidate knowledge nodes and multiple candidate conflict relationship records. The candidate conflict relationship record is used to describe a conflict relationship, compatible relationship, or candidate substitution relationship between two value knowledge candidates, and includes at least a relationship record identifier, a first candidate identifier, a second candidate identifier, a set of comparison dimensions, a relationship type, a relationship determination basis, a relationship rule version, and a relationship summary; the candidate conflict relationship graph includes candidate knowledge nodes and conflict relationship edges, compatible relationship edges, and candidate substitution relationship edges represented by the candidate conflict relationship record; The conflict relationship edge is used to indicate that there are interpretation conflicts, applicable condition conflicts, candidate effect conflicts, or variable dependency conflicts among multiple untransferred value knowledge candidates with the same target candidate knowledge type and overlapping engineering object scope, applicable conditions, exclusion conditions, variable source binding, or candidate effect output. The compatibility edge is used to indicate that multiple value knowledge candidates can be retained together within the candidate domain; The candidate substitution relation edge is used to indicate that a value knowledge candidate can substitute for another value knowledge candidate within the candidate domain; The candidate conflict relationship graph and the processing performed based on it do not establish knowledge relationships between official knowledge content versions, nor do they change the official knowledge registry, official release status, or official project output.

14. The method according to claim 13, characterized in that, Candidate conflict decision records are generated based on the candidate conflict relationship records and candidate conflict decision rule versions in the candidate conflict relationship graph. The candidate conflict decision record includes a conflict decision identifier, a candidate conflict relationship diagram identifier, a set of untransferred value knowledge candidates participating in the comparison, a set of comparison dimensions, a conflict relationship type, a blocking identifier, a conflict handling status, a conflict handling action, a handling basis, a decision rule version, a summary of the candidate set before handling, a summary of the candidate set after handling, and a conflict decision summary. The conflict handling actions include at least maintaining multiple value knowledge candidates, merging multiple value knowledge candidates, determining priority value knowledge candidates, splitting value knowledge candidates, or rejecting value knowledge candidates. When the blocking flag of a candidate conflict decision record indicates blocking and the conflict handling status indicates unhandled, it is determined that there is an unhandled blocking candidate conflict, and the corresponding value knowledge candidate is prohibited from being converted to the TRANSFER_READY state.

15. The method according to claim 1 or 12, characterized in that, A candidate knowledge formation replay package is generated, which is used to restore and re-execute the candidate knowledge formation process before the formal knowledge governance process. The candidate knowledge formation replay package includes a knowledge formation context snapshot, an engineering evidence participation snapshot, a set of knowledge hypotheses, a knowledge hypothesis relationship graph, a set of knowledge hypothesis judgment records, a knowledge formation decision, a candidate version of valuable knowledge, a candidate knowledge credible state vector, a candidate knowledge credible state transition decision, a formation decision fingerprint, a credible handover fingerprint, a set of candidate conflict decision records, and a set of corresponding rule versions. Before performing the replay, the candidate knowledge is used to perform the following checks on the replay package: context summary consistency check, participation evidence set summary consistency check, knowledge hypothesis set summary consistency check, relationship graph summary consistency check, decision formation summary consistency check, trusted state summary consistency check, and rule version availability check. When all verifications pass, the candidate knowledge formation process can be replayed in an isolated replay environment, a read-only environment, or an independent replay namespace. During the replay process, the target knowledge governance interface with formal write side effects is not called, or a simulation interface without side effects is used; The output of the replay is limited to replaying knowledge formation decisions, replaying valuable knowledge candidates, replaying the trustworthiness status of candidate knowledge, replaying trustworthy handover judgments, and replaying handover judgment records. The replay handover judgment records are only used for difference comparison and do not grant valuable knowledge candidates the qualification to enter the formal knowledge governance process. Furthermore, the replay does not restore or modify the version of the formal knowledge content, the formal release status, or the formal project output.

16. The method according to claim 15, characterized in that, Compare the replay output with the corresponding historical candidate knowledge formation results; When there is a difference between the two, a candidate replay difference record is generated; The candidate replay difference record includes a difference identifier, a candidate knowledge formation replay package identifier, a historical candidate version, a replay candidate version, a difference type, a difference object, a difference reason, a difference attribution rule version, and a difference summary; The types of differences include at least the following: differences in evidence of participation, differences in knowledge formation context, differences in knowledge hypothesis set, differences in knowledge hypothesis relationship diagram, differences in knowledge hypothesis judgment, differences in knowledge formation decision, differences in candidate credible state, differences in credible handover judgment, and differences in rule version. The candidate replay difference record does not directly modify the historical value knowledge candidate, but serves as input for generating a new candidate knowledge version or re-executing the candidate trust state determination.

17. The method according to claim 9 or 16, characterized in that, Candidate knowledge is generated to form evolutionary decisions based on newly added standardized engineering evidence units, engineering application feedback, candidate effect change information, candidate conflict change information, candidate credibility state change information, or candidate replay difference records; when a newly added standardized engineering evidence unit changes the participating evidence set, a new engineering evidence participation snapshot is generated; when the scope of the engineering object, the scope of evidence selection, the target candidate knowledge type, the constraint version, or the processing version changes, new knowledge is generated to form a context snapshot. Based on the candidate knowledge formation evolution decision, the newly generated engineering evidence participation snapshot or knowledge formation context snapshot, the knowledge hypothesis set and knowledge hypothesis relationship graph are regenerated, and the knowledge hypothesis judgment and knowledge formation decision are re-executed; when the regenerated knowledge formation decision reaches the CONFIRMED state, a new value knowledge candidate version is generated, and a candidate knowledge formation chain version relationship is established between the new value knowledge candidate version and the historical value knowledge candidate version. The candidate knowledge formation chain version relationship is at least bound to the corresponding knowledge formation context snapshot, engineering evidence participation snapshot, knowledge hypothesis set, knowledge formation decision, candidate knowledge credibility state vector, and change field set; The candidate knowledge formation evolution decision includes evolution identifier, original candidate version, new candidate version, scope of change, reason for change, evolution type, trigger record, evolution rule version, and evolution summary; The evolution types include at least extension, modification, splitting, candidate replacement, or candidate obsolescence; The new candidate versions of value knowledge and the version relationships of the candidate knowledge formation chain both belong to candidate domain objects prior to the formal knowledge governance process, and do not belong to formal knowledge content versions. They do not change the formal knowledge version relationships or formal release status. New candidate versions of value knowledge must not be formed by modifying historical knowledge formation context snapshots or engineering evidence in the FROZEN state in situ. The new candidate versions of value knowledge must not directly inherit the TRANSFER_READY state or knowledge transfer eligibility of historical candidate versions of value knowledge. Instead, they should be based on the snapshot bound to the new candidate version, the regenerated set of knowledge hypotheses, the knowledge hypothesis relationship diagram, and the knowledge formation decision. The process of determining the trustworthy state of candidate knowledge, state transition, candidate conflict verification, trustworthy transfer fingerprint verification, and trustworthy transfer judgment should be re-executed.

18. A candidate knowledge generation and trusted transfer system based on engineering evidence snapshots and knowledge hypothesis adjudication, characterized in that, include: An existing engineering evidence acquisition module is used to acquire standardized engineering evidence units that have been formed and have evidence identification, source binding, engineering object binding, data version and evidence summary; The knowledge formation context building module is used to create knowledge formation context snapshots and bind the scope of engineering objects, the scope of evidence selection, the target candidate knowledge type, the constraint version, and the processing version. The evidence participation selection and freezing module is used to select a set of evidence participation from existing standardized engineering evidence units, generate an engineering evidence participation snapshot, perform participation snapshot freeze verification, and prohibit in-situ modification of the participating evidence and its binding relationship after freezing. The knowledge hypothesis set and relationship graph construction module is used to generate a knowledge hypothesis set, construct a knowledge hypothesis relationship graph, and establish the association between knowledge hypotheses and participation evidence, engineering result indicators, competitive relationships, and boundary constraints. The knowledge hypothesis judgment and formation decision module is used to calculate the evidence support judgment value, effect correlation judgment value, knowledge hypothesis conflict judgment value, boundary integrity judgment value, and cross-sample stability judgment value. It maps the machine-decidable state according to the judgment rule version, generates knowledge hypothesis judgment records and knowledge formation decisions, and controls the transition from the CONFIRMED state to the CANDIDATE_GENERATED state without controlling the candidate handover. The value knowledge candidate generation module is used to generate value knowledge candidates that have not yet entered the formal knowledge governance process when the fingerprint of the formation decision is consistent and the knowledge formation decision is in the CONFIRMED state. The value knowledge candidates include at least machine-executable applicable conditions, machine-executable exclusion conditions, variable and source binding, candidate knowledge content, effect model and evidence reference set, and convert the knowledge formation decision into the CANDIDATE_GENERATED state. The candidate knowledge trust state control module is used to generate candidate knowledge trust state vectors, including stable trust states, and candidate knowledge trust state transition decisions. It controls the transitions between INITIAL, EVALUATING, TRUST_SUPPORTED, TRANSFER_READY, and INVALIDATED states. When the pre-transfer verification has been completed but failed, it maintains the TRUST_SUPPORTED state and records the reason for the blockage. When the failure is irreversible or the candidate basis is invalid, it transitions to the INVALIDATED state. It is allowed to enter the TRANSFER_READY state only when the evidence trust state, pattern trust state, and effect trust state are all SUPPORTED, the context trust state, boundary trust state, and version consistency state are all READY, the stable trust state is STABLE, the knowledge formation decision is in the CANDIDATE_GENERATED state, the trust transfer fingerprint verification is consistent, there are no unprocessed blocking candidate conflicts, and the target knowledge governance interface identifier, target interface version, and transfer data pattern version all pass the compatibility verification. The Trusted Transfer Control Module is used to perform joint access control judgment when the knowledge formation decision is in the CANDIDATE_GENERATED state, the candidate trusted state is in the TRANSFER_READY state, the stable trusted state is STABLE, the trusted transfer fingerprint verification is consistent, there are no unprocessed blocking candidate conflicts, and the target knowledge governance interface identifier, target interface version, and transfer data mode version all pass the compatibility verification. It generates candidate transfer payloads and calls the target knowledge governance interface to perform writing. It generates knowledge transfer records based on the interface call or writing results. If the interface compatibility verification fails, it refuses to generate or write the candidate transfer payloads. If the interface call or writing fails, it generates a transfer failure result and records the failure reason. It only sets the qualification granting identifier to the input qualification of the granted and valued knowledge candidate to enter the subsequent formal knowledge governance process when the target knowledge governance interface returns a successful writing result. The candidate conflict handling module is used to compare untransferred value knowledge candidates with the same target candidate knowledge type and overlapping scope of engineering objects, applicable conditions, exclusion conditions, variable source binding, or candidate effect output. It generates or updates candidate conflict relationship records within the candidate domain, constructs or updates candidate conflict relationship graphs from candidate knowledge nodes and multiple candidate conflict relationship records, generates candidate conflict decision records based on candidate conflict relationship records and candidate conflict decision rule versions, and determines whether there are unprocessed blocking candidate conflicts based on blocking identifiers and conflict handling status. The candidate knowledge formation replay module is used to restore the candidate knowledge formation process before the formal knowledge governance process in an isolated replay environment, read-only environment or independent replay namespace based on the candidate knowledge formation replay package. It performs replay verification, does not call the target knowledge governance interface with formal write side effects or uses the simulation interface without side effects, and generates replay handover judgment records and candidate replay difference records that are only used for difference comparison and are not given input qualifications. The candidate knowledge version evolution module is used to generate new engineering evidence participation snapshots when the set of participating evidence changes, and to generate new knowledge formation context snapshots when the scope of engineering objects, the scope of evidence selection, the type of target candidate knowledge, the constraint version, or the processing version changes. Based on these snapshots, a candidate knowledge formation evolution decision is generated, the knowledge hypothesis set and the knowledge hypothesis relationship diagram are regenerated, and the knowledge hypothesis judgment and knowledge formation decision are re-executed. When the regenerated knowledge formation decision reaches the CONFIRMED state, a new value knowledge candidate version and a candidate knowledge formation chain version relationship are generated. Historical snapshots must not be modified in situ. The new value knowledge candidate version must not inherit the TRANSFER_READY state or knowledge transfer qualification of the historical version, and the candidate knowledge trust status judgment, state transition, candidate conflict verification, trust transfer fingerprint verification, and trust transfer judgment should be re-executed. This module does not generate or modify the official knowledge content version, official release status, or official engineering output.

19. An electronic device comprising a processor, a memory, a communication interface, and a computer program stored in the memory and executable by the processor, characterized in that, When the processor executes the computer program, it causes the electronic device to perform the steps of the method according to any one of claims 1 to 17.

20. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the electronic device to perform the steps of the method according to any one of claims 1 to 17.

Images