An evidence-driven knowledge unit generation, verification and version evolution method and system for multi-level objects of engineering cost

Abstract

This invention discloses a method and system for generating, verifying, and evolving knowledge units driven by engineering cost evidence. The processor converts project data and professional knowledge into evidence units bound to objects and versions, generating knowledge candidates containing executable conditions, variable sources, effect models, and technical constraints. These candidates are then processed through relationship determination and admission verification to form knowledge content versions. Before publishing or activating, the scope, time, engineering output key, and current valid set are reviewed and atomically written to the initial state and activation record. A replayable publishing selection decision is formed for the engineering output key. The execution interface generates engineering quantities, materials, costs, or constraint results. Formal results are uniquely written to the formal channel after qualification verification, while shadow results are written to the shadow channel in an isolated environment. Feedback is provided to bind knowledge, publishing, project, selection decision, and result channels, first generating evolution signals, and then determining the content or publishing action.

Description

Technical Field

[0001] This invention relates to the fields of computer data processing, engineering cost digitization, knowledge engineering, versioning rules and model management, graph structure relationship analysis, and machine learning feedback governance. In particular, it relates to a method, system, electronic device, and computer-readable storage medium for evidence-driven knowledge unit generation, verification, controlled release, and version evolution of multi-level objects in engineering cost.

[0002] More specifically, this invention uses the processor of an electronic device to convert engineering files, engineering object data, calculation results, professional knowledge documents, and human decision-making records into standardized evidence units bound to engineering objects, hierarchical paths, contexts, and multiple versions; generates machine-executable value decision knowledge candidates; forms content layer relationships and performs release context conflict review before each release configuration is generated, activated, or replaced; freezes immutable knowledge content versions after candidates pass admission verification; the system forms a currently valid release set based on immutable release configurations, append-only state events, and activation records, and generates replayable release selection decision records; the execution interface generates verification results for changes in engineering quantities, material usage, cost indicators, or technical constraints based on engineering object fields, quantities, prices, technical parameters, and variable sources, and writes them through formal result channels and shadow isolation channels respectively.

[0003] The value decision knowledge unit can be implemented by conditional rules, variable binding, optimization actions, calculation formulas, statistical models, decision tables, knowledge graph subgraphs, constrained generative models, agent skill definitions, or combinations thereof; the implementation form is not limited to the core technology closed loop of this invention. Background Technology

[0004] 2.1 Technical Characteristics of Engineering Cost Value Decision-Making Knowledge

[0005] Construction cost valuation typically involves multiple levels of objects, including projects, individual projects, unit projects, specialties, lists of sub-items, measures, materials, equipment, quantities, prices, calculation results, and indicators. The same optimization action may have different applicable conditions, variable sources, technical constraints, and expected effects under different business types, regions, time periods, design stages, structural forms, project scales, and standard versions.

[0006] Value engineering knowledge is not simply a textual conclusion. Knowledge objects that can be reliably used by computers typically need to simultaneously express the applicable objects, project context, triggering conditions, exclusion conditions, optimization actions, affected objects, variable sources, expected effect model, functional and safety constraints, regulatory basis, and relationships with other knowledge. The absence of any key element can lead to mismatches, inexecutability, duplicate counting, relationship conflicts, or an inability to interpret historical conclusions.

[0007] Meanwhile, engineering knowledge is characterized by continuous change and the coexistence of multiple versions. The structure of project objects, source data, evidence patterns, condition interpretations, calculation models, standards and knowledge relationships may change, and the scope, mode, effective time and status of releases may change. Older versions of knowledge used in historical projects should be retained to interpret the analysis results at that time, while new versions should be re-validated before being used in new projects.

[0008] 2.2 Typical processing methods in existing technologies

[0009] Static rule base The rules are entered by experts and the projects are directly matched. Lack of evidence binding, relationship diagram, verification batches, and operational feedback loop Large model generation rules According to the text generation conditions or rule draft It is easy to lack control over project object boundaries, variable sources, and version consistency. Knowledge graph update Add or modify knowledge nodes and edges Typically, there is no direct control over whether rules can be matched, executed, published, or rolled back. Expert approval process The knowledge will be marked as available after manual review. The audit findings did not form a replayable closed loop with machine verification, input versions, and subsequent project feedback. Model feedback training Update model parameters using feedback It is difficult to explain the correspondence between specific knowledge versions, project objects, and specification versions. General Version Control Save old and new versions and change history It cannot be proven whether the version underwent relational verification and multi-level validation in the project.

[0010] The above methods often address only one aspect of rule generation, knowledge storage, expert review, model feedback, or version management, and cannot form a unified technology chain from multi-source engineering evidence to machine-executable knowledge versions, and then to runtime feedback and cross-project evolution.

[0011] 2.3 Computer technology problems that existing technologies need to solve

[0012] • How to convert engineering files, object data, calculation results, knowledge documents, and feedback records with different structures, locations, units, and versions into evidence units that are reproducible, comparable, and have a deterministic summary;

[0013] • How to ensure that the generated value decision knowledge candidates not only have textual descriptions, but also engineering object boundaries, machine-executable conditions, variable sources, expected effect models, and technical constraints;

[0014] • How to use machine fields to determine the duplication, inclusion, conflict, dependency, synergy, cascade, substitution and effect overlap between new candidates and existing knowledge, and form a safe pending closed loop when the relationship cannot be determined;

[0015] • How to automatically generate different candidate admission verification tasks based on different knowledge relationships, and separate the historical replay, independent samples, counterexamples and counterfactual verification before candidate approval, and the shadow evaluation after KnowledgeVersion is frozen into two stages with independent version binding;

[0016] • How to separate the candidate's verification sandbox eligibility from the formal operation eligibility of KnowledgeVersion and ReleaseVersion, and prevent models or actions that fail the eligibility verification from generating formal engineering calculation results through immutable state records and interface interception;

[0017] • How to make KnowledgeVersion and ReleaseVersion immutable content snapshots and immutable release configuration snapshots respectively, and express pause, shutdown, replacement and rollback with independent state events, activation records and replacement records;

[0018] • How to generate a replayable selection decision record when multiple release configuration versions hit the project at the same time, and select a unique official output version with stable gray-scale routing, range specificity, priority and deterministic disambiguation rules, and explain the unselected version and the shadow version;

[0019] • How to enable shadow models or optimization actions to be executed under frozen input snapshots, sandboxes or rollback transactions, independent namespaces and write barriers, avoiding modification of formal project objects, formal calculation results, formal process states or calling interfaces with external side effects; Summary of the Invention

[0020] 3.1 Purpose of the Invention

[0021] The purpose of this invention is to provide a method and system for evidence-driven knowledge unit generation, verification, controlled release, and version evolution for multi-level engineering cost objects, in order to solve the problems of difficulty in uniformly expressing multi-source engineering evidence, lack of engineering object and variable sources in generated knowledge, difficulty in determining knowledge relationships and duplicate benefits, non-replayability of the verification process, potential formal invocation of unverified knowledge, direct overwriting of old versions by runtime feedback, and lack of version and rollback boundaries in cross-project evolution.

[0022] This invention forms a computer control closed loop through engineering object and project context binding, deterministic evidence summarization, content layer relationships and conflict review during publication, candidate admission verification, knowledge content eligibility and publication status events, replayable publication selection decisions, formal / shadow result recording, and shadow execution isolation. This makes the knowledge generation, verification, freezing, publication, engineering calculation, feedback, and evolution processes executable, restrictable, replayable, traceable, and rollbackable.

[0023] 3.2 Overall Technical Solution

[0024] like Figure 1 and Figure 2 As shown, the method of the present invention is executed by at least one processor of an electronic device, and preferably includes the following steps:

[0025] S101 Obtain at least two types of project documents, project object data, calculation results, professional knowledge, specifications, or operational feedback source data. Original evidence set S102 Perform source classification, object and hierarchical path location, field unit normalization, project context and version binding, and generate a deterministic summary. VEEvidenceUnit S103 Aggregate multiple evidence units to generate applicable objects, trigger / exclusion conditions, variable bindings, optimization actions, impact models, and technical constraints. VEKnowledgeCandidate S104 Determine content layer relationships; perform release context conflict checks when planning the specific release scope. Knowledge relationship graph, relationship pending record, publication context conflict check record S105 Complete the candidate access verification, and calculate the shadow freeze access flag and the direct official release access flag respectively. Candidate admission verification batch, candidate control status record S106 Freeze knowledge content versions according to entry thresholds; handle initial generation and activation, reactivation of existing versions, and replacement releases separately; atomically write the corresponding record when conflict verification passes and the set remains unchanged. Knowledge content version, release configuration version, initial release control status record, release activation record S107 Generate release selection decisions for engineering output keys; generate PRE_EXECUTION qualification records before model or action loading, and PRE_WRITE qualification records before writing formal or shadow results. Release of decision-making records, execution of two-stage results and writing to eligibility records, official results records, and shadow results records. S108 First, calculate the evolution signal based on version binding feedback, and then determine the content, eligibility, release configuration, or release runtime control actions. Evolution signal recording, new candidate or additional state / activation recording

[0026] The new candidate does not directly overwrite existing knowledge content versions. Once a release configuration version is created, it cannot be modified in situ; the release running status is expressed by the append-only release control status record. Release context conflict checks are performed before generating a release configuration version, activating an existing release configuration version, or generating and activating a new release configuration version to replace an existing release configuration version, and the activation set version and set summary are bound during the check. Initial generation and activation, reactivation, and replacement releases use different atomic commit paths. The execution interface performs PRE_EXECUTION eligibility checks before the model or action is loaded, and PRE_WRITE eligibility checks before the result or formal object is written.

[0027] 3.3 Relationship between Core Model and Machine Control

[0028] The value decision-making knowledge processing model can be represented as follows:

[0029] K = H(E, C, O, V),

[0030] Where E represents the set of standardized evidence units, C represents the set of engineering contexts, O represents the set of engineering objects and hierarchical paths, V represents the set of bindings of objects, source data, evidence patterns, candidates, relationship diagrams, verification strategies, models, specifications and releases, etc., and K represents value decision knowledge candidates or knowledge versions.

[0031] A knowledge relationship diagram can be represented as:

[0032] KRG = (KN, KE, RV),

[0033] Wherein, KN represents the set of knowledge candidate and existing knowledge version nodes, KE represents the set of knowledge relationship edges, and RV represents the relationship determination strategy and relationship graph version.

[0034] This invention employs three independent control objects: candidate verification control, knowledge content eligibility, and release operation status. The candidate control status only manages verification matching, verification execution, and freezing eligibility; the knowledge content eligibility status controls new release citations, existing release operation, formal output, and shadow execution; the release control status uses append-only immutable records, and the legal status evolution is determined by comparing a monotonically increasing and unique status sequence number with the previous status version or digest.

[0035] CCS = Qc(RelationRecord, CandidateAdmissionValidationBatch); KQS = Qk(KnowledgeVersion, EvolutionSignalSet); RCS = Qr(ReleaseVersion, ReleaseControlStateRecord, ReleaseActivationRecord).

[0036] Here, CCS stands for CandidateControlStateVector, which only controls validationMatchAllowed, validationExecutionAllowed, and freezeAllowed in the validation sandbox or test project; KQS stands for KnowledgeQualificationStateVector, which controls knowledge content eligibility through newReleaseReferenceAllowed, existingReleaseRuntimeAllowed, formalOutputAllowed, and shadowExecutionAllowed; RCS represents the current release runtime state calculated from the immutable ReleaseControlStateRecord and ReleaseActivationRecord. Final eligibility for official operation must also be determined by ReleaseSelectionPolicyVersion, which selects the scope specificity, priority, coexistence, and result channel.

[0037] Cross-project evolution can be represented as:

[0038] ED = W(FeedbackSet, WindowRule, MetricVersion, EvolutionPolicy),

[0039] Among them, FeedbackSet represents the set of runtime feedback evidence bound to the specific knowledge version and project object version, WindowRule represents the evaluation window selection rule, MetricVersion represents the evaluation metric definition version, EvolutionPolicy represents the evolution strategy version, and ED represents new candidate or evolution decisions such as downgrading, pausing, retiring, and rolling back.

[0040] 3.4 Beneficial Effects

[0041] • By binding engineering objects, hierarchical paths, project contexts, and multiple versions, engineering data and expertise from different sources are transformed into replayable evidence units, avoiding the inability to locate the source and applicable boundaries by simply saving extracted text or final rules.

[0042] • By combining triggering conditions, exclusion conditions, variable sources, optimization actions, affected objects, expected effect models, and technical constraints into machine-executable knowledge candidates, knowledge can be stably matched and executed by the processor.

[0043] • By using versioned knowledge relationship graphs to make data-driven comparisons of the scope of objects, condition intervals, variables and action goals, technical constraints and expected effects, it is possible to identify duplication, inclusion, conflict, dependency, collaboration, cascading, substitution and duplicate benefits;

[0044] • By using relationship-driven candidate admission verification tasks, the historical replay, independent samples, counterexamples and counterfactual verification before candidate approval are separated from the shadow evaluation after KnowledgeVersion is frozen into two independent stages, avoiding confusion between the shadow running object and the approval sequence.

[0045] • By verifying eligibility through Candidate, content eligibility through KnowledgeVersion, and using the immutable ReleaseControlStateRecord, candidate testing, knowledge content eligibility, and release runtime status are separated, and a unique source of status is clearly defined.

[0046] • By using immutable KnowledgeVersion, immutable ReleaseVersion configuration, ReleaseControlStateRecord, ReleaseActivationRecord, and ReleaseSupersessionRecord, configuration changes, state changes, and replacement relationships are recorded separately without modifying historical snapshots;

[0047] • By using ReleaseSelectionPolicyVersion to determine a unique official output version and writing the shadow result to ShadowResultSet, multiple release versions are avoided from being executed repeatedly, output repeatedly, or overwriting the official project results;

[0048] • By re-entering the relationship and verifying the main chain, knowledge access controls are avoided through automated learning or manual modification. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating the overall process of evidence-driven knowledge generation, version release, feedback, and evolution.

[0050] Figure 2 This is a diagram showing the core technology objects and their relationships.

[0051] Figure 3 Flowchart for evidence standardization and object version binding.

[0052] Figure 4 A flowchart for generating candidate knowledge for value decisions.

[0053] Figure 5 This is a flowchart for determining content relationships, closing the pending issues, and reviewing conflicts in the publishing context.

[0054] Figure 6 This is a flowchart outlining the dual entry thresholds, release path, and initial state activation process.

[0055] Figure 7 A unique control flowchart for recording three types of control states and their sequence.

[0056] Figure 8 This is a flowchart for selecting release based on the project output key, pre-execution qualification verification, model or action execution, and pre-writing qualification verification.

[0057] Figure 9 Flowchart for performing pre-execution checks, freezing input, isolating execution, pre-write checks, and write barriers for shadow execution.

[0058] Figure 10 A flowchart for generating evolution signals and then determining evolution actions.

[0059] Figure 11 An atomic commit relationship graph for initial generation and activation, reactivation of existing release configurations, and activation of replacement release configurations.

[0060] Figure 12 This is a diagram showing the system module composition.

[0061] The numbers 101 to 1212 in the accompanying drawings are used only for the components or steps in the corresponding specification. Figure 1 A vertical six-node structure is adopted, and the same images, labels and return arrows are used directly with the abstract figures. Detailed Implementation

[0062] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. These embodiments are used to illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art can replace the database, programming language, parser, vector model, generative model, graph storage, task engine, summarization algorithm, and deployment structure without changing the engineering object and version binding, relationship graph determination, relationship-driven verification, machine control state, immutable knowledge version, and feedback evidence evolution main chain.

[0063] The engineering objects, candidate numbers, project numbers, status codes, and data described below are only abstract examples. The actual parameters, weights, and rule texts involved in the formulas or models may be stored as restricted configurations or trade secrets in the actual system.

[0064] 5.1 Core Terminology, Status Logs, and Version System

[0065] I. Core Terminology

[0066] Project cost objects Projects, individual projects, unit projects, specialties, lists of items, quantities, materials, equipment, prices, indicators, and calculation results can all be used to uniquely locate objects. Value Decision Knowledge Candidates Candidates that have not yet entered the formal knowledge registry are only eligible for matching, execution, and freezing in the verification environment. Knowledge content version A snapshot of immutable content including freeze conditions, variables, actions, effect models, technical constraints, evidence, relationship diagrams, and admission criteria. Release configuration version Reference a knowledge content version and save an immutable configuration snapshot of the range, mode, grayscale ratio, configuration validity range, compatibility requirements, and selection parameters, but do not save the runtime state. Release Context Conflict Validation Log Before generating or activating the release configuration, the target scope, time, project output key, content conflicts or effect overlaps, and the currently valid release set are reviewed, and immutable records of the activated set version and set summary are bound during verification. Publish control status log An append-only immutable state event that is bound to a release configuration version. Release activation record An immutable record that records ACTIVATE or DEACTIVATE actions, activation set version, previous set summary, subsequent set summary, commit status, and transaction identifier. Publish alternative relationship records Record the configuration replacement relationship between the old and new release configuration versions. Release selection strategy version The policy versions specify the scope specificity, priority, gray-scale routing, shadow coexistence, and deterministic disambiguation. Publish selection decision record For a project object, a knowledge identifier, and an engineering output key, save a replayable record of the candidate release set, conflict check set, status version, route bucket, unique official selection, shadow selection, and exclusion reason. Shadow execution isolation record Save records of frozen input snapshots, isolation methods, external calls, write targets, and side effect check results. Official results record / Shadow results record Save the project output key, output value, input snapshot summary, model version, result channel, result execution and write qualification record and version binding record. Results execution and entry into eligibility records It includes the eligibilityStage field; PRE_EXECUTION records control of execution eligibility before the model or action is loaded, and PRE_WRITE records control of write eligibility before the result or formal object is written.

[0067] II. Controlled Objects and Unique Source of State

[0068] Candidate control state record Value Decision Knowledge Candidates validationMatchAllowed, validationExecutionAllowed, freezeAllowed Determined by effectiveTime, unique stateSequence, and state record identifier; normal writes require comparison with the previous state version or digest. Knowledge Content Qualification Status Record Knowledge content version newReleaseReferenceAllowed, existingReleaseRuntimeAllowed, formalOutputAllowed, shadowExecutionAllowed Determined by effectiveTime, unique stateSequence, and state record identifier; normal writes require comparison with the previous state version or digest. Publish control status log Single release configuration version matchAllowed, executeAllowed, formalOutputAllowed, shadowOutputOnly Determined by effectiveTime, unique stateSequence, and state record identifier; normal writes require comparison with the previous state version or digest. Release activation record Release configuration version collection ACTIVATE / DEACTIVATE, activationSetVersion, collection summary Determine whether to enter the currently valid release set.

[0069] III. Version Collection

[0070] ObjectVersion Project object structure and hierarchical relationship version SourceDataVersion Original file, interface, governance, or feedback data version EvidenceSchemaVersion Evidence fields, units, and enumeration specification versions CandidateVersion Knowledge candidate content version RelationPolicyVersion Content layer relationship mapping strategy version RelationGraphVersion Knowledge nodes and content relationship edge versions CandidateAdmissionValidationBatchVersion Candidate Admission Verification Batch Version ShadowEvaluationBatchVersion Knowledge content version shadow evaluation batch version ModelVersion Computational, inference, or effects model versions SpecVersion Specifications and technical constraints version KnowledgeVersion Immutable knowledge content version ReleaseVersion Immutable release configuration snapshot version ReleaseControlStateVersion Immutable release state event version ReleaseActivationSetVersion Current valid release collection and activation record versions ReleaseSelectionPolicyVersion Release selection and canary routing policy version ReleaseSelectionDecisionVersion Release the version of the decision record. ResultSchemaVersion Official / Shadow Result Recording Mode Version FeedbackSchemaVersion Run feedback evidence mode version EvolutionPolicyVersion Signal calculation and action decision-making strategy version ReleaseContextConflictCheckRecordVersion Release Context Conflict Check Log Version ResultExecutionWriteEligibilityRecordVersion Result execution and writing to the eligibility record version

[0071] 5.2 Multi-source evidence units and contextual data structure

[0072] I. Classification of Evidence Types and Sources

[0073] ENGINEERING_FILE Export files from XML, Excel, PDF, Word, and BIM formats. File identifier, content fragment, path, summary, parsing version OBJECT_DATA Project, Item, Specialty, List, Material, Parameter, Indicator objectId, objectPath, field, unit, object version CALCULATION_RESULT Quantity, price, total price, indicators, model output Model version, input version, result version, computation path KNOWLEDGE_DOCUMENT Specifications, standards, drawing sets, industry articles, design guidelines Source, terms, publication date, validity status EXPERT_INPUT Structured data entry, review, and manual editing Personnel roles, values ​​before and after modification, reasons, and time. PROJECT_DECISION Accepted, Pending, Rejected, Accepted after Modification, Merged Decision status, rationale, object, and knowledge version ACTUAL_OUTCOME Actual cost, time, risk, quality, or implementation results Observation time, measurement diameter, and result version EXTERNAL_SERVICE External search, third-party models or data services Service identifier, request digest, response digest, model version

[0074] II. VEEvidenceUnitRecord

[0075] evidenceUnitId Unique identifier of evidence unit Required evidenceType Types of evidence sources Required sourceReference Original file, interface, document, or record identifier Required sourceFragment Original location, page number, node path, or field path suggestion projectId / objectId Related project and engineering object identifiers According to the type of evidence required objectType / objectPath Object type and hierarchical path Engineering evidence is required contextSnapshotId Related project context snapshot suggestion normalizedFieldMap Normalize fields, values, units, and enumerations Required sourceDataVersion Source data version Required objectVersion Project object version Engineering evidence is required modelVersion Model version used to generate or interpret evidence By type of evidence specVersionSet Related specifications and technical constraints versions When applicable acquisitionMethod Parsing, manual input, interface synchronization, model inference, etc. Required evidenceConfidence Level of credibility of evidence and reasons Required evidenceDigest Standardized content deterministic summary Required sensitivityLabel Public, internal, trade secret, restricted, etc. suggestion reviewState Not reviewed, reviewed, rejected, or pending supplementation suggestion createdTime Time of evidence formation Required

[0076] 3. EngineeringContextSnapshotRecord

[0077] contextSnapshotId Context snapshot identifier projectId / projectVersion Projects and Project Versions businessType Business type or purpose designStage Estimate, scheme, preliminary design, construction drawings, and other stages region / timeBoundary Regional and Time Scope objectScope Project, individual item, unit project, professional or structural scope keyTechnicalParameters Technical parameters such as structural type, area, number of floors, and floor height dataCompleteness Completeness of key fields sourceBindingDigest Summary of Evidence that Constitutes Context snapshotDigest Deterministic snapshot summary

[0078] IV. Rules for Standardized Processing of Evidence

[0079] • Stable object identifiers are preferred for object location; if an identifier is missing, a temporary identifier can be generated by combining hierarchical path, encoding, name and context, but the generation method must be recorded.

[0080] • Numerical fields should uniformly store the original value, original unit, normalized value, and target unit; it is prohibited to only store the converted value.

[0081] • Enumeration fields store the original text and standard enumerations. If the value cannot be determined, UNKNOWN and candidate values ​​are stored. Forced guessing is not allowed.

[0082] • Model inference results must save the model version, input summary, output summary, and confidence statement; inference results are not automatically equivalent to factual evidence.

[0083] • Manual modifications must simultaneously save the original value, the modified value, the reason for the modification, the user's role, and the time.

[0084] • Evidence Digest is generated with normalized sorted objects, fields, versions, and sources; the same input should generate the same evidenceDigest.

[0085] Algorithm snippet: Evidence standardization

[0086] function normalizeEvidence(rawEvidence, objectModel, schemaVersion, versions):type = classifySource(rawEvidence) fragment = locateSourceFragment(rawEvidence)objectRef = resolveEngineeringObject(fragment, objectModel) fields =extractFields(fragment, type) normalized = normalizeUnitsEnumsAndPaths(fields,schemaVersion) context = buildContextSnapshot(objectRef, normalized, versions)confidence = evaluateEvidenceConfidence(type, normalized, context) canonical =canonicalSerialize(type, objectRef, normalized, context, versions) digest =SHA256(canonical) # or equivalent deterministic digest algorithm return VEEvidenceUnit(type, objectRef,normalized, context, versions, confidence, digest)

[0087] V. Check the correctness of evidence units

[0088] Source can be located `sourceReference` and `sourceFragment` can locate the original source. Marking it SOURCE_UNRESOLVED prohibits its use as independent high-level evidence. Objects can be bound objectId or objectPath can be mapped to the current object version. Enter OBJECT_BINDING_PENDING Fields can be interpreted Field types, units, and enumerations can be interpreted by EvidenceSchemaVersion. Enter SCHEMA_MAPPING_PENDING Full version At least the source data version and the evidence specification version are required. Reject entering candidate generation Abstract Stable The same normalized input repeatedly generates the same digest. Log DETERMINISM_FAILURE and stop committing. Sensitive compliance Restricted fields meet the requirements for data anonymization and scope of use. Limiting the scope of candidate generation and publication

[0089] 5.3 Value Decision-Making Knowledge Candidates and Representation Model

[0090] 1. VEKnowledgeCandidateRecord

[0091] candidateId / candidateVersion Candidate Identifiers and Candidate Versions Required candidateType NEW, UPDATE, RETIRE, RELATION_UPDATE, SCOPE_CHANGE, etc. Required targetKnowledgeId Target knowledge identifier during updates, retirements, or relationship adjustments When applicable applicableObjectScope Applicable object type, level and object condition Required triggerConditionTree Machine-executable trigger condition tree Required exclusionConditionTree Machine-executable exclusion condition tree Recommendation: If missing, risk verification is required. variableBindings Variables, source, unit, missing data policy, and version requirements Required optimizationAction Proposed or recommended engineering optimization actions Required expectedEffectModel Expected impact model, range and applicable scope Required technical Constraints Standards, safety, functionality, quality, and implementation constraints Required relationHints Possible relationships discovered during candidate generation Optional evidenceUnitRefs Supporting evidence unit set Required generationMethod Expert input, rule summarization, model reasoning, graph reasoning, etc. Required generationModelVersion Generation algorithm or model version When applicable candidateDigest Candidate Normalized Summary Required completenessState Complete, To be supplemented, or not executable Required controlState Initially GENERATED Required

[0092] II. Conditional Expression Structure

[0093] LOGIC operator=AND / OR / NOT; children Combinator conditions COMPARE field / operator / value / unit Supports =, ≠, >, ≥, <, ≤, IN, BETWEEN, CONTAINS, etc. EXISTS field / path Determine if a variable or object exists REFERENCE knowledgeId / version / field Reference prior knowledge, standards or benchmarks MODEL_OUTPUT modelId / modelVersion / output / threshold Using model output as the controlled condition UNKNOWN reason / candidateValues The conditions are currently uncertain and must be either put into a pending or manually closed-loop process.

[0094] An abstract example of a condition tree (numerical values ​​are for illustrative purposes only).

[0095] { "operator": "AND", "conditions": [ {"field": "businessType", "operator": "IN", "value": ["residential", "public building"]}, {"field": "designStage", "operator": "IN", "value": ["plan", "initial design"]}, {"field": "indicatorDeviation", "operator": ">", "value": 0.08}, {"operator": "NOT", "conditions": [ {"field": "specialConstraintFlag", "operator": "=", "value": true} ]} ]}

[0096] 3. KnowledgeVariableBindingRecord

[0097] variableId / name Variable identifier and name dataType / unit Data types and units sourcePriority Prioritization of project targets, lists, indicator libraries, knowledge presets, and manual supplementation. sourcePath Field, object, or interface path requiredFlag Is it necessary for execution? missingPolicy REJECT, PENDING, DEFAULT, INFER_WITH_REVIEW, etc. normalizationRule Units, precision, enumeration, and outlier handling versionRequirement Source data and model version requirements confidenceRule Variable source credibility rules usedBy Triggering conditions, exclusion conditions, and references in the affecting model or constraints.

[0098] 4. ExpectedEffectModelRecord

[0099] effectModelId / modelVersion Expected Impact Model and its Version effectType Cost, workload, indicators, risks, schedule, functionality, or multi-dimensional impacts inputVariables Input variable and source binding expressionOrModelRef Formula, decision table, statistical model, or constrained model identifier expectedInterval Expected impact range and confidence boundaries baselineDefinition Baseline object, baseline version, and baseline caliber overlapKey Used to identify objects and cost / metric keys that overlap with other knowledge effects. validationTolerance Verify error tolerance or pass rules fallbackPolicy Handling strategies when the model is unexecutable or variables are missing

[0100] V. Candidate Integrity Model

[0101] Candidate completeness is not simply about counting non-empty fields; it's about checking whether knowledge can be interpreted by the processor within defined object and version boundaries. At a minimum, it should simultaneously verify object scope, condition tree, variable sources, optimization actions, expected impact, technical constraints, and evidence citations.

[0102] COMPLETE All necessary objects, variables, actions, models, constraints, and evidence are interpretable. Enter Relationship Graph Determination PARTIAL_EXECUTABLE Non-critical fields are missing, but core matching and model execution are possible. Enter the relationship diagram and supplementary verification; formal release is prohibited. PENDING_INPUT Key variables, exclusion conditions, or constraints are missing. Create a structured supplementary task NON_EXECUTABLE Model without a clear object, variable source, or influence Refusal to enter the main verification chain

[0103] Algorithm snippet: Knowledge candidate generation

[0104] function generateCandidate(evidenceUnits, currentContext, generationPolicy):groups = groupEvidenceByObjectActionAndGoal(evidenceUnits) candidate =inferKnowledgeStructure(groups, generationPolicy)candidate.triggerConditionTree = buildTriggerConditions(groups) candidate.exclusionConditionTree = buildExclusionConditions(groups)candidate.variableBindings = bindVariables(groups, currentContext)candidate.expectedEffectModel = buildExpectedEffectModel(groups)candidate.technicalConstraints = collectTechnicalConstraints(groups)candidate.evidenceUnitRefs = sortEvidenceRefs(groups)candidate.completenessState = evaluateCandidateCompleteness(candidate)candidate.candidateDigest = digest(canonicalSerialize(candidate)) returncandidate

[0105] 5.4 Review of content relationships, relationship pending, and publication context conflicts

[0106] For content-level conflicts or overlapping effects, the processor further assesses the risk of release-level conflicts or duplicate outputs by considering the target release context, release scope, effective period, and project output key. This review is performed before generating a release configuration version, activating an existing release configuration version, or generating and activating a new release configuration version to replace an existing one.

[0107] like Figure 5 As shown, candidates are first compared with existing knowledge content versions in five dimensions. When a relationship cannot be determined, the relationship pending record must be supplemented with evidence or a relationship strategy before returning to the five-dimensional comparison and relationship mapping steps. It is not allowed to bypass relationship recalculation and directly enter the candidate admission verification.

[0108] I. Comparison of Content Layer Relationships

[0109] object scope Project object hierarchy path, applicable object set Equivalence, inclusion, intersection, separation Conditional interval Triggering conditions, exclusion conditions, numerical ranges, and enumeration sets Equivalence, partial overlap, mutual exclusion Variables or action targets Variable source, optimization action, affected object Same, Dependency, Conflict Technical constraints Specifications, security, functionality and boundary constraints Compatibility, conditional dependency, incompatibility Expected results Project output keys, cost items, project quantity or indicator scope No overlap, partial overlap, duplicate effects

[0110] II. RelationPendingRecord (Relation Pending Record)

[0111] candidateId / candidateVersion Candidate Identifiers and Versions compared KnowledgeVersionId Version of knowledge content being compared relationPolicyVersion Relationship mapping strategy version dimensionComparisonResults Five-dimensional comparison results conflictingRelationOutputs Inconsistent Relationship Output unresolvedDimensionSet Incomparable sets of dimensions required Supplement Additional evidence or strategies needed reasonCode / recordDigest Reason code and record summary

[0112] III. ReleaseContextConflictCheckRecord: Release context conflict check record

[0113] conflictCheckRecordId / version Verification record identifier and version knowledgeVersionId Proposed release of knowledge content version plannedReleaseVersionId / plannedReleaseConfigDigest Planning release configuration identifier or planning configuration summary targetReleaseContext Target tenant, enterprise, project, object scope, effective period, and project output key conflictingKnowledgeVersionId / conflictingReleaseVersionId Conflict knowledge content version and currently valid release configuration version scopeOverlapResult / effectiveTimeOverlapResult Range and time overlap results effectOverlapResult Engineering output key and effect aperture overlap results checkedActivationSetVersion Activate collection version during verification checkedEffectiveReleaseSetDigest The current valid published collection summary is validated during the verification process. checkTime / conflictPolicyVersion Verification time and conflict policy version validationResult / reasonCode PASS, PENDING, or BLOCK and reason code recordDigest Record Summary

[0114] Release context conflict verification is performed before generating a release configuration version, activating an existing release configuration version, or generating and activating a new release configuration version to replace an existing release configuration version. If the target scope does not overlap during the candidate phase, it only proves that the target release context is not conflicting at that time; subsequent verification must be performed when expanding the release scope, reactivating historical configurations, or generating alternative configurations. Activation is prohibited if the verification result is BLOCK.

[0115] 5.5 Candidate entry threshold and shadow evaluation time series

[0116] After the planned release configuration passes release context conflict verification and the activationSetVersion and valid set summary remain unchanged upon commit: For the first generation and activation of a release configuration version, the processor writes the release configuration version, initial release control state record, ACTIVATE record, and new activation set version to the same atomic commit unit. For reactivating an existing release configuration version, it does not regenerate or modify the release configuration version; instead, it appends a new release control state record, ACTIVATE record, and new activation set version to the same commit unit. For generating and activating a new release configuration version to replace an existing release configuration version, it writes the new release configuration version, release replacement relationship record, new version initial state and ACTIVATE record, old version DEACTIVATE record, and new activation set version to the same commit unit. When creating a formal release configuration after the shadow evaluation passes, the formal configuration and its initial state and ACTIVATE record are written according to the first generation and activation path, and a DEACTIVATE record is appended to the original shadow configuration.

[0117] The candidate admission verification batch simultaneously calculates both the shadow freeze admission flag and the direct official release admission flag. The direct official release threshold is higher than the shadow freeze threshold, and both thresholds play a binding role in subsequent release steps.

[0118] approvalForShadowFreeze All blocking tasks were completed and passed; technical constraints were consistent; the variables, models, and frozen inputs required for shadow execution were available. Freeze knowledge content versions and only create shadow release configuration versions approvalForDirectFormalRelease It meets the shadow freeze threshold and further satisfies the requirements for formal project samples, relationship handling, release context conflict verification, and version compatibility. Freezing the knowledge content version allows you to directly create a production release configuration version. None of them reached Blocking task failure, relationship pending, key variable missing, or model unexecutable Unfrozen knowledge content version

[0119] If `approvalForShadowFreeze` is true only, the release strategy cannot bypass the threshold to create a formal release configuration version. A shadow path must form a `ShadowEvaluationBatch`, and a formal release configuration version can only be created after the shadow evaluation meets the formal release criteria.

[0120] ShadowEvaluationBatch

[0121] knowledgeVersionId / releaseVersionId The evaluated knowledge content and shadow publishing configuration shadowWindowRule Project scope, time frame, and minimum sample size shadowMatchMetrics / humanModificationMetrics Shadow hit and effective manual modification effectDeviation / actualOutcomeBindings Effect bias and actual results obtained compatibilityAndConstraintResults Version compatibility and technical constraints results shadowIsolationRecordRefs Shadow execution isolation record reference formal Release Decision Official release, continued shadow review, manual review, or suspension. batchDigest Shadow Evaluation Batch Summary

[0122] 5.6 Formal Data Structures for the Three Types of Control States

[0123] Set a unique constraint for `stateSequence` within the same candidate, knowledge content version, or release configuration version. When writing a new state record, compare `previousStateVersion` or `expectedPreviousStateDigest`; reject the commit if the comparison fails. `recordId` is only used for deterministic sorting of anomalous data.

[0124] I. CandidateControlStateRecord Candidate Control State Record

[0125] candidateId / candidateVersion Candidate Identifiers and Versions state / stateVersion / stateSequence Status, status version, and monotonically increasing sequence number validationMatchAllowed Allow matching in the verification environment? validationExecutionAllowed Allow loading models or actions in the validation environment. freezeAllowed Allow freezing of knowledge content versions effectiveTime / previousStateVersion / expectedPreviousStateDigest Effective date, previous state version, and expected previous state summary relationGraphVersion / admissionBatchVersion Relationship diagram and admission batch basis transitionRecordId / reasonCode Conversion record and reason code idempotencyKey / stateDigest Idempotent keys and state summaries

[0126] II. KnowledgeQualificationStateRecord: Record of knowledge content qualification status

[0127] qualificationStateRecordId / knowledgeVersionId Qualification records and knowledge content versions state / stateVersion / stateSequence QUALIFIED, REVIEW_PENDING, DEGRADED, SUSPENDED, or RETIRED and sequence number newReleaseReferenceAllowed Allow the creation of new release configuration references? existingReleaseRuntimeAllowed Should existing releases continue to be included in the candidate set? formalOutputAllowed Is formal output allowed? shadowExecutionAllowed Allow shadow execution? effectiveTime / previousStateVersion / expectedPreviousStateDigest Effective date, previous state version, and expected previous state summary triggerSignalRefs / reasonCode Trigger signal and reason code idempotencyKey / recordDigest Idempotent keys and summaries

[0128] III. ReleaseControlStateRecord publishes control state records.

[0129] releaseStateRecordId / releaseVersionId Status events and release configuration versions state / stateVersion / stateSequence PREPARED, SHADOW_ACTIVE, FULL_ACTIVE, PAUSED, CLOSED, or ROLLED_BACK and sequence number matchAllowed / executeAllowed Matching and executing qualifications formalOutputAllowed / shadowOutputOnly Formal output and shadow output limitations effectiveTime / previousStateVersion / expectedPreviousStateDigest Effective date, previous state version, and expected previous state summary activationRecordId / reasonCode Activation record and reason code idempotencyKey / stateDigest Idempotent keys and state summaries

[0130] The current state of the same entity is determined by descending order of effectiveTime, descending order of stateSequence, and ascending order of state record identifier. State records use append-only immutable events and are not modified in situ.

[0131] 5.7 Publishing configurations, state events, activation sets, and concurrent atomic consistency

[0132] Release configuration versions do not save runtime status, nor do they save identifiers for future replacement versions. A new release configuration version is written upon initial generation and activation; when an existing release configuration version is reactivated, that version remains unchanged; when a configuration is replaced, a new release configuration version is generated and associated with the old version through the release replacement relationship record. Upon initial activation, reactivation, pause, shutdown, rollback, or shadow conversion to official status, status events, activation or deactivation records, and activationSetVersion are atomically committed, and the expected previous set summary is verified.

[0133] I. ReleaseVersion Release Configuration

[0134] releaseVersionId Immutable release configuration version identifier previousReleaseVersionId The previous release configuration version referenced when configuration changes knowledgeVersionId Version of the knowledge content cited releaseScope / releaseMode / grayRatio Range, mode and grayscale ratio effectiveTime / expiryTime Configure effective range compatibilityRequirements Object, variable, model, and specification compatibility requirements releasePriority / formalOutputFlag / shadowOutputOnlyFlag Selection and Result Channel Configuration releaseSelectionPolicyVersion / releaseDigest Select policy version and configuration summary

[0135] Released configuration versions do not save runtime state, nor do they save the identifier of future replacement versions. New configurations can save the identifier of the previous released configuration version; old configurations remain unchanged.

[0136] II. ReleaseActivationRecord: Release Activation Record

[0137] activationRecordId Activation record identifier releaseVersionId Activated or deactivated release configuration versions action ACTIVATE or DEACTIVATE only activationSetVersion The monotonically increasing version of the activation set expectedPreviousSetDigest Expected valid set digest before submission, used for concurrent comparison previousEffectiveSetDigest Summary of the set before actual action nextEffectiveSetDigest Post-action set summary effectiveScope / effectiveTime Action range and effective time reasonCode / triggerRecordId Record of causes and sources idempotencyKey / activationDigest Idempotent keys and summaries commitStatus / committedTime Submission status and completion time transactionOrCommitId Transaction or commit identifier activationScenario INITIAL_ACTIVATION, REACTIVATION or SUPERSESSION_ACTIVATION

[0138] III. ReleaseSupersessionRecord publishes replacement relationship records.

[0139] supersessionRecordId Substitution Relationship Record Identifier previousReleaseVersionId / newReleaseVersionId Replaced configuration and new configuration supersessionScope / supersessionTime Replacement Scope and Time reasonCode / recordDigest Causes and Summary

[0140] IV. Atomic Submission and Concurrency Control

[0141] Pausing operations append a PAUSED state record and a DEACTIVATE activation record to the same transaction or a commit unit with equivalent atomic semantics, forming a new activationSetVersion. When reactivating an existing release configuration version, the ReleaseVersion is not regenerated or modified; instead, a new release control state record, an ACTIVATE record, and a new activationSetVersion are appended. When a configuration is replaced, a new ReleaseVersion, ReleaseSupersessionRecord, a new version ACTIVATE record, and an old version DEACTIVATE record are generated. During a commit, expectedPreviousSetDigest is validated; if the validation is inconsistent, the commit is rejected and recalculated.

[0142] 5.8 Deterministic Choice in Multiple Release Versions and Evidence for Replayable Decisions

[0143] The release selection decision is formed for a single project output key and bound to a set of release context conflict verification records. Formal results, shadow results, and runtime feedback are all bound to the selectionDecisionId to replay the candidate set, conflict verification, bucketing, and selection reason at that time.

[0144] I. ReleaseSelectionPolicyVersion Release selection policy version

[0145] scopeSpecificityRule Specify the order of scope specificity, such as project, object scope, enterprise, and tenant. releasePriorityRule Priority within the same range grayRoutingRule Stable grayscale routing algorithm and number of buckets shadowCoexistenceRule Allowed combination of shadow patterns tieBreakRule When specificity and priority are the same, disambiguation is performed based on effectiveTime and releaseVersionId. formalOutputRule Only one production output version is allowed for the same knowledgeId + projectObjectVersion + engineeringOutputKey. policyDigest Strategy Summary

[0146] The grayscale routing key is determined by projectObjectVersion, knowledgeId, and releaseSelectionPolicyVersion, without using random numbers, server nodes, or request times.

[0147] II. ReleaseSelectionDecisionRecord publishes the selection decision record.

[0148] selectionDecisionId / version Select Decision Records and Versions projectObjectVersion / knowledgeId Project object version and knowledge identifier candidateReleaseSetDigest Summary of the selected release collection knowledgeQualificationStateVersion Knowledge Content Qualification Status Version releaseStateRecordVersionSet Release control state version set activationSetVersion Current valid set version releaseSelectionPolicyVersion Select strategy version grayRoutingKey / grayBucket Stable grayscale routing key and bucketing results selectedFormalReleaseVersionId The only officially released configuration version selectedShadowReleaseVersionIds Set of shadow versions allowed to coexist exclusionReasonMap Reasons for excluding unselected versions selectionDigest Select Decision Summary engineeringOutputKey Select the corresponding project output key this time. releaseContextConflictCheckRecordIds / conflictCheckSetDigest Publish context validation record set or its summary

[0149] The FormalResultSet, ShadowResultSet, and runtime feedback are all bound to selectionDecisionId, so that the candidate set, sorting, bucketing, and selection reason at that time can still be replayed after the state or strategy changes.

[0150] 5.9 Project Result Recording and Shadow Execution Isolation

[0151] I. ResultExecutionWriteEligibilityRecord: Execution and Writing of Result to Eligibility Record

[0152] writeEligibilityRecordId Result execution and writing to qualification record identifier projectObjectVersion / knowledgeId Project object version and knowledge identifier knowledgeVersionId / releaseVersionId Knowledge content and release configuration versions releaseSelectionDecisionId Publish selection decision record engineeringOutputKey / resultChannel Project output keys and FORMAL or SHADOW channels knowledgeQualificationStateVersion Knowledge Content Qualification Status Version releaseControlStateVersion Release control status version activationSetVersion Activate Collection Version targetNamespace Formal or shadow target namespace eligibilityResult / reasonCode Qualification conclusion and reason code effectiveTime / recordDigest Effective Date and Summary eligibilityStage PRE_EXECUTION or PRE_WRITE

[0153] Results processing eligibility is divided into two phases. The PRE_EXECUTION phase is executed before loading the expected effect model or candidate optimization actions, validating the selection decision, knowledge eligibility, release status, active set version, engineering output key, execution namespace, and shadow isolation conditions; if the validation fails, the model or action will not be loaded. The PRE_WRITE phase is executed before writing to the formal result set, shadow result set, formal engineering object, or process status, validating the result channel, target namespace, release selection decision, knowledge eligibility, release status, active set version, and engineering output key; if the validation fails, writing is not allowed.

[0154] II. EngineeringResultRecord (Engineering Result Record)

[0155] resultId Result Record Identifier projectObjectVersion Project object version knowledgeVersionId / releaseVersionId Knowledge content and release configuration versions releaseSelectionDecisionId Publish selection decision record modelVersion / resultChannel Model version and FORMAL or SHADOW channel engineeringOutputKey Project output unique key outputValue / unit Result value and unit inputSnapshotDigest Enter snapshot summary writeEligibilityRecordId Write to qualification record createdTime / resultDigest Creation Time and Summary

[0156] Only one release configuration version is allowed to be written to the FormalResultSet for the same knowledgeId, projectObjectVersion, and engineeringOutputKey. Different knowledgeIds, different project output keys, or shadow channels can coexist.

[0157] III. ShadowExecutionIsolationRecord

[0158] isolationRecordId Isolation record label projectObjectVersion / knowledgeVersionId / releaseVersionId Project object and version binding releaseSelectionDecisionId Publish selection decision record inputSnapshotDigest Frozen Project Input Snapshot Summary isolationMode Sandbox, transaction rollback environment, or independent namespace externalCallRecords Response snapshot or side-effect-free simulated call log writeTarget ShadowResultSet or shadow namespace only sideEffectCheckResult Formal objects, formal results, and process status side effect checks writeBarrierResult resultChannel=SHADOW Write barrier results recordDigest Summary of Isolation Records

[0159] Shadow optimization actions must not modify official project parameters, official inventory lists, official quantities, official cost metrics, or official process status. Calls to external interfaces should use pre-recorded response snapshots, read-only interfaces, or side-effect-free mock interfaces. Only official release configuration versions approved by formalOutputAllowed can be written to official project objects or FormalResultSets.

[0160] IV. RuntimeFeedbackEvidenceRecord runtime feedback evidence

[0161] feedbackId / executionId / sourceEventId Feedback, Execution, and Source Event Identifiers releaseSelectionDecisionId / engineeringOutputKey Select decision and engineering output keys knowledgeVersionId / releaseVersionId / projectObjectVersion Three types of version binding matchRecord / executionRecord Matching and execution records decisionRecord / predictedEffect / actualOutcome Human decision-making, forecasting, and actual results resultChannel / resultRecordId Results Channel and Results Records feedbackDigest Feedback Summary deduplicationKey executionId+sourceEventId+selectionDecisionId+engineeringOutputKey+releaseVersionId+resultChannel

[0162] 5.10 Core Algorithm Pseudocode and Examples

[0163] 1. Candidate Admission Thresholds and Release Paths

[0164] function admitCandidate(candidate, relationGraph, validationPolicy):batch = runAllBlockingAdmissionTasks(candidate, relationGraph)batch.approvalForShadowFreeze = allBlockingTasksCompletedAndPassed(batch) andtechnicalConstraintPass(batch) and shadowExecutionInputReady(batch) batch.approvalForDirectFormalRelease = batch.approvalForShadowFreeze anddirectFormalSampleThresholdPass(batch) and releaseCompatibilityPass(batch)return batchif approvalForShadowFreeze and notapprovalForDirectFormalRelease: create KnowledgeVersion and SHADOWReleaseVersion onlyif approvalForDirectFormalRelease: allow direct FORMALReleaseVersionif shadow path: create FORMAL ReleaseVersion only afterShadowEvaluationBatch passes

[0165] 2. Conflict Review and Selection Decision During Release

[0166] function prepareOrActivateRelease(operation, releaseConfig,projectContext): conflict = checkReleaseContextConflict( operation,releaseConfig.scope, releaseConfig.timeRange, releaseConfig.engineeringOutputKey, knowledgeRelations, currentEffectiveReleaseSet) if conflict.result isBLOCK: reject activation assert currentActivationSetVersion == conflict.checkedActivationSetVersion assert currentEffectiveReleaseSetDigest == conflict.checkedEffectiveReleaseSetDigest if operation == INITIAL_ACTIVATION:atomically write new ReleaseVersion, initial state, ACTIVATE and next setversion if operation == REACTIVATION: keep existing ReleaseVersion unchanged;atomically append new state, ACTIVATE and next set version if operation ==SUPERSESSION_ACTIVATION: atomically write new ReleaseVersion, supersessionrecord, new ACTIVATE, old DEACTIVATE and next set version

[0167] III. Unique Official Output and Shadow Isolation

[0168] formal = decision.selectedFormalReleaseVersionIdshadows = decision.selectedShadowReleaseVersionIdsif formal: preExecution =createEligibilityRecord(PRE_EXECUTION, formal, FORMAL) if preExecution.pass:result = executeWithEngineeringInputs(formal, objectFields, quantity, price,technicalParameters) preWrite = createEligibilityRecord(PRE_WRITE, formal,FORMAL, result) if preWrite.pass: enforce unique key (knowledgeId,projectObjectVersion, engineeringOutputKey) write FormalResultSet(result)forshadow in shadows: preExecution = createEligibilityRecord(PRE_EXECUTION,shadow, SHADOW) if preExecution.pass: snapshot = freezeProjectInput(projectObjectVersion) result = execute in sandbox with side-effect-freeexternal calls preWrite = createEligibilityRecord(PRE_WRITE, shadow, SHADOW,result) if preWrite.pass and writeBarrier(resultChannel=SHADOW): writeShadowResultSet and ShadowExecutionIsolationRecord

[0169] IV. Atomic Commit of State Events and Activation Sets

[0170] function pauseRelease(releaseVersionId, expectedSetDigest,idempotencyKey): begin atomic commit assert currentEffectiveSetDigest ==expectedSetDigest append ReleaseControlStateRecord(PAUSED, stateSequence++)append ReleaseActivationRecord(DEACTIVATE, activationSetVersion++,idempotencyKey) compute nextEffectiveSetDigest commit

[0171] V. End-to-end Implementation

[0172] Example 1: Candidate Admission and Dual Threshold

[0173] Candidate KC-001 has completed all blocking tasks and passed the technical constraint consistency verification, with approvalForShadowFreeze=true and approvalForDirectFormalRelease=false. The system only freezes KV-001 and creates the SHADOW release configuration RV-S1; it must not directly create a formal release.

[0174] Example 2: Official release after shadow evaluation

[0175] RV-S1 runs in a shadow environment, forming a ShadowEvaluationBatch. Once the batch meets the conditions for official release, the system creates the official release configuration RV-F1, which references KV-001.

[0176] Example 3: Subsequent expanded release scope and re-conflict review

[0177] KV-001 was initially released only within the scope of Enterprise B, and its conflict knowledge did not overlap with that of Enterprise A. When RV-F2 was subsequently created for the scope of Enterprise A, the system regenerated ReleaseContextConflictCheckRecord and discovered overlaps in the scope, time, and project output keys, resulting in validationResult=BLOCK and disabling RV-F2 activation.

[0178] Example 4: Gray-scale routing and selection decision replayable

[0179] Project object P-100 simultaneously hits the Enterprise FULL, Project-Specific, GRAY, and SHADOW releases. The system generates a stable grayscale routing key using projectObjectVersion + knowledgeId + policyVersion, selects a unique official version based on scope specificity and priority, and writes the candidate set, status version, bucket, exclusion reason, and shadow version into ReleaseSelectionDecisionRecord.

[0180] Example 5: The only formal engineering output

[0181] Both the project-specific and enterprise versions can execute the same project output key, COST-DELTA. The selected strategy only allows the project-specific version to write to the FormalResultSet; the enterprise version is excluded, and the shadow version only writes to the ShadowResultSet, preventing duplicate cost metrics from being written.

[0182] Example 6: Shadow Optimization Action Side Effect Isolation

[0183] Shadow version reads a frozen input snapshot and executes within a rollback transaction and a separate namespace. A response snapshot is used for the material price interface, while a side-effect-free simulation is used for the message interface. A write barrier rejects writes to the formal project table, formal quantity table, and formal process status, forming a ShadowExecutionIsolationRecord.

[0184] Example 7: Concurrent Consistency in Publishing Status

[0185] Two nodes simultaneously attempt to pause the same release. The first transaction passes with expectedPreviousSetDigest and commits the PAUSED status and DEACTIVATE record; the second transaction fails upon discovering a change in the set digest, and then rereads the latest activationSetVersion before proceeding.

[0186] Example 8: Feedback to Prevent Repetition

[0187] When the same execution event arrives repeatedly, the system uses executionId, sourceEventId, selectionDecisionId, engineeringOutputKey, releaseVersionId, and resultChannel to form an idempotent key, and the second write is rejected; observationTime is only saved as the observation time.

[0188] Example 9: Signal-Driven Content and Publishing Decentralization

[0189] The evaluation window first generates signals for effect deviation and version compatibility failure. When the content boundary changes, a new Candidate is generated for re-admission; only when the runtime is paused, knowledge qualification status, release status, and activation records are appended, without generating a new release configuration version.

[0190] Example 10: Historical Project Replay

[0191] Historical projects save ReleaseSelectionDecisionRecord, FormalResultRecord or ShadowResultRecord, state version and active set version, so even if the release strategy or state changes later, it is still possible to replay why a certain official version was selected and which shadow versions coexist.

[0192] VI. Supplementary Implementation Method for Concurrent Verification and Write Qualification

[0193] During the release configuration activation transaction, the system reads the current activationSetVersion and the current valid set digest, and compares them with the checkedActivationSetVersion and checkedEffectiveReleaseSetDigest stored in ReleaseContextConflictCheckRecord; if either is inconsistent, the original verification record becomes invalid and the release context conflict verification is re-executed.

[0194] The release selection decision uses projectObjectVersion, knowledgeId, and engineeringOutputKey as selection boundaries, and saves a summary of the conflict verification records involved in the selection. The grayscale routing key is determined by projectObjectVersion, knowledgeId, and releaseSelectionPolicyVersion.

[0195] Before writing to a FormalResultSet or ShadowResultSet, the system generates a ResultExecutionWriteEligibilityRecord. When formal channel qualification fails, formal project quantities, material usage, cost indicators, or technical constraint conclusions are not written; when shadow channel qualification fails, ShadowResultSet is not written.

[0196] When two concurrent transactions append the same principal state, only the transaction that obtains a unique stateSequence by comparing the previous state version or digest succeeds. State records and publish / activate records use the same transaction or equivalent atomic commit unit.

[0197] 5.11 System Implementation Method

[0198] like Figure 12 As shown, the system of the present invention includes the following modules:

[0199] Evidence Standardization Module Standardized evidence units that generate objects, hierarchical paths, contexts, and version bindings. Knowledge Candidate Generation Module Generate candidates with complete conditions, variables, actions, effect models, and technical constraints. Content Relationship Determination Module Perform five-dimensional content comparison, relation mapping, and relation pending loop closure. Release Context Conflict Review Module When generating binding checks, conflict check records are activated for the collection version and the valid collection digest, and the checks are re-verified when the collection changes. Candidate Admission Verification Module Generate two admission thresholds and candidate control state records. Knowledge Content Versions and Qualification Modules Freeze immutable knowledge content versions and add eligibility status records. Release configuration and status module Distinguish between initial generation and activation, reactivation of existing configurations, and activation of replacement configurations; atomically write the corresponding state, activation / deactivation, and set version records. Publish Selection and Decision Record Module Perform stable routing and deterministic selection for the project output key, and bind a set of conflict check records. Shadow evaluation and execution isolation module Generate ShadowEvaluationBatch and ShadowExecutionIsolationRecord Engineering Calculation Execution and Result Control Module Generate a PRE_EXECUTION qualification record before loading the model or action, and generate a PRE_WRITE qualification record before writing the result or formal object, and control the execution and write channels respectively. Feedback, Signaling and Evolution Module Generate version binding feedback, evolution signals, and content / release actions. Version Submission Audit Module Execution state order unique constraint, preceding state summary comparison, activation set version and atomic commit

[0200] The release of selection decisions, official results, shadow results, shadow execution isolation, and operational feedback form a continuous chain of evidence. The modules in the system claims can be deployed on the same electronic device or multiple service nodes, but state events and activation set updates must maintain atomic or equivalent atomic semantics.

[0201] 5.12 Electronic devices, storage media, and program implementation methods

[0202] The present invention also provides an electronic device, which includes at least one processor, a memory, a communication interface, and a bus. The memory stores standardized evidence units, value decision knowledge candidates, knowledge content versions, knowledge content eligibility status records, release configuration versions, release context conflict verification records, release control status records, release activation records, release substitution relationship records, release selection strategy versions, release selection decision records, shadow evaluation batches, shadow execution isolation records, formal result records, shadow result records, operational feedback evidence, and evolution signal records.

[0203] When the computer program is executed by the processor, the electronic device performs the steps described in S101 to S108. The processor may be a central processing unit, a graphics processing unit, a neural network processor, a digital signal processor, an application-specific integrated circuit, a programmable logic device, or a combination thereof. The memory may be random access memory, read-only memory, solid-state memory, disk, object storage, or other non-transitory media.

[0204] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. The present invention can also be provided in the form of a computer program product, a container image, a deployable service package, or firmware.

[0205] 5.13 Alternative Implementation Methods and Technical Boundaries

[0206] • Evidence units can be stored in relational databases, document databases, graph databases, object stores, or event logs, as long as they can save source location, object binding, version binding, and deterministic summary.

[0207] • Knowledge candidates can be generated by expert structured input, rule induction, statistical pattern mining, clustering or association analysis, vector retrieval, generative models, knowledge graph reasoning, causal analysis, agent collaboration, or a combination thereof.

[0208] • Conditional expressions can take the form of JSON trees, decision tables, rule languages, compiled functions, query predicates, or constrained model outputs, as long as their inputs, outputs, and versions can be determined by the processor.

[0209] • Knowledge relationship graphs can be stored as graph databases, relation tables, adjacency lists, sparse matrices, or in-memory graphs; relation determination can be based on deterministic rules, statistical models, learning models, or manual structured confirmation, but relation records must retain comparison fields, reasons, and versions.

[0210] • Validation can be performed in historical projects, synthetic projects, test projects, sandboxes, shadow environments, or real projects; manual review is one of the optional validation methods and does not replace machine validation and state control of the main chain.

[0211] • The digest algorithm can be SHA-256 or an equivalent deterministic digest algorithm; the transaction can be a single database transaction, a distributed transaction, an event-sourced commit, or another commit mechanism with equivalent atomic semantics.

[0212] • The release scope can be tenant, enterprise, region, project type, design phase, object scope, or specified project; each time a release configuration is generated, activated, or replaced, a release context conflict review is re-executed, and a unique official output and coexisting shadow outputs are formed by the release selection strategy.

[0213] • Cross-project evolution can employ fixed thresholds, statistical process control, drift detection, Bayesian updates, online learning, reinforcement learning, or manual strategies, as long as the running feedback first forms version binding evidence, and new knowledge must re-enter the relationship and verification chain.

[0214] • This invention does not focus on automatically generating final engineering design schemes, finding optimal solutions by combining multiple value engineering schemes, generating construction drawing parameters, or automatically generating drawings; the above-mentioned technical topics can be protected independently as other patent applications.

Claims

1. A method for generating, verifying, controlling the release, and versioning evidence-driven knowledge units for multi-level engineering cost objects, executed by at least one processor of an electronic device, characterized in that... include: Acquire engineering project data and professional knowledge data, and perform source fragment location, engineering object identification, object hierarchy location, field and unit normalization, project context binding, source data version binding, and deterministic summary calculation on the acquired data to generate multiple standardized evidence units; Based on the multiple standardized evidence units, value decision knowledge candidates are generated. The value decision knowledge candidates include the scope of applicable objects, machine-executable triggering conditions, machine-executable exclusion conditions, candidate optimization actions, variable and source binding, affected objects, expected effect model, technical constraint set and evidence binding set. The value decision knowledge candidates and existing immutable knowledge content versions are added to a versioned knowledge relationship graph. The scope of the comparison objects, the condition interval, the variable or action target, the technical constraints and the expected effect are compared. The content layer knowledge relationship is mapped according to the versioned relationship determination strategy. When the relationship output is inconsistent or there are dimensions that cannot be compared, a relationship pending record is generated, and the comparison and mapping are re-executed after supplementing evidence or relationship determination strategy. Based on the knowledge relationships in the content layer, candidate admission verification tasks are generated, and structural integrity verification, variable availability verification, expected effect model executability verification, technical constraint consistency verification, and project sample verification are performed to generate candidate admission verification batch records. When all blocking verification tasks are completed and passed and the input conditions required for shadow execution are met, a shadow freeze admission flag is set. When the project sample, content relationship processing, and version compatibility conditions required for direct formal release are further met, a direct formal release admission flag is set. The value decision knowledge candidates only have verification matching qualifications, verification execution qualifications, and freeze qualifications in the verification environment, and do not enter the formal knowledge registry or generate formal engineering output. When the shadow freeze access flag is true and the direct formal release access flag is false, a knowledge content version that cannot be modified in place is frozen, and shadow release configuration information to be generated is formed; when the direct formal release access flag is true, formal release configuration information to be generated is allowed; in the shadow path, formal release configuration information corresponding to the same knowledge content version is allowed to be generated only after the shadow evaluation batch meets the formal release conditions. Before generating a release configuration version, activating an existing release configuration version, or generating and activating a new release configuration version to replace an existing release configuration version, a release context conflict check is performed based on the target release scope, effective interval, project output key, content layer conflict relationship or effect overlap relationship of the planned or to-be-activated release configuration, and the current set of valid release versions. A release context conflict check record is generated, which is bound to the version of the activated set at the time of check, the summary of the current valid set, the check time, and the conflict strategy version. When the activation is committed, the current activated set version and the summary of the current valid set are checked to be consistent with the release context conflict check record. If they are inconsistent, the original check record is invalidated and the release context conflict check is re-executed. When the release context conflict check passes and the activated set version is consistent with the current valid set summary: when a release configuration version is generated and activated for the first time, a release configuration version that cannot be modified in situ, the initial release control state record bound to it, the ACTIVATE release activation record, and the new activated set version are written into the same transaction or commit unit with equivalent atomic semantics; when an existing release configuration version is reactivated, the release configuration version is not regenerated or modified, but a new release control state record, the ACTIVATE release activation record, and the new activated set version are appended into the same commit unit. Generate and activate a new release configuration version to replace the existing release configuration version. In the same commit unit, write the new release configuration version, release replacement relationship record, initial release control status record of the new release configuration version, ACTIVATE record of the new release configuration version, DEACTIVATE record of the existing release configuration version, and a new activation set version. Among them, the shadow release configuration version corresponds to the shadow valid status, and the official release configuration version corresponds to the official valid status. When creating the official release configuration version after the shadow evaluation is passed, write the official release configuration version and its initial status and ACTIVATE record according to the first generation and activation path, and append the DEACTIVATE record to the original shadow release configuration version. The knowledge registry forms a candidate release set based on knowledge content eligibility status records, release control status records, release activation records, release scope, validity period, and version compatibility results. It then performs a deterministic selection based on the release selection strategy version for each project output key, generating a release selection decision record. This release selection decision record is bound to the project output key, a summary of the candidate release set, the knowledge content eligibility status version, the release control status version set, the activation set version, a summary of the release context conflict verification record set, the release selection strategy version, the stable grayscale routing key and bucketing results, the selected official release configuration version, the selected shadow release configuration version set, the exclusion reason, and the selection summary. For the same knowledge identifier, the same project object version, and the same project output key, only one release configuration version is allowed to generate an official output. The execution interface reads the project object fields, quantities, prices, material data, technical parameters, and variable source bindings based on the release selection decision record. Before loading the expected effect model or candidate optimization action, it generates a result execution and write qualification record with the qualification stage set to PRE_EXECUTION, and verifies the knowledge content qualification status, release control status, activation set version, release selection decision, project output key, and execution namespace. After the pre-execution qualification verification passes, it loads the expected effect model or candidate optimization action and generates at least one of the following: quantity change result, material usage result, project cost index, or technical constraint verification result. Before writing to the formal result set, shadow result set, formal project object, or process status, it generates a result execution and write qualification record with the qualification stage set to PRE_WRITE, and verifies again the project object version, knowledge content version, release configuration version, release selection decision record, project output key, result channel, knowledge content qualification status version, release control status version, activation set version, and target namespace. If the PRE_EXECUTION qualification verification fails, it refuses to load the model or candidate optimization action; if the PRE_WRITE qualification verification fails, it cannot write to the corresponding result set, formal project object, or formal process status. The official release configuration version is executed only after the PRE_EXECUTION qualification check is passed, and writes the official result set, official project object, or official process status when the PRE_WRITE qualification check allows official output. The shadow release configuration version reads the frozen project object input snapshot after the PRE_EXECUTION qualification check is passed, and executes in a sandbox, transaction rollback environment, or independent namespace. It prohibits modification of official project objects, official calculation results, and official process status. External calls use response snapshots or side-effect-free simulation interfaces, and only writes the shadow result set and shadow execution isolation record after the PRE_WRITE qualification check and write barrier are passed. Generate runtime feedback evidence that simultaneously binds knowledge content version, release configuration version, project object version, release selection decision record, engineering output key, and result channel; generate evolution signal records according to the evaluation window and evolution strategy version, and then determine content evolution, knowledge content eligibility control, release configuration, or release runtime control actions based on signal type, severity level, combination relationship, and priority; When the knowledge content changes, a new value decision knowledge candidate is generated, retaining the parent knowledge content version and the set of changed fields, and the knowledge relationship determination and candidate admission verification are re-executed; when only the release configuration changes, a new immutable release configuration version and release replacement relationship record are generated; when only the release running status changes, a new release configuration version is not generated, but a release control status record, release activation record, and a new activation set version are appended in the same transaction or a commit unit with equivalent atomic semantics. Among them, the status sequence number under the same candidate, the same knowledge content version, or the same release configuration version is monotonically increasing and unique. The status record saves the previous status version or the expected previous status summary. When writing, the previous status comparison is performed. If the comparison fails, the submission is rejected.

2. The method according to claim 1, characterized in that, The multi-level objects of the project cost include at least two different object levels, and include at least one of the following: list of sub-items, measure items, quantity of work, calculation results or indicators, as well as one of the following: professional, unit project, single project or project level; the project context includes project type, design stage, region, time, construction scale and structural form.

3. The method according to claim 1 or 2, characterized in that, Generating the standardized evidence unit includes: determining the original location, node path, page number, field path, or event location in the source data; mapping the source data fields to normalized fields in a preset evidence pattern, and performing unit conversion, enumeration normalization, time normalization, and semantic identifier normalization on the field values; binding the normalized fields to the engineering object identifier, engineering object hierarchical path, engineering object version, source data version, model version, and applicable specification version set; and generating a deterministic evidence digest based on the normalized field order, object binding, and version binding.

4. The method according to claim 1, characterized in that, The machine-executable trigger conditions and machine-executable exclusion conditions are represented by conditional expression trees, respectively; the variable and source binding includes variable identifier, data type, unit of measurement, source priority, allowed data version and missing data handling strategy; the expected effect model includes target object, effect type, calculation formula or inference model, benchmark, expected range and engineering output key.

5. The method according to claim 1 or 4, characterized in that, The value decision knowledge candidates are generated by at least one of the following methods: expert structured input, rule induction, statistical pattern mining, clustering or association analysis, vector retrieval, generative model reasoning, knowledge graph reasoning, causal analysis, or intelligent agent collaboration. After the candidates are generated, they are normalized and serialized according to the preset field order to generate candidate summaries.

6. The method according to claim 1, characterized in that, The versioning relationship determination strategy includes: when the applicable object scope is equivalent, the triggering condition and exclusion condition are semantically equivalent, the candidate optimization actions and expected effects overlap and there is no substantial difference in technical constraints, it is mapped as a duplicate relationship; when the object scope and condition interval have an intersection and the candidate optimization actions cannot be executed simultaneously or the technical constraint outputs are incompatible, it is mapped as a content layer conflict relationship; when the expected effect models have the same engineering output key and the target object, cost item, engineering quantity or indicator caliber overlaps, it is mapped as an effect overlap relationship; for content layer conflict relationships or effect overlap relationships, the target release context, release scope overlap results, effective time overlap results and engineering output key are further combined to determine whether a release layer conflict or duplicate output risk is formed.

7. The method according to claim 6, characterized in that, The release context conflict verification record includes the knowledge content version identifier, the planned release configuration identifier or the planned release configuration summary, the target release context, the conflicting knowledge content version identifier, the conflicting release configuration version identifier, the release scope overlap result, the effective time overlap result, the effect overlap result, the active set version at the time of verification, the current valid release set summary at the time of verification, the verification time, the conflict strategy version, the verification conclusion, and the record summary. When generating a release configuration version, activating an existing release configuration version, or generating and activating a new release configuration version to replace an existing release configuration version, if the currently activated set version or the current valid release set summary is inconsistent with the release context conflict verification record, the release context conflict verification is re-executed.

8. The method according to claim 1, characterized in that, The candidate admission verification batch record includes a candidate version, a knowledge relationship graph version, an input evidence set summary, a verification strategy version, a verification task set, a task result set, a blocking conclusion, a shadow freeze admission flag, a direct official release admission flag, and a batch summary; when the direct official release admission flag is true, the shadow freeze admission flag is also true.

9. The method according to claim 8, characterized in that, The candidate admission verification includes historical project replay verification, independent sample verification, counterexample or negative sample verification, and counterfactual verification. After the shadow release configuration version is generated, a shadow evaluation batch is generated separately. The shadow evaluation batch evaluates at least the shadow hit, effective manual modification, actual results, effect deviation, technical constraint results, version compatibility results, and shadow execution isolation results.

10. The method according to claim 8 or 9, characterized in that: When the shadow freeze access flag is true, only the creation of shadow release configuration versions is allowed; when the direct formal release access flag is true, the creation of formal release configuration versions is allowed; in the shadow release path, the creation of formal release configuration versions is only allowed when the shadow evaluation batch meets the formal release conditions.

11. The method according to claim 1, characterized in that: Candidate control status records include candidate identifier, candidate version, status, status version, status sequence number, verification matching eligibility, verification execution eligibility, freeze eligibility, effective time, previous status version or expected previous status summary, reason code, relationship graph version, admission batch version, idempotent key, and status summary; knowledge content eligibility status records include knowledge content version identifier, eligibility status record identifier, status, status version, status sequence number, new release citation eligibility, existing release operation eligibility, formal output eligibility, shadow execution eligibility, effective time, previous status version or expected previous status summary, trigger signal citation, idempotent key, and status summary; release control status records include release configuration version identifier, release status record identifier, status, status version, status sequence number, matching eligibility, execution eligibility, formal output eligibility, shadow output limitation, effective time, previous status version or expected previous status summary, activation record identifier, idempotent key, and status summary; the status sequence number under the same subject is kept monotonically increasing and unique through unique constraints and comparison with the preceding status.

12. The method according to claim 11, characterized in that, The knowledge content eligibility status record adopts an append-only immutable record; when the new release citation eligibility is false, the creation of a new release configuration version that cites the corresponding knowledge content version is prohibited; when the existing release execution eligibility is false, the knowledge registry excludes existing release configuration versions that cite the knowledge content version; when the formal output eligibility is false and the shadow execution eligibility is true, only shadow execution is allowed.

13. The method according to claim 1, characterized in that, The immutable knowledge content version includes the parent knowledge content version identifier, source candidate version, condition and variable snapshot, candidate optimization action and expected effect model snapshot, technical constraint snapshot, evidence summary set, knowledge relationship graph version, candidate admission verification batch version, model version set, specification version set, change field set, difference summary and knowledge version summary, and does not save the publication scope or publication running status.

14. The method according to claim 1 or 13, characterized in that, The immutable release configuration version includes a release configuration version identifier, a previous release configuration version identifier, a knowledge content version identifier, a release scope, a release mode, a grayscale ratio, a configuration effective time, a configuration expiration time, compatibility requirements, a release priority, a coexistence flag, a formal output configuration flag, a shadow output configuration flag, a release selection strategy version, and a release configuration summary. The release activation record includes an activation set version, an expected previous set summary, a valid set summary before the action, a valid set summary after the action, a commit status, a commit completion time, a transaction or commit identifier, and an idempotent key. When a release configuration version is generated and activated for the first time, the release configuration version, the initial release control state record, and the ACTIVATE release activation record are written in the same atomic commit unit. When an existing release configuration version is reactivated, the release configuration version is not regenerated or modified; only a new release control state record and an ACTIVATE release activation record are appended. A new release configuration version used to replace an existing release configuration version is associated with the existing release configuration version through a release replacement relationship record and is atomically written with the new version ACTIVATE record and the old version DEACTIVATE record.

15. The method according to claim 14, characterized in that, The release selection strategy version includes range specificity rules, release priority rules, gray-scale routing rules, and deterministic disambiguation rules with the same priority. Gray-scale routing uses a stable routing key generated by the project object version, knowledge identifier, and release selection strategy version. The release selection decision record includes the project object version, knowledge identifier, project output key, candidate release set summary, knowledge content eligibility status version, release control status version set, activation set version, release context conflict check record identifier set or conflict check set summary, release selection strategy version, gray-scale routing key and bucketing results, selected official release version identifier, selected shadow release version identifier set, exclusion reason mapping, and selection summary. For the same knowledge identifier, the same project object version, and the same project output key, only one release configuration version is allowed to be written into the official result set.

16. The method according to claim 1 or 15, characterized in that, The result execution and writing eligibility record includes a result execution and writing eligibility record identifier, eligibility stage, project object version, knowledge identifier, knowledge content version identifier, release configuration version identifier, release selection decision record identifier, engineering output key, result channel, knowledge content eligibility status version, release control status version, activation set version, target namespace, eligibility verification result, reason code, effective time, and record summary. The eligibility stage is either PRE_EXECUTION or PRE_WRITE. The PRE_EXECUTION record is used to control execution eligibility before model or action loading, and the PRE_WRITE record is used to control writing eligibility before writing results or formal objects. Both formal result records and shadow result records include a result identifier, project object version, knowledge content version identifier, release configuration version identifier, release selection decision record identifier, model version, result channel, engineering output key, output value and unit, input snapshot summary, result summary, creation time, and PRE_EXECUTION and PRE_WRITE result execution and writing eligibility record identifiers. The shadow execution isolation record includes a frozen input snapshot, isolation method, external call record, writing target, side effect check result, and record summary.

17. The method according to claim 1 or 16, characterized in that, The operational feedback evidence includes execution identifier, source event identifier, release selection decision record identifier, engineering output key, knowledge content version identifier, release configuration version identifier, project object version, matching record, execution record, manual decision record, predicted effect, actual effect, result channel, and feedback summary; the feedback anti-duplicate key is generated from at least the execution identifier, source event identifier, release selection decision record identifier, engineering output key, release configuration version identifier, and result channel.

18. A system for evidence-driven knowledge unit generation, verification, controlled release, and version evolution for multi-level engineering cost objects, characterized in that: include: The system comprises the following modules: evidence standardization, knowledge candidate generation, content relationship determination, candidate admission verification, knowledge content version and eligibility, release configuration, release context conflict verification, release status and activation, release selection and decision recording, engineering calculation and result execution and eligibility writing, shadow evaluation and execution isolation, operation feedback and evolution signal, and version submission audit. Specifically, the release context conflict verification module generates and verifies a release context conflict verification record bound to the activation set version and the currently valid release set summary before generating a release configuration version, activating an existing release configuration version, or generating and activating a new release configuration version to replace an existing one. This verification is re-verified when the activation set version or set summary changes. The release status and activation module atomically writes the release configuration version, initial release control status record, ACTIVATE release activation record, and new activation set version when the release configuration version is first generated and activated. When reactivating an existing release configuration version, it atomically appends a new release without regenerating or modifying the release configuration version. The system controls the state record, ACTIVATE record, and new activation set version. When generating and activating an alternative release configuration version, it atomically writes the new release configuration version, release substitution relationship record, new version ACTIVATE record, old version DEACTIVATE record, and new activation set version. The release selection and decision record module generates a replayable release selection decision record for the engineering output key and determines a unique official output version. The engineering calculation and result execution and write qualification module generates a result execution and write qualification record with the qualification stage PRE_EXECUTION before loading the model or action, and generates a result execution and write qualification record with the qualification stage PRE_WRITE before writing the official or shadow result. It controls model loading, target namespace, and result channel based on the records of the two stages. The shadow evaluation and execution isolation module executes the shadow model or action in an isolated environment and generates a shadow execution isolation record. The version submission audit module controls concurrent submissions through a monotonically increasing and unique state sequence number, previous state summary verification, activation set version, and expected previous set summary.

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 implements the steps of the method according to any one of claims 1 to 17.

Images