A carbon removal full life cycle certification data processing method, device and system based on data share identification and a storage medium

Abstract

The application discloses a carbon removal full-life-cycle certification data processing method, device, system and storage medium based on data share identification. A data processing system acquires or generates a source-side certification evidence object; based on the object, its field or related life cycle stage data, a data share identification corresponding to a physical biochar output share is generated or updated; a chain mapping relationship with multiple life cycle stage nodes is established with the identification as an anchor point, and a certification qualification state is determined based on certification judgment input data; when there is an abnormal state, the affected data share identification and its certification qualification state are determined based on the chain mapping relationship; and based on the state, write prevention, numerical deduction or accounting mutual locking are performed. The application improves the granularity adaptation, abnormal positioning and anti-repetition inclusion capability of the source-side continuous data and discrete life cycle certification data.

Description

Technical Field

[0001] This invention relates to the field of digital measurement, reporting and verification (dMRV) technology for carbon removal, specifically to a method, device, system and storage medium for processing carbon removal lifecycle verification data based on data share identification. Background Technology

[0002] Biochar carbon removal projects typically require the recording and verification of data related to raw material acquisition, transportation, continuous or quasi-continuous biomass carbonization production, output metering, packaging, storage, transportation, delivery, end-use or sequestration, and relevant testing. Existing carbon removal verification methodologies or registration rules usually focus on requirements such as raw material compliance, production process status, biochar testing results, lifecycle emissions, end-use destinations, and restrictions on repeated inclusion. At the engineering implementation level, these requirements need to be translated into a data processing workflow that is collectable, correlateable, disseminable, verifiable, and auditable.

[0003] In the source-side production stage, data acquisition, material propagation relationship modeling, spatiotemporal attribution calculation, discrete evidence boundary determination, and process status attribution can be performed on the continuous biomass carbonization production process through source-side computing nodes, thereby generating source-side verification evidence objects. These source-side verification evidence objects can demonstrate the correlation between a specific biochar production unit and the feed-side traceability records, process status attribution data, output physical quantity records, model parameter status, time synchronization status, measurement equipment calibration status, non-conformity records, or consistency verification information.

[0004] However, the source-side verification evidence object is not necessarily equivalent to the subsequent carbon removal accounting input unit. A source-side output unit may be broken down into multiple packaging units, storage units, transportation units, delivery units, or end-use shares; multiple source-side output units may also be merged into a verification declaration batch, a credit candidate share, or a credit statement object. Without a cross-lifecycle data fractionation and chain mapping mechanism, inconsistencies in granularity can easily arise between the source-side evidence object and the downstream verification, declaration, issuance, statement, retirement, or cancellation related datasets.

[0005] In continuous or quasi-continuous biomass carbonization production processes, feeding, pyrolysis reactions, and discharging typically occur continuously over time, while subsequent packaging, storage, transportation, delivery, end-use or sequestration, and carbon removal accounting are usually recorded at the batch, packaging unit, transportation unit, delivery unit, test sample, or accounting unit level. This results in a granularity inconsistency between the continuous process status data at the source and the discrete lifecycle data downstream.

[0006] When anomalies occur in a certain production time window, equipment operating status, test results, transportation records, or end-application records, existing systems can usually only mark the anomalies at the project level, batch level, or file level. It is difficult to accurately propagate the anomaly or correlate it in reverse to the affected physical biochar output share and its subsequent life cycle stage data. This can easily lead to the over-exclusion of qualified output, the under-exclusion of unqualified output, or the repeated writing, referencing, or inclusion of the same physical output share in different carbon removal accounting related datasets.

[0007] In real-world projects, a single non-compliant raw material input window may only affect a portion of the subsequent output; a single abnormal operating condition time window may only correspond to a portion of the dry-based biochar quality within several source-side output units; missing evidence for a transportation route may only affect the corresponding transportation unit or delivery unit; insufficient evidence for a single end-application route may only affect the specific end-application share. If only projects, batches, or the entire source-side evidence are considered as processing objects, the system will struggle to prevent the excessive exclusion of compliant output or the incorrect inclusion of non-compliant shares.

[0008] Furthermore, in the processes of carbon removal accounting, reporting, credit issuance, credit statement processing, credit transfer processing, and credit retirement or cancellation processing, there is a risk that the same physical and biochar output share may be repeatedly included in multiple accounting input datasets, repeatedly used in multiple registration agency reporting datasets, repeatedly generated as multiple credit candidate statements, or repeatedly issued or claimed by the purchaser. Existing supply chain traceability systems or ordinary carbon asset ledgers typically focus on recording the flow process, but lack accounting mutual exclusion locking, write rejection, and audit output mechanisms based on physical and biochar output shares.

[0009] Existing supply chain traceability systems or general industrial ERP systems typically track physical products, packaging units, or fixed batches. These tracked objects usually maintain physical consistency throughout the flow, and anomaly handling often manifests as freezing, releasing, or status-marking the entire batch. Continuous or quasi-continuous biochar production processes differ from ordinary physical product flows. Source-side feeding, pyrolysis reactions, and discharge occur continuously over time, while subsequent packaging, warehousing, transportation, delivery, end-use or sealing, and carbon removal accounting data are typically managed at the granularity of discrete stage nodes, discrete data records, or discrete accounting units. Therefore, an abnormal time window or non-conformity record may only affect a portion of the physical biochar output share in one or more subsequent discrete data shares, rather than affecting the entire batch. General supply chain traceability systems struggle to directly address the issues of granularity adaptation between continuous source-side data and discrete lifecycle verification data, cross-stage propagation of abnormal states, partial exclusion or deduction of affected shares, and duplicate inclusion of the same physical biochar output share in control.

[0010] For external verification platforms, registration agency systems, third-party audit terminals, or purchaser verification systems, simply receiving production batch reports or spreadsheets is insufficient to form a machine-auditable lifecycle evidence chain. Auditors or verification systems typically need to trace back from credit candidate shares, credit statement status, or interface data packets to source-side verification evidence objects, source-side output unit identification information, output physical quantity records, anomaly propagation records, verification eligibility status, write blocking records, write refusal status, accounting mutual exclusion lock status, and deduction calculation records. Existing systems lack technical solutions for generating audit traceability paths, audit drill-down indexes, structured audit evidence packages, or open query interface data packets around the same data share identifier.

[0011] Therefore, there is an urgent need for a digital measurement, reporting, and verification data processing technology solution based on the entire lifecycle of source-side verification evidence objects. This solution would enable the data processing system to acquire or generate source-side verification evidence objects, generate or update data share identifiers based on these objects, their fields, or associated lifecycle stage data, and characterize continuous source-side data into verification data processing granularity that can be associated, propagated, verified, deducted, or locked between data at different lifecycle stages. Furthermore, based on the lifecycle chain mapping relationship and verification judgment input data, the verification eligibility status would be determined, and at least one of write blocking, numerical deduction, or accounting mutual exclusion locking would be executed. This would improve the data granularity adaptability, status judgment accuracy, and the ability to prevent duplicate accounting and duplicate claims between source-side evidence from continuous biochar production and downstream verification datasets. Summary of the Invention

[0012] The present invention aims to solve the problem of inconsistent data granularity between the source-side physical biochar production share and the downstream discrete life cycle verification data formed in the continuous or quasi-continuous biomass carbonization production process. It enables the source-side verification evidence objects to be characterized by a verification data processing granularity that can be associated, propagated, verified, deducted or locked among data in multiple life cycle stages through data share identification.

[0013] This invention also aims to address the problem that existing systems have difficulty accurately associating abnormal states such as unqualified raw material input windows, abnormal operating condition time windows, storage and transportation anomalies, and insufficient evidence of end-use or sealing with the data share identifier corresponding to the same physical biochar production share, and that it is difficult to determine the affected data share identifier and its verification qualification status through forward propagation, reverse association, bidirectional verification, stage status query, or rule engine processing.

[0014] This invention also aims to address the lack of a systematic mechanism for writing prevention, numerical deduction, status update, accounting mutual exclusion locking, duplicate accounting or duplicate declaration detection, locking non-repeatable inclusion status, rejecting write status generation, and auditing output data or interface data packet generation based on the share of physical and biochar production in existing carbon removal verification data processing schemes.

[0015] This invention also aims to address the problem that ordinary supply chain traceability or carbon asset ledger systems only record the circulation process and lack the ability to align physical and biochar production share based on source-side verification evidence objects, generate or update data share identifiers, generate or read verification judgment input data, determine verification qualification status, process verification data, generate audit traceability paths, and provide interface output or open query capabilities to external verification platforms, registration agency systems, audit terminals, or purchaser verification systems.

[0016] To address the aforementioned technical problems, this invention provides a method, device, system, and storage medium for processing carbon removal lifecycle verification data based on data share identification. The method is executed by a carbon removal digital measurement, reporting, and verification data processing system. This data processing system can be a computing system deployed on a cloud server, an enterprise local server, a registry interface server, an external verification platform, an audit platform, a buyer verification system, an enterprise carbon asset management platform, a lifecycle stage data source, an edge collaboration server, or a combination of the above devices.

[0017] The data processing system acquires source-side verification evidence objects, or acquires relevant source-side data and generates source-side verification evidence objects based on the relevant source-side data. The source-side verification evidence objects correspond to source-side output units or at least a portion of physical biochar output shares in a continuous or quasi-continuous biochar production process. The source-side verification evidence objects may include at least one of the following: source-side output unit identification information, output baseline information, output physical quantity records, process status attribution data, non-conformity records, anomaly impact information, deduction input information, excluded carbon quantity, exclusion ratio, exclusion share, consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, or audit drill-down index.

[0018] In one embodiment, the data processing system may not perform the generation process of source-side verification evidence objects. Instead, it may use source-side verification evidence objects collected, generated, or sent by source-side computing nodes, industrial control cabinets, programmable logic controllers (PLCs), distributed control systems (DCS), industrial personal computers (IPCs), edge computing gateways, sensor data acquisition modules, or production equipment control systems as input data objects for lifecycle chain mapping, verification eligibility status determination, verification data processing, accounting mutual exclusion locking, status recording, audit traceability processing, or interface data packet generation. In another embodiment, the data processing system may receive relevant source-side data and generate source-side verification evidence objects based on that data. Therefore, the focus of this invention is on the fractionalization, status determination, write control, locking control, and audit output of source-side evidence objects or relevant source-side data after they enter the full lifecycle verification data processing system.

[0019] In one implementation, when the data processing system receives source-side related data via a communication network and generates source-side verification evidence objects based on the source-side related data, the source-side related data may include source-side output unit candidate identifiers, discharge reference time information, feeding time intervals, actual reaction participation time intervals, weighing records, packaging records, time-series segments of process operating parameters, process status attribution data or its index, non-conformity records, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio, exclusion share, time synchronization status, measuring equipment calibration status, object hash digest, source-side data reference address, trusted timestamp, or source-side evidence object index. The data processing system can generate source-side verification evidence objects based on the aforementioned source-side related data, containing at least one of the following: source-side output unit identifier information, output reference information, output physical quantity records, process status attribution data, non-conformity records, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio, exclusion share, consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, or audit drill-down index.

[0020] In one implementation, generating source-side verification evidence objects includes: performing field integrity checks on received source-side related data; determining output benchmark information based on discharge benchmark time information, feed time interval, actual reaction participation time interval, or weighing records; generating source-side output unit identification information based on source-side output unit candidate identifiers, output benchmark information, or packaging records; associating process status attribution data, non-conformity records, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio, or exclusion share to the source-side output unit identification information; and generating consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, or audit drill-down index associated with the above fields.

[0021] The data processing system generates or updates data share identifiers based on the source-side verified evidence object, source-side output unit identification information or output benchmark information in the source-side verified evidence object, or lifecycle stage data associated with the source-side verified evidence object. The data share identifier corresponds to or is associated with at least a portion of the physical biochar output share represented by the source-side verified evidence object, and is used to represent the at least a portion of the physical biochar output share in the data processing system as a verified data processing granularity capable of being associated, propagated, verified, deducted, or locked between data from different lifecycle stages.

[0022] The minimum data share corresponding to the data share identifier refers to a data processing unit that is determined or updated by the data processing system based on the source-side verification evidence object, fields in the source-side verification evidence object, or related lifecycle stage data, is associated with at least a portion of the physical biochar output, and can be independently subjected to lifecycle chain mapping, verification eligibility status determination, write blocking, numerical deduction, or accounting mutual exclusion locking. Therefore, the physical biochar output share itself is not equivalent to a data processing unit, but is represented and processed by the data share identifier within the data processing system.

[0023] The data processing system uses the data share identifier as an anchor point to establish a chain-like mapping relationship between the data share identifier and multiple lifecycle stage nodes. This chain-like mapping relationship may include at least one of the following: stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, and verification information associated with the data share identifier. The lifecycle stage nodes may include at least two stage nodes from the following stages: raw material acquisition, raw material transportation, production conversion, output measurement, material unloading and packaging, storage, transportation, delivery, end-use application or sealing, sample testing, certification declaration, registration agency interface, buyer's declaration verification, and data status stages related to carbon removal accounting, credit issuance, credit declaration, credit transfer, or credit retirement or cancellation.

[0024] The data processing system determines the verification eligibility status of the data share identifier based on the chained mapping relationship and verification judgment input data of at least one lifecycle stage node. The verification judgment input data includes at least one of the following: stage status data, abnormal status, target verification rule processing result, state transition rule, or rule engine output result. The stage status data may include stage eligibility status variables corresponding to at least one lifecycle stage node. These stage eligibility status variables characterize at least one of the following lifecycle stage node's data integrity, path determinism, target verification rule satisfaction status, abnormal impact status, supplementary verification status, interface return status, locked status, write refusal status, or duplicate declaration risk status.

[0025] The target verification rules can correspond to requirements regarding raw material compliance, production process status, biochar testing results, transportation records, end-use or storage records, lifecycle emissions, deduction parameters, and duplicate inclusion restrictions in carbon removal verification methodologies, registration system rules, external verification platform rules, project verification rules, or buyer declaration rules. These requirements are converted into verification judgment input data, stage status data, status fields, numerical fields, interface data, interface data packets, write rejection status, accounting mutual exclusion lock status, or audit output data in the data processing system. This invention does not limit the name, source, or version of specific target verification rules.

[0026] The abnormal state can be determined based on the stage state data, interface return status, or consistency verification result, or the target verification rule processing result can be generated based on at least one of the stage state data, the abnormal state, a preset threshold, a rule engine, a deduction parameter lookup table, stage state query results, or state transition rules. In one embodiment, when an abnormal state is detected at any lifecycle stage node, the data processing system propagates the abnormal state to the corresponding data share identifier based on the chain mapping relationship; the abnormal state can propagate forward along the chain mapping relationship to subsequent lifecycle stage nodes, or it can be associated backward with the corresponding source-side verification evidence object, source-side output unit identifier, batch identifier, packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, terminal application, or sealing path identifier. In another embodiment, the data processing system can directly determine the affected data share identifier and its verification qualification status associated with the abnormal state based on the chain mapping relationship; furthermore, it can determine the affected data share identifier and its verification qualification status associated with the abnormal state based on the stage state query result or the rule engine processing result, without requiring explicit execution of the abnormal state propagation step. The state transition rules or rule engine output can be stored as a state transition rule table, rule parameter table, deduction parameter lookup table, interface return status table or a combination thereof, and used to convert stage status data, abnormal status, target verification rule processing results, stage status query results or rule engine processing results into at least one verification qualification status among: eligible for inclusion, excluded, temporarily suspended, pending supplementary verification, included after adjustment, locked for non-repeatable inclusion or refused to write.

[0027] Based on the certification eligibility status, the data processing system performs certification data processing on the data share identifier or the data field corresponding to the data share identifier. This certification data processing includes at least one of write blocking, numerical deduction, or accounting mutual exclusion locking. Write blocking prevents the data share identifier from being written into the carbon removal accounting-related dataset. Numerical deduction updates the candidate values ​​for certification results, the values ​​eligible for accounting inclusion, the carbon removal-related numerical fields, or combinations thereof, corresponding to the data share identifier. In some embodiments, the carbon removal-related numerical fields include at least one of net carbon removal candidate values, verifiable dry biochar quantity, qualified biochar dry mass candidate values, the number of unitized certification result candidates, the number of carbon removal credit candidates, or related numerical fields. In some embodiments, the data processing system can also generate status records, including records updating the data share identifier or corresponding data field to an eligible inclusion, excluded, deferred inclusion, pending certification, included after adjustment, locked for non-repeatable inclusion, refused write, or other certification eligibility status.

[0028] The accounting mutual exclusion lock is used to restrict the repeated writing, referencing, or inclusion of data share identifiers or data objects corresponding to the same physical biochar output share in carbon removal accounting-related datasets. The accounting mutual exclusion lock status can prevent the same physical biochar output share from being repeatedly written into another accounting input dataset, output report declaration dataset, registration agency declaration dataset, carbon removal credit candidate declaration dataset, credit issuance-related dataset, credit declaration-related dataset, credit transfer-related dataset, or credit retirement or cancellation-related dataset. When it is detected that another dataset references a data share identifier already in the accounting mutual exclusion lock status, or references a data object corresponding to the same physical biochar output share as the locked data share identifier, the data processing system can generate a duplicate declaration risk status, a duplicate accounting risk status, a locked non-repeatable inclusion status, or a write rejection status.

[0029] In some implementations, the data processing system can also generate status records or audit traceability data, which may include audit output data, audit traceability paths, or interface data packets. The data processing system can generate audit output data based on at least one of the following: data share identifier, chained mapping relationship, verification judgment input data, stage status data, abnormal status, target verification rule processing result, verification eligibility status, write blocking flag, write refusal status, or accounting mutual exclusion lock status. Audit output data may include structured audit evidence packages, audit traceability paths, audit drill-down indexes, lock status records, verification eligibility status outputs, abnormal status propagation records, write blocking records, write refusal reasons, deduction calculation records, or lock status hash digests. The audit output data or audit traceability paths may be output, sent, distributed, open for querying, or written to at least one of the following interface data packets: external verification platform, registration agency system, audit terminal, buyer verification system, enterprise carbon asset management platform, or lifecycle stage data source.

[0030] By using the aforementioned data share identifier, chain mapping relationship, verification judgment input data, write blocking flag, numerical deduction result, and accounting mutual exclusion lock status, the present invention enables the data processing system to uniformly control the write eligibility, numerical deduction result, or lock status of the same physical biochar production share in the relevant datasets for accounting, declaration, issuance, statement, transfer, retirement, or cancellation without relying on manual item-by-item judgment; in some embodiments, it can also generate status update records, audit traceability records, or interface outputs.

[0031] This invention also provides a carbon removal lifecycle verification data processing device based on data share identifiers. The device includes a communication interface, a memory, and a processor connected to the communication interface and the memory. The communication interface is used to acquire source-side verification evidence objects or to receive source-side related data, and to communicate with at least one of the following: source-side computing nodes, external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources. The memory stores at least one of the following: computer programs, source-side verification evidence objects, source-side related data, source-side evidence object indexes, source-side data reference addresses, object hash digests, data share identifiers, chained mapping relationships, verification judgment input data, stage status data, abnormal states, abnormal impact information, target verification rule processing results, state transition rules, rule engine output results, verification eligibility status, write blocking flags, write refusal status, numerical deduction processing results, accounting mutual exclusion lock status, lock status hash digests, registration agency interface records, interface data packets, status records, audit drill-down indexes, or audit traceability data. The processor is configured to perform the operations described in any embodiment of the present invention and to output, send, distribute, or open for querying the status record, audit trace data, calculate the mutual exclusion lock status, refuse to write status, lock status hash digest, or interface data packet through the communication interface.

[0032] The present invention also provides a carbon removal lifecycle verification data processing system based on data share identification. The system includes an evidence acquisition and generation module, a data share management module, a lifecycle chain mapping module, a verification qualification determination module, a verification data processing module, an accounting mutual exclusion locking module, a locking status storage module, and an audit output module. The evidence acquisition and generation module acquires source-side verification evidence objects or receives relevant source-side data and generates source-side verification evidence objects based on that data. The data share management module generates or updates data share identifiers based on the source-side verification evidence objects, source-side output unit identification information or output benchmark information within the source-side verification evidence objects, or lifecycle stage data associated with the source-side verification evidence objects. The lifecycle chain mapping module establishes a chain mapping relationship between the data share identifiers and multiple lifecycle stage nodes. The verification qualification determination module determines the verification qualification status based on the chain mapping relationship and verification judgment input data. In some embodiments, an abnormal status handling module or an abnormal status propagation module is set as an independent functional module or integrated into the verification qualification determination module, used to determine the abnormal status based on the chain mapping relationship. The affected data share identifier of the linked data; the verification data processing module is used to execute at least one of write blocking, numerical deduction, or accounting mutual exclusion lock based on the verification eligibility status; the accounting mutual exclusion lock module is used to generate accounting mutual exclusion lock status, and generate a duplicate declaration risk status, duplicate accounting risk status, lock non-repeatable inclusion status, or write rejection status when it detects duplicate reference to the same data share identifier or the same physical biochar production share data object; the lock status storage module is used to store, index, output, or distribute at least one of accounting mutual exclusion lock status, lock status hash digest, write rejection status, or registration agency interface record to external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or life cycle stage data sources; the audit output module is used to generate audit output data, audit traceability paths, or interface data packets, and output, send, distribute, open for querying, or write the audit output data, audit traceability paths, or interface data packets to at least one of external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or life cycle stage data sources.

[0033] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements the carbon removal lifecycle verification data processing method based on data share identification as described in any embodiment of the present invention.

[0034] The beneficial effects of this invention are as follows: The core innovation of this invention lies in introducing a data share identifier corresponding to or associated with the physical biochar output share between continuous or quasi-continuous biochar production data at the source and downstream discrete lifecycle verification data. This data share identifier serves as a common anchor point for the entire lifecycle verification data processing. Through this technology, source-side verification evidence is no longer merely referenced by downstream systems as project-level, batch-level, or document-level evidence, but is transformed into verification data processing granularity capable of being independently correlated, propagated, verified, excluded, deducted, locked, and audited. Therefore, this invention solves the problem of inconsistency in granularity between continuous source-side production data and discrete packaging, transportation, delivery, end-use or storage, verification application, and credit-related data, providing a unified data processing foundation for subsequent verification eligibility status determination and write control.

[0035] Based on the aforementioned data share identifiers, this invention further establishes a chain-like mapping relationship between data share identifiers and multiple lifecycle stage nodes, ensuring traceable data consistency for the same physical biochar production share across source-side evidence objects, packaging units, inventory units, transportation units, delivery units, end-use or sealing paths, verification declaration datasets, and credit issuance, declaration, transfer, retirement, or cancellation-related data statuses. Therefore, when any lifecycle stage experiences missing evidence, data conflicts, path uncertainty, insufficient end-use evidence, or other abnormal states, the data processing system can, based on the chain-like mapping relationship, stage status queries, or rule engine processing, pinpoint the impact of the anomaly to the affected data share identifier, rather than only performing coarse-grained processing on the entire project, the entire batch, or the entire source-side evidence object.

[0036] Because the impact of anomalies can be pinpointed to specific data share identifiers, this invention can determine the certification eligibility status at this granularity and perform write blocking, numerical deduction, or accounting mutual exclusion locking. Therefore, for physical biochar output shares that are only partially affected by anomalies, the system can generate excluded data shares and remaining included data shares, or form an adjusted inclusion status and perform numerical deductions on the net carbon removal candidate value field, the verifiable dry biochar quantity field, the qualified biochar dry mass candidate value field, the unitized verification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields. This processing method can avoid excessive exclusion of qualified output due to project-level or batch-level anomaly marking, while reducing the risk of anomaly-affected output shares being incorrectly included in carbon removal accounting.

[0037] Based on the same data share identifier and its corresponding physical biochar production share, this invention further restricts duplicate writing, duplicate referencing, or duplicate inclusion through a mutual exclusion locking state. This locking is not merely a duplicate check for a single surface identifier, but can apply mutual exclusion control to data share identifiers or data objects corresponding to the same physical biochar production share. Therefore, even if subsequent accounting input datasets, registration agency declaration datasets, credit candidate declaration datasets, credit declaration-related datasets, credit transfer-related datasets, or credit retirement or cancellation-related datasets use different data objects or different credit candidate share identifiers, as long as they correspond to the same physical biochar production share, the system can still generate a duplicate declaration risk state, a duplicate accounting risk state, a locked non-duplicate inclusion state, or a write rejection state. Thus, this invention improves the ability to prevent the same physical biochar production share from being repeatedly accounted for, declared, or included.

[0038] Since the data share identifier, chain mapping relationship, verification eligibility status, and accounting mutual exclusion lock status are all established around the same physical biochar production share, this invention can generate status records, audit output data, audit traceability paths, or interface data packages corresponding to the data share identifier. External verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources can use the audit traceability paths or interface data packages to reverse locate from the credit candidate share, credit statement status, or registration agency interface records to the source-side verification evidence object, lifecycle stage data, abnormal status propagation records, verification eligibility status, write blocking records, numerical deduction records, and accounting mutual exclusion lock status. Therefore, this invention improves the machine readability, reconstructability, and verifiability of the entire lifecycle verification data, and reduces the workload of manually piecing together evidence chains.

[0039] Therefore, the beneficial effect of this invention lies not merely in recording more lifecycle data, but in transforming continuous production evidence from the source side into certified data units that can be uniformly processed by downstream certification, declaration, and auditing systems through a continuous data processing mechanism of "data share identification - chain mapping relationship - certification eligibility status - accounting mutual exclusion lock / audit output". This mechanism can simultaneously improve the granularity adaptability between source-side evidence and downstream certified data, the accuracy of anomaly location, the ability to partially exclude or deduct data, the ability to prevent double accounting, and the efficiency of audit traceability, thereby forming a data processing effect that differs from ordinary supply chain traceability systems or ordinary carbon asset ledgers. Attached Figure Description

[0040] Figure 1This is a schematic diagram of the overall structure of a carbon removal lifecycle verification data processing system based on data share identification, showing the logical relationships between source-side computing nodes, communication networks, data processing systems, external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, and data sources at each stage of the lifecycle.

[0041] Figure 2 This diagram illustrates the mapping relationship between data share identifiers and physical biochar production shares, showing one-to-one, one-to-many, many-to-one, or many-to-many relationships between source-side verified evidence objects, production batches, packaging units, inventory units, transportation units, delivery units, end-use or storage path shares, and carbon removal credit candidate shares, as well as parent-child data share relationships, splitting relationships, merging relationships, or share ratio relationships.

[0042] Figure 3 This diagram illustrates the lifecycle chain mapping relationship, showing the chain relationship between data share identifiers and stages such as raw material acquisition, raw material transportation, production transformation, output measurement, packaging, storage, transportation, delivery, end-use application or sealing, sample testing, certification declaration, registration agency interface, buyer declaration verification, credit issuance, credit declaration, credit transfer, and credit retirement or cancellation.

[0043] Figure 4 This diagram illustrates the input data and abnormal status handling for verification judgment, showing the relationships between stage status data, stage eligibility status variables, abnormal status, target verification rule processing results, status transition rules, rule engine output results, verification judgment input data, forward propagation, reverse association, bidirectional verification, stage status query, rule engine processing, affected data share identifier, and verification eligibility status.

[0044] Figure 5 is a schematic diagram of the determination of certification eligibility status and certification data processing. It shows the process of determining the certification eligibility status based on data share identifier, chain mapping relationship, certification judgment input data or abnormal status, and performing write blocking, value deduction or accounting mutual exclusion locking on the corresponding dataset or data field when the certification eligibility status is eligible for inclusion, excluded, temporarily suspended, pending supplementary certification, included after adjustment, locked for non-repeatable inclusion or refused to write. In some implementations, status records or audit traceability data can also be generated.

[0045] Figure 6This diagram illustrates the structure of a mutually exclusive lock state, showing the relationships between the lock identifier, data share identifier, lock object, lock scope, lock source, lock time, lock duration, lock release condition, hash of the previous lock record, hash of the current lock record, trusted timestamp, duplicate declaration risk state, duplicate accounting risk state, lock cannot be included repeatedly, write refusal reason, lock state table, hash chain storage unit, append-only log storage unit, immutable storage unit, trusted timestamp storage unit, registry interface data table, external verification platform communication records, relevant records of the purchaser verification system, and audit drill-down index.

[0046] Figure 7 This diagram illustrates the audit output data structure, showing the data share identifier, source-side verification evidence object index, source-side output unit identifier information, output physical quantity record, chain mapping relationship, lifecycle stage node status, verification judgment input data, stage status data, stage qualification status variable, abnormal status, abnormal status propagation record, target verification rule processing result, status transition rule identifier, verification qualification status, write blocking flag, accounting mutual exclusion lock status, exclusion record, record to be supplemented verification, deduction calculation record, write refusal reason, lock status hash digest, audit drill-down index, and audit traceability path and external output relationship between interface data packets.

[0047] Figure 8 This diagram illustrates the cross-lifecycle processing of non-conforming item records, excluded carbon quantity, excluded ratio, or excluded share. It shows the relationship between the non-conforming raw material input window, abnormal operating condition time window, discharge impact time window, affected output unit candidate identifier, affected data share identifier, excluded carbon quantity, excluded ratio, excluded data share, remaining data share that can be included, verification eligibility status, write blocking flag, adjusted inclusion status, numerical deduction, field update record, accounting mutual exclusion lock status, and audit output data.

[0048] Figure Label Explanation: 100 represents the source-side computing node; 110 represents the source-side verification evidence object; 120 represents the communication network; 200 represents the data processing system; 210 represents the communication interface; 220 represents the processor; 230 represents the memory; 240 represents the evidence acquisition and generation module; 300 represents the data share management module; 310 represents the data share identifier; 320 represents the physical biochar production share; 330 represents the carbon removal credit candidate share; 400 represents the lifecycle chain mapping module or lifecycle chain mapping relationship; 410 represents the lifecycle stage node; 420 represents the stage status data or stage eligibility status variable; 430 represents the verification judgment input data; 440 represents the target verification rule processing result; 500 510 represents an abnormal state handling module, an abnormal state propagation module, or an abnormal state handling functional unit integrated into the certification qualification determination module 600; 520 represents an abnormal state or abnormal state propagation record; 530 represents a non-compliance record; 540 represents excluded carbon quantity, exclusion ratio, or exclusion share; 600 represents the remaining data share that can be included; 610 represents the certification qualification determination module; 620 represents the certification qualification status; 630 represents the certification data processing module; 640 represents a status update record, value deduction record, or field update record; 650 represents a write refusal status; 700 represents the accounting mutual exclusion locking module; 710 represents the accounting mutual exclusion locking status; 720 represents the lock status table; 730 represents a hash chain storage unit; 740 represents an immutable storage unit; 750 represents an append-only log storage unit; 760 represents a trusted timestamp unit; 770 represents the registration agency interface data table; 780 represents the lock status hash digest; 790 800 represents the locked state storage module; 810 represents the audit output module; 820 represents the audit output data; 830 represents the audit traceability path; 840 represents the audit drill-down index; 900 represents the interface data packet; 910 represents the registration agency system; 920 represents the audit terminal; 930 represents the lifecycle stage data source; 940 represents the buyer verification system; 950 represents the enterprise carbon asset management platform.

[0049] Figures 1 to 8 This paper describes the specific implementation of the present invention from the aspects of system structure, data share identification, lifecycle chain mapping, verification judgment input data, abnormal state propagation, stage state query, rule engine processing, verification qualification status determination, write blocking, value deduction, accounting mutual exclusion locking, and corresponding status records, audit output, interface data packets, and cross-lifecycle processing of non-compliance items. The accompanying drawings are only for illustrating the technical solution of the present invention and do not constitute a limitation on the number of modules, module names, physical deployment locations, number of communication links, data structure forms, number of lifecycle stages, or calculation order. Detailed Implementation

[0050] The following combination Figures 1 to 8 The present invention will be further illustrated by specific embodiments. It should be understood that the following embodiments are used to explain the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. The specific values, data fields, communication protocols, model parameters, state names, data structures and interface forms in each embodiment can be adjusted according to the actual carbon removal project, verification standards, registration agency interfaces, purchaser verification systems or enterprise data systems.

[0051] In this invention, the determination of certification eligibility status, write blocking, numerical deduction, and accounting mutual exclusion locking are all executed by the data processing system based on data share identifiers, chain mapping relationships, and certification judgment input data, without relying on manual item-by-item judgment of whether to include carbon removal credit accounting. The write blocking, numerical deduction, and accounting mutual exclusion locking can be executed before database writing, interface submission, message queue publishing, registration agency declaration package generation, credit statement dataset update, interface data packet generation, or open query, forming write control, numerical field control, or mutual exclusion locking control at the data processing system level. In some embodiments, the data processing system can also generate status records, audit traceability data, or interface data packets. The credit issuance, credit statement, credit transfer, or credit retirement or cancellation related content in this invention are all processed as datasets, status fields, interface records, locked objects, or audit output fields in the data processing system, without limiting their commercial and legal effects themselves.

[0052] Unless the context clearly indicates otherwise, the term "source-side verification evidence object" in this specification refers to a data object distributed to verification, auditing, evidence storage, or external verification platforms that corresponds to the biochar production process, biochar output unit, or biochar physical output share. This object can be generated by source-side computing nodes or by a data processing system based on relevant source-side data received through a communication network. The object may include source-side output unit identification information, output baseline information, output physical quantity records, process status attribution data, non-conformity records, anomaly impact information, deduction input information, excluded carbon quantity, exclusion ratio, exclusion share, consistency verification information, audit drill-down index, object hash digest, source-side evidence object index, source-side data reference address, trusted timestamp, model parameter status, time synchronization status, or measurement equipment calibration status. The output baseline information may include at least one of the following: discharge baseline time information, discharge metering time interval, feed time interval, actual reaction participation time interval, weighing time information, packaging time information, or source-side equipment event time information.

[0053] In this specification, "data share identifier" refers to an identifier generated or updated by the data processing system for at least a portion of the physical biochar production share. The data share identifier corresponds to or is associated with at least a portion of the physical biochar production share represented by the source-side verification evidence object, and is used to convert source-side data generated during continuous or quasi-continuous biochar production processes into verification data processing granularity capable of being correlated, propagated, verified, deducted, updated, or locked between data at different lifecycle stages. The data share identifier can serve as a common anchor point in lifecycle chain mapping, verification eligibility status determination, write blocking, deduction, status update, accounting mutual exclusion locking, status output, interface data packet generation, or audit traceability processing.

[0054] In this specification, "verification determination input data" refers to the input data used by the data processing system to determine the verification eligibility status of the data share identifier. This includes at least one of the following: stage status data, abnormal status, interface return status, stage status query result, target verification rule processing result, status transition rule, or rule engine output result. The abnormal status can be determined based on the stage status data, interface return status, or consistency verification result. The target verification rule processing result can be generated based on at least one of the following: stage status data, abnormal status, preset threshold, rule engine, deduction parameter lookup table, stage status query result, or status transition rule. The rule engine output result may include at least one of the following: verification eligibility status candidate value, deduction parameter, exclusion ratio, pending verification flag, duplicate declaration risk flag, duplicate accounting risk flag, locked non-repeatable inclusion flag, or refused write flag. The data share identifier types, stage status data, abnormal status, deduction input fields, deduction rules, lock status fields, or audit output fields listed in this specification are all exemplary data fields or status variables for performing lifecycle chain mapping, certification qualification status determination, certification data processing, accounting mutual exclusion locking, or audit traceability processing around the data share identifier. Without changing the above data processing mechanism, those skilled in the art can select, combine, replace, or extend the above fields, statuses, or rules according to the lifecycle stage data source, external certification platform interface, registration agency interface, or target certification rules.

[0055] In this specification, "batch biochar" can refer to a physical output unit determined during continuous biomass carbonization production based on discharge time windows, weighing records, packaging records, transfer records, temporary storage records, release records, production scheduling information, or source-side equipment event signals. "Quasi-continuous biochar production process" in this specification refers to a data processing scenario where at least one stage of feeding, pyrolysis reaction, or discharge occurs continuously within multiple adjacent or shortly spaced time windows during the production cycle, and the corresponding physical biochar output share needs to be determined based on time windows, discharge metering intervals, equipment events, or packaging records.

[0056] The "physical biochar production share" in this specification can be all or part of a batch of biochar, or at least a portion of the physical output formed by merging multiple batches of biochar. The physical biochar production share itself is a physical object or physical share; in the data processing system, the physical biochar production share is characterized by a data share identifier as a data processing unit that can be individually executed for lifecycle chain mapping, qualification status determination, write blocking, value deduction, status update, accounting mutual exclusion locking, status output, interface data packet generation, or audit traceability processing.

[0057] In this specification, "carbon removal credit candidate share" can be a unitized verification result or carbon removal credit accounting candidate data unit formed after performing dry mass determination, carbon content determination, stability or persistence parameter processing, project emission deduction, uncertainty adjustment or verification eligibility status determination and verification data processing on the share of physical and biochar production. In one embodiment, the carbon removal credit candidate share can be represented as a carbon removal credit candidate data unit corresponding to the unitized verification result or carbon removal credit unit measurement granularity, and the carbon removal credit candidate data unit corresponds to a candidate value range that is less than one, equal to one, or greater than one unitized verification result or carbon removal credit unit.

[0058] The unitized verification result or carbon removal credit unit can be the unitized net carbon removal amount defined by the carbon removal verification or registration system. This invention does not limit the name, face value, registration agency or verification standard of the specific unitized verification result or carbon removal credit unit.

[0059] In one embodiment, the physical biochar production share corresponds to a biochar production batch, biochar usage batch, bag-level unit, transportation unit, delivery unit, end-use unit, or a portion thereof in the carbon removal verification methodology; after verification eligibility status determination and verification data processing, the physical biochar production share is used to determine the qualified biochar dry mass, carbon reserves, net carbon removal, unitized verification results, or number of carbon removal credit candidates.

[0060] In one implementation, the chained mapping relationship can be implemented through relational data tables, graph databases, directed graphs, index tables, event streams, message topics, hash chains, or combinations thereof. The relational data tables may include a data share table, a source-side evidence object table, a lifecycle stage table, a stage data reference table, an anomaly propagation record table, a lock status table, an interface data packet table, and an audit index table. Specifically, the data share table records data share identifiers and their corresponding or associated physical biochar production shares; the source-side evidence object table records source-side verified evidence object indexes, source-side production unit identifiers, and production benchmark information; the lifecycle stage table records stage node identifiers and stage types; the stage data reference table records stage node identifiers, stage data references, upstream stage relationships, and downstream stage relationships; the anomaly propagation record table records anomaly states, propagation directions, affected data share identifiers, and propagation results; the lock status table records accounting mutual exclusion lock statuses, lock status hash digests, or reasons for write refusal; the interface data packet table records interface data packets that are output, sent, distributed, or open for querying; and the audit index table records audit drill-down indexes associated with data share identifiers.

[0061] In one implementation, data share identification can be achieved through a data share identification generation or update table. The data share identification generation or update table may include at least one of the following fields: data share identification, source-side verification evidence object index, source-side output unit identification information, output baseline time information, feed time interval, actual reaction participation time interval, output metering time interval, output physical quantity record, dry basis quality field, share ratio field, parent data share identification, child data share identification, lifecycle stage data reference, update source, object hash digest, generation timestamp, update time, registration agency interface record identifier, interface data packet identifier, or audit drill-down index.

[0062] In one implementation, when a source-side verification evidence object corresponds to multiple packaging units, inventory units, transportation units, delivery units, or end-application shares, the data processing system can generate multiple sub-data share identifiers and maintain the association with the original data share identifier through the parent data share identifier field. When multiple source-side verification evidence objects correspond to the same delivery unit, end-application share, or verification declaration data unit, the data processing system can establish a many-to-one mapping relationship between multiple data share identifiers and data references in the same stage. The data processing system can also generate remaining data shares that can be included or adjusted data shares based on splitting relationships, merging relationships, share ratio relationships, or excluding data shares.

[0063] In one implementation, the data share identifier can be generated or updated based on at least one of the following: source-side verified evidence object, source-side output unit identifier information, output benchmark information, share ratio field, packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, terminal application or sealing path identifier, lifecycle stage data, generation timestamp or object hash digest; the generation or update can be implemented using database primary key, hash digest, index encoding, field concatenation encoding, stage data reference update or a combination thereof.

[0064] In one implementation, the chained mapping relationship can be implemented using a chained mapping relationship table. The chained mapping relationship table may include at least one field selected from the following: data share identifier, lifecycle stage node identifier, stage type, stage data reference, upstream stage node identifier, downstream stage node identifier, stage status data, stage eligibility status variable, abnormal status identifier, target verification rule processing result, status transition rule identifier, rule engine output result, interface return status, locked status, write-rejected status, interface data packet identifier, verification digest, update time, or audit drill-down index.

[0065] In one implementation, the stage data reference may point to at least one of the following: raw material acquisition record, raw material transportation record, production conversion record, output measurement record, packaging record, inventory record, transportation record, delivery record, end-use or sealing record, sample testing record, certification declaration dataset, registration agency interface dataset, buyer's declaration verification dataset, credit issuance related dataset, credit statement related dataset, credit transfer related dataset, or credit retirement or cancellation related dataset.

[0066] In one implementation, the chained mapping table can be implemented using relational database foreign keys, directed graph edges, graph database indexes, event stream indexes, message topics, hash chains, or combinations thereof. When lifecycle stage nodes undergo splitting, merging, status updates, interface returns, buyer declaration verification, or data share updates, the data processing system can update the corresponding upstream stage node identifier, downstream stage node identifier, stage data reference, interface data packet identifier, or verification digest based on the data share identifier.

[0067] In one implementation, the mutual exclusion locking mechanism includes the following steps: The data processing system receives a write, reference, or inclusion request for a data share identifier; queries whether there is a valid locking record for the data share identifier and its corresponding or associated physical biochar production share or data object; when there is no valid locking record and the certification eligibility status meets the preset inclusion conditions, a locking record is generated, wherein the locking record includes at least one of the following: data share identifier, locking object, locking scope, locking source, locking time, locking status summary, previous locking record summary, current locking record summary, and audit index; the locking record is written to at least one of the following: locking status table, append-only log, hash chain, immutable storage unit, trusted timestamp storage unit, registration agency interface data table, external certification platform communication record, or relevant record of the buyer verification system, or buyer declaration verification record; when a subsequent request references the same data share identifier, the same physical biochar production share, or a data object corresponding to the same physical biochar production share again, the data processing system generates a duplicate declaration risk status, a duplicate accounting risk status, a locked non-repeatable inclusion status, or a write rejection status.

[0068] In one implementation, the data processing system can determine the certification eligibility status of a data share identifier using a certification eligibility status transition table. The certification eligibility status transition table may include at least one of the following fields: status transition rule identifier, input anomaly type, stage status data, stage status query result, interface return status, target certification rule processing result, supplementary certification status, exclusion ratio, deduction parameter, duplicate declaration risk flag, duplicate accounting risk flag, lock non-duplicate inclusion flag, refuse write flag, and output certification eligibility status or rule update time.

[0069] In one implementation, when the input anomaly type is insufficient evidence for terminal use and the supplementary certification status is not supplemented, the output certification eligibility status can be pending supplementary certification or postponed inclusion; when the anomaly impact ratio or exclusion ratio is 100%, the output certification eligibility status can be excluded; when the anomaly impact ratio or exclusion ratio is less than 100% and there are deduction parameters, the output certification eligibility status can be included after adjustment; when it is detected that the same data share identifier, the same physical biochar production share, or the data object corresponding to the same physical biochar production share already has a valid accounting mutual exclusion lock status, the output certification eligibility status can be locked and cannot be included repeatedly, or a write rejection status can be generated.

[0070] In one implementation, the certification eligibility status transition table can be read by a rule engine, and the stage status data, stage status query results, interface return status, abnormal status, target certification rule processing results, deduction parameter lookup table or status transition rules can be converted into at least one certification eligibility status among: eligible for inclusion, excluded, temporarily suspended, pending supplementary certification, included after adjustment, locked and cannot be included again, or refused to write.

[0071] In one implementation, the accounting of mutual exclusion lock status can be implemented using a lock status table. The lock status table may include at least one field from the following: lock identifier, data share identifier, locked object, lock scope, lock source, lock time, lock duration, lock release condition, lock status hash digest, previous lock record hash, current lock record hash, trusted timestamp, write request result, write rejection reason, registry interface record identifier, external verification platform communication record identifier, buyer verification system related record or buyer declaration verification record identifier, or audit drill-down index.

[0072] In one implementation, when the data processing system receives a write, reference, inclusion, or declaration request for a data share identifier, it queries the lock status table. If a valid lock record already exists for the data share identifier, its corresponding physical biochar production share, or a data object corresponding to the same physical biochar production share, the data processing system generates a write rejection status, a duplicate accounting risk status, a duplicate declaration risk status, or a lock-and-not-repeat-inclusion status. If no valid lock record exists and the certification eligibility status meets the preset inclusion conditions, the data processing system writes the corresponding dataset and generates a new accounting mutual exclusion lock status.

[0073] In one implementation, the audit traceability table may include at least one field selected from the following: data share identifier, source-side verification evidence object index, source-side output unit identifier information, output physical quantity record, lifecycle stage node identifier, stage data reference, verification qualification status, abnormal status propagation record, deduction calculation record, exclusion record, pending verification record, write blocking flag, accounting mutual exclusion lock status, write refusal reason, lock status hash digest, interface data packet identifier, audit drill-down index, or consistency verification information. The lock status table, audit traceability table, or interface data packet table may be written to at least one of the following: relational database, append-only log, hash chain, immutable storage unit, trusted timestamp unit, registration agency interface data table, external verification platform communication records, buyer verification system, or lifecycle stage data source.

[0074] Example 1: Main Process Example This embodiment can be combined with Figure 1 , Figure 3 , Figure 4 , Figure 5and Figure 7 Understood. This embodiment illustrates the overall processing flow of the carbon removal lifecycle verification data processing method based on data share identification. The data processing system acquires source-side verification evidence objects through a communication network, or receives relevant source-side data through a communication network and generates source-side verification evidence objects based on the relevant source-side data; the source-side verification evidence objects correspond to source-side output units or at least a portion of physical biochar output shares in a continuous or quasi-continuous biochar production process.

[0075] The data processing system executes S1 to acquire or generate source-side verification evidence objects. In one embodiment, the source-side verification evidence objects are generated and sent to the data processing system by source-side computing nodes, industrial control cabinets, programmable logic controllers, distributed control systems, industrial personal computers, edge computing gateways, sensor data acquisition modules, or production equipment control systems. In another embodiment, the data processing system receives relevant source-side data through a communication network and generates source-side verification evidence objects based on the relevant source-side data. The communication network may include the Industrial Internet, enterprise local area networks, leased lines, virtual private networks, message queues, API interfaces, file exchange channels, external verification platform interfaces, registry interfaces, or lifecycle stage data source interfaces.

[0076] The source-side verification evidence object may include at least one of the following: source-side output unit identification information, output baseline information, output physical quantity records, process status attribution data, non-conformity records, anomaly impact information, deduction input information, excluded carbon quantity, exclusion ratio, exclusion share, consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, or audit drill-down index. Therefore, the data processing system can receive the complete source-side verification evidence object, or it can receive the object index, hash digest, reference address, and necessary fields to facilitate data drill-down during subsequent auditing or verification.

[0077] The data processing system executes S2, generating or updating a data share identifier based on the source-side verification evidence object, the source-side output unit identification information or output benchmark information in the source-side verification evidence object, or lifecycle stage data associated with the source-side verification evidence object. The data share identifier corresponds to or is associated with at least a portion of the physical biochar output share and is used to convert source-side data generated during continuous or quasi-continuous biochar production processes into verification data processing granularity capable of being correlated, propagated, verified, deducted, or locked between data at different lifecycle stages.

[0078] The data processing system executes S3, using the data share identifier as an anchor point to establish a chain mapping relationship between the data share identifier and multiple lifecycle stage nodes. The chain mapping relationship may include at least one of the following: stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, and verification information associated with the data share identifier. The lifecycle stage nodes may include at least two stage nodes from the following stages: raw material acquisition stage, raw material transportation stage, production conversion stage, output measurement stage, output packaging stage, storage stage, transportation stage, delivery stage, end-use application or sealing stage, sample testing stage, certification declaration stage, registration agency interface stage, buyer's declaration verification stage, and data status stages related to carbon removal accounting, credit issuance, credit declaration, credit transfer, or credit retirement or cancellation.

[0079] The data processing system executes step S4, determining the verification eligibility status of the data share identifier based on the chained mapping relationship and verification judgment input data for at least one lifecycle stage node. The verification judgment input data may include at least one of stage status data, abnormal states, target verification rule processing results, state transition rules, or rule engine output results. When the verification judgment input data includes an abnormal state, the data processing system determines the affected data share identifier associated with the abnormal state based on the chained mapping relationship, and determines the verification eligibility status of the affected data share identifier.

[0080] The data processing system executes step S5, which, based on the verification eligibility status, performs verification data processing on the data share identifier or the data field corresponding to the data share identifier. The verification data processing includes at least one of write blocking, numerical deduction, or mutual exclusion locking. Specifically, write blocking can be used to prevent the data share identifier from being written to the carbon removal accounting-related dataset; numerical deduction can be used to update the verification result candidate value, the accounting value that can be included, the carbon removal-related numerical field, or a combination thereof, corresponding to the data share identifier; in some embodiments, the carbon removal-related numerical field includes at least one of the following: net carbon removal candidate value, verifiable dry biochar quantity, qualified biochar dry mass candidate value, unitized verification result candidate quantity, carbon removal credit candidate quantity, or related numerical field; in some embodiments, the data processing system can also generate status records, which may include records that update the data share identifier or corresponding data field to a status such as eligible for inclusion, excluded, temporarily suspended, pending supplementary certification, included after adjustment, locked to prevent repeated inclusion, or refused to write; accounting mutual exclusion locking can be used to restrict the data share identifier or data object corresponding to the same physical biochar production share from being repeatedly written, repeatedly referenced, or repeatedly included in the carbon removal accounting-related dataset.

[0081] Through the above S1 to S5, the data processing system can convert source-side data generated by continuous or quasi-continuous biochar production processes into a verification data processing granularity that matches discrete life cycle stage data, and perform verification qualification status determination, write control, numerical deduction or accounting mutual exclusion locking processing at this granularity; in some embodiments, status records or audit traceability data can also be generated.

[0082] Example 2: Source-side verification evidence object acquisition or generation example This embodiment can be combined with Figure 1 Understood. This embodiment illustrates the method of acquiring or generating source-side verifiable evidence objects. The data processing system can acquire source-side verifiable evidence objects through a communication interface or communication network, or it can receive relevant source-side data and generate source-side verifiable evidence objects based on the relevant source-side data.

[0083] In one implementation, at least one of the following—a source-side computing node, an industrial control cabinet, a programmable logic controller, a distributed control system, an industrial personal computer, an edge computing gateway, a sensor data acquisition module, or a production equipment control system—collects or generates source-side related data near the continuous or quasi-continuous biochar production equipment, and sends the source-side verification evidence object, object summary, source-side evidence object index, source-side data reference address, audit drill-down index, or necessary fields to the data processing system.

[0084] The source-side verification evidence object may include at least one of the following: source-side output unit candidate identifier, source-side output unit identification information, discharge reference time information, feed time interval, actual reaction participation time interval, raw material source information, process operation parameter time sequence segment, process status attribution data, output physical quantity record, propagation path segment model parameter status, time synchronization status, measurement equipment calibration status, consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, audit drill-down index, non-conformity record, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio or exclusion share.

[0085] In one implementation, the data processing system acquires the complete source-side verification evidence object and uses it as the basic input for subsequent data share identifier generation or update, lifecycle chain mapping, verification eligibility status determination, and verification data processing. In some implementations, the object can also serve as the basic input for audit traceability processing. In another implementation, the data processing system only receives the index, hash digest, source-side data reference address, and necessary fields of the source-side verification evidence object, while the original source-side data remains in the source-side computing node, industrial control cabinet, edge computing gateway, or evidence storage module. When an external verification platform, registration agency system, audit terminal, or purchaser verification system requires verification, the data processing system can request the original data fragment or verification data corresponding to the source-side data reference address or audit drill-down index.

[0086] In another embodiment, the data processing system receives source-side relevant data and generates source-side verification evidence objects based on the source-side relevant data. The source-side relevant data may include at least one of the following: source-side output unit candidate identifier, discharge reference time information, feeding time interval, actual reaction participation time interval, weighing record, packaging record, process operation parameter time sequence segment, process status attribution data or its index, non-conformity record, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio, exclusion share, time synchronization status, measuring equipment calibration status, object hash digest, source-side data reference address, trusted timestamp, or source-side evidence object index.

[0087] When the data processing system generates source-side verification evidence objects, it can perform field integrity checks on the received source-side related data; determine output benchmark information based on discharge benchmark time information, feeding time interval, actual reaction participation time interval, or weighing records; generate source-side output unit identification information based on source-side output unit candidate identifiers, output benchmark information, or packaging records; associate process status attribution data, non-conformity records, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio, or exclusion share with the source-side output unit identification information; and generate consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, or audit drill-down index associated with the above fields.

[0088] The data processing system can perform integrity checks on acquired or generated source-side verification evidence objects. Integrity checks can include verification object hashes, model parameter status hashes, process status attribution data hashes, time synchronization status summaries, measurement equipment calibration status summaries, or trusted timestamps. If the integrity check fails, the data processing system can generate a data consistency check failure status and associate this status as input data for verification judgment or an abnormal status with the corresponding data share identifier.

[0089] Example 3: Data Share Identifier Generation or Update Example This embodiment can be combined with Figure 2 Understood. This embodiment illustrates the method for generating or updating data share identifiers. After the data processing system acquires or generates source-side verification evidence objects, it can generate or update data share identifiers based on the source-side verification evidence objects, source-side output unit identifier information or output benchmark information in the source-side verification evidence objects, or lifecycle stage data associated with the source-side verification evidence objects.

[0090] Data share identifiers may include at least one of the following: raw material share identifier, source-side output unit identifier, batch identifier, packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, end-use or storage path identifier, verification calculation input identifier, carbon removal credit candidate share identifier, credit issuance related data status identifier, credit statement related data status identifier, credit retirement or cancellation related data status identifier, lock status identifier, audit traceability identifier, or registration agency interface record identifier.

[0091] In one implementation, the data processing system generates a data share identifier based on source-side output unit identification information, output baseline information, output physical quantity records, object hash digests, or generation timestamps. This data share identifier can correspond to the total physical biochar output share of a source-side output unit, or it can correspond to a portion of the physical biochar output share of that source-side output unit.

[0092] In another implementation, the data processing system updates the data share identifier in subsequent lifecycle stages. For example, when a source-side verified evidence object corresponds to a two-hour metering cycle of continuous bulk discharge, and the biochar within that metering cycle is subsequently broken down into multiple packaging units, storage units, transportation units, or delivery units, the data processing system can generate or update multiple sub-data share identifiers based on the packaging unit identifier, storage unit identifier, transportation unit identifier, or delivery unit identifier, and maintain the association with the original data share identifier through the parent data share identifier.

[0093] In another implementation, when multiple packaging units corresponding to multiple source-side verification evidence objects are merged into the same delivery unit, end-application share, or verification declaration data unit, the data processing system can establish a many-to-one mapping relationship between multiple data share identifiers and data references at the same stage; when the physical biochar production share corresponding to a data share identifier is split into multiple credit candidate shares or multiple end-application shares, the data processing system can establish a one-to-many mapping relationship.

[0094] The generation or updating of data share identifiers can be achieved using database primary keys, hash digests, index encoding, field concatenation encoding, lifecycle stage data reference updates, or a combination thereof. The data share identifier generation or update table may include at least one of the following fields: data share identifier, source-side verification evidence object index, source-side output unit identifier information, output benchmark time information, output metering time interval, output physical quantity record, dry basis quality field, share ratio field, parent data share identifier, child data share identifier, lifecycle stage data reference, update source, object hash digest, generation timestamp, update time, registration agency interface record identifier, interface data packet identifier, or audit drill-down index.

[0095] Therefore, the data share identifier is not a simple identifier used to mark batches, but rather a data processing unit in the data processing system that represents at least a portion of the physical biochar production share as a data processing unit that can be individually subjected to lifecycle chain mapping, qualification status determination, write blocking, value deduction, status update, accounting mutual exclusion locking, interface data packet generation, or audit traceability processing.

[0096] Example 4: Data Share Identifier and Physical Biochar Production Share Mapping Example This embodiment can be combined with Figure 2 and Figure 7 Understand. This embodiment illustrates the mapping relationship between data share identifiers and physical biochar production shares, carbon removal credit candidate shares, and credit-related data records. The physical biochar production share may include at least one of the following: the entirety of a biochar production batch, a portion of a biochar production batch, a combination of multiple biochar production batches, the entirety of a biochar usage batch, a portion of a biochar usage batch, a packaging unit, a storage unit, a transportation unit, a delivery unit, an end-application share, or a sequestration path share.

[0097] The data share identifier can have a one-to-one, one-to-many, many-to-one, or many-to-many mapping relationship with the source-side verified evidence object, physical biochar production share, carbon removal credit candidate share, credit issuance related data record, credit statement related data record, credit transfer related data record, or credit retirement or cancellation related data record. The mapping relationship can include at least one of the following: parent-child relationship, split relationship, merge relationship, share ratio relationship, or stage data reference relationship between the parent data share identifier and the child data share identifier.

[0098] In one implementation, one source-side verified evidence object corresponds to one packaging unit, and the data processing system directly generates a data share identifier using either the packaging unit identifier or the source-side output unit identifier. This data share identifier corresponds to the total share of physical biochar produced within the packaging unit and is associated with the source-side verified evidence object index, output physical quantity records, and packaging records.

[0099] In another implementation, one source-side verified evidence object corresponds to multiple inventory units or transportation units. The data processing system can generate sub-data share identifiers for each inventory unit or transportation unit, and record the parent data share identifier, sub-data share identifier, share ratio field, and stage data reference. If the transportation route evidence for one of the transportation units is missing, the data processing system can simply mark the sub-data share identifier corresponding to that transportation unit as pending verification, temporarily suspended, excluded, or included after adjustment, without affecting other unaffected sub-data share identifiers under the same source-side verified evidence object.

[0100] In another implementation, multiple packaging units corresponding to multiple source-side verification evidence objects are merged into the same delivery unit, terminal application share, or verification declaration data unit. The data processing system can establish a many-to-one mapping relationship between multiple source-side verification evidence objects and a delivery unit data share identifier, and record the contribution ratio of each source-side verification evidence object to the delivery unit data share identifier.

[0101] In one implementation, the physical biochar production share corresponding to the data share identifier is calculated based on carbon removal, forming a carbon removal credit candidate data unit corresponding to the unitized verification result or carbon removal credit unit measurement granularity. The carbon removal credit candidate data unit may correspond to a candidate value range that is less than one, equal to one, or greater than one unitized verification result or carbon removal credit unit.

[0102] In one implementation, when the physical biochar production share corresponding to a data share identifier is less than one unitized verification result or carbon removal credit unit after carbon removal calculation, the data processing system can merge the data share identifier with other qualified data share identifiers to form a carbon removal credit candidate share; when the physical biochar production share corresponding to a data share identifier is greater than one unitized verification result or carbon removal credit unit after carbon removal calculation, the data processing system can split it into multiple carbon removal credit candidate shares and record the mapping relationship between each carbon removal credit candidate share and the original data share identifier.

[0103] Through the above mapping relationship, the data processing system can split, merge or update the granularity of data processing according to the needs of packaging, inventory, transportation, delivery, end application, certification declaration or credit candidate processing without changing the objective allocation of physical biochar production share. This improves the granularity adaptability between continuous source data and discrete lifecycle certification data.

[0104] Example 5: Lifecycle Chain Mapping Relationship Example This embodiment can be combined with Figure 3Understanding. This embodiment illustrates the chained mapping relationship between data share identifiers and multiple lifecycle stage nodes. The data processing system uses the data share identifier as an anchor point to establish a chained mapping relationship between the data share identifier and multiple lifecycle stage nodes, enabling the physical biochar production share represented by the source-side verification evidence object to maintain traceable data correlation between data from different lifecycle stages.

[0105] Lifecycle stage nodes may include at least two of the following stages: raw material acquisition stage, raw material transportation stage, production conversion stage, output measurement stage, output packaging stage, storage stage, transportation stage, delivery stage, end-use or sealing stage, sample testing stage, certification declaration stage, registration agency interface stage, buyer declaration verification stage, and data status stages related to carbon removal accounting, credit issuance, credit declaration, credit transfer, or credit retirement or cancellation.

[0106] The chained mapping relationship may include at least one of the following: stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, and verification information associated with data share identifier. Stage data reference may point to at least one of the following: raw material acquisition record, raw material transportation record, production conversion record, output measurement record, packaging record, inventory record, transportation record, delivery record, end-use or sealing record, sample testing record, certification declaration dataset, registration agency interface dataset, buyer's declaration verification dataset, credit issuance related dataset, credit statement related dataset, credit transfer related dataset, or credit retirement or cancellation related dataset.

[0107] In one implementation, the chain-like mapping relationship is represented by a directed graph. Data shares are identified as the master object node in the graph, and each lifecycle stage node is associated with this master object node through edges. Each edge can record the stage type, stage time, stage object identifier, evidence index, verification judgment input data, stage status data, stage eligibility status variables, abnormal status, interface return status, target verification rule processing result, or verification summary.

[0108] In another implementation, the chained mapping relationship is represented by a relational database table. The data processing system establishes a lifecycle status table for each data share identifier. Each row in the table corresponds to a lifecycle stage node, and the fields include at least one of the following: stage type, stage object identifier, input evidence index, output evidence index, verification judgment input data, stage status data, stage eligibility status variable, abnormal status, target verification rule processing result, status transition rule identifier, rule engine output result, interface return status, locked status, write refusal status, interface data packet identifier, and update time.

[0109] In another implementation, the chained mapping relationship can be implemented through event streams, message topics, graph database edges, hash chains, or combinations thereof. When lifecycle stage nodes are split, merged, updated in status, returned via API, verified by a buyer's declaration, or updated in data share, the data processing system can update the corresponding upstream stage node identifier, downstream stage node identifier, stage data reference, API data packet identifier, or verification digest based on the data share identifier.

[0110] Through the aforementioned chain-like mapping relationship, the data processing system can maintain consistency between the physical biochar production share represented by the source-side verification evidence object and the data status related to subsequent packaging, storage, transportation, delivery, end-use or sealing, sample testing, verification application, registration agency interface, buyer declaration verification, credit issuance, credit statement, credit transfer, and credit retirement or cancellation. This provides a data foundation for determining the verification eligibility status, write blocking, numerical deduction, accounting mutual exclusion locking, and audit traceability.

[0111] Example 6: Stage Status Data and Verification Judgment Input Data Example This embodiment can be combined with Figure 4 Understand. This embodiment illustrates the methods for generating or retrieving stage status data, stage eligibility status variables, and verification judgment input data. The data processing system can generate, receive, read, or update stage status data corresponding to at least one lifecycle stage node based on a chained mapping relationship.

[0112] The stage status data may include stage eligibility status variables corresponding to at least one lifecycle stage node. These stage eligibility status variables are used to characterize at least one of the following for the corresponding lifecycle stage node: data integrity, path determinism, target verification rule satisfaction, anomaly impact, supplementary verification, interface return, locked, write rejection, or duplicate declaration risk.

[0113] The stage eligibility status variables may include at least one of the following: raw material eligibility status variables, production and transformation eligibility status variables, output measurement eligibility status variables, packaging eligibility status variables, storage eligibility status variables, transportation eligibility status variables, delivery eligibility status variables, end-use or sealing eligibility status variables, certification declaration eligibility status variables, credit issuance related status variables, credit statement related status variables, credit transfer related status variables, or credit retirement or cancellation related status variables.

[0114] In one implementation, the stage eligibility status variable is an enumerated status, such as qualified, abnormal, pending supplementary certification, pending review, excluded, included after adjustment, locked for non-repeatable inclusion, or rejected for writing. In another implementation, the stage eligibility status variable is a structured status object, including at least one of the following: data integrity score, path determinism score, target verification rule satisfaction flag, abnormal impact ratio, supplementary certification status, interface return status, duplicate declaration risk flag, last update time, and status source.

[0115] Stage eligibility status variables can be generated or updated by the data processing system based on source-side non-compliance records, feedback from external verification platforms, results from registration agency interfaces, input from audit terminals, feedback from buyer verification systems, data source upload records for each lifecycle stage, or calculation results from an automated rule engine. Stage eligibility status variables can also be generated by external systems and read by the data processing system via interface data, interface data packets, message queues, or file exchange.

[0116] The verification judgment input data may include at least one of the following: stage status data, abnormal status, interface return status, stage status query result, target verification rule processing result, status transition rule, or rule engine output result. The target verification rule processing result may be generated based on at least one of the following: stage status data, abnormal status, preset threshold, rule engine, deduction parameter lookup table, stage status query result, or status transition rule. The rule engine output result may include at least one of the following: verification qualification status candidate value, deduction parameter, exclusion ratio, pending certification flag, duplicate declaration risk flag, duplicate accounting risk flag, locked non-repeatable inclusion flag, or refuse to write flag.

[0117] In one implementation, the data processing system can read stage eligibility status variables from a chained mapping table, lifecycle status table, stage data reference table, lock status table, or external interface return table via stage status query, and use the read stage eligibility status variables as verification judgment input data. In another implementation, the data processing system can read stage status data, abnormal states, deduction parameter lookup table, and state transition rules via a rule engine, and output the target verification rule processing result or the rule engine output result.

[0118] By using the aforementioned stage status data and verification judgment input data, the data processing system can convert the data integrity, path certainty, anomaly impact status, interface return status, and duplicate declaration risk status of different lifecycle stages into the input data required for subsequent verification qualification status determination without relying on manual comparison of different lifecycle documents or ledger records.

[0119] Example 7: Determining Certification Qualification Status This embodiment can be combined with Figure 4 and Figure 5 Understanding. This embodiment illustrates how a data processing system determines the verification eligibility status of a data share identifier based on a chain mapping relationship and verification judgment input data. The verification eligibility status may include at least one of the following: eligible for inclusion, excluded, deferred inclusion, pending supplementary verification, included after adjustment, locked for non-repeatable inclusion, or refused to write.

[0120] In one implementation, the data processing system reads the stage status data of multiple lifecycle stage nodes associated with the target data share identifier based on a chain mapping relationship, and determines the verification eligibility status based on the stage status data, abnormal states, target verification rule processing results, state transition rules, or rule engine output results. For example, when the data integrity, path certainty, and target verification rule satisfaction of all necessary stage nodes meet preset conditions, and there is no valid locked state or duplicate declaration risk state, the data processing system can determine the verification eligibility status of the data share identifier as eligible for inclusion.

[0121] In another embodiment, when the verification judgment input data includes an abnormal state, the data processing system determines the affected data share identifier associated with the abnormal state based on a chain mapping relationship, and determines the verification eligibility status of the affected data share identifier. Further, the data processing system can determine the verification eligibility status of the affected data share identifier through at least one of the following methods: forward propagation, reverse association, bidirectional verification, stage status query, or rule engine processing.

[0122] For example, when an anomaly occurs in the upstream raw material acquisition stage, the data processing system can propagate forward along the chain mapping relationship to the production conversion stage, output measurement stage, packaging stage, storage stage, transportation stage, delivery stage, end-use or sealing stage, and verification and declaration stage, and identify the corresponding data share as excluded, temporarily suspended, or pending supplementary certification. As another example, when an anomaly occurs in the downstream end-use stage, the data processing system can reversely link to the corresponding delivery unit, transportation unit, inventory unit, packaging unit, source-side output unit identifier, or source-side verification evidence object, and identify the affected data share.

[0123] In one implementation, the data processing system can determine the certification eligibility status of a data share identifier using a certification eligibility status transition table. The certification eligibility status transition table may include at least one of the following fields: status transition rule identifier, input anomaly type, stage status data, stage status query result, interface return status, target certification rule processing result, supplementary certification status, exclusion ratio, deduction parameter, duplicate declaration risk flag, duplicate accounting risk flag, lock non-duplicate inclusion flag, refuse write flag, and output certification eligibility status or rule update time.

[0124] In one implementation, when the input anomaly type is insufficient evidence for terminal use and the supplementary certification status is not supplemented, the output certification eligibility status can be pending supplementary certification or postponed inclusion; when the anomaly impact ratio or exclusion ratio is 100%, the output certification eligibility status can be excluded; when the anomaly impact ratio or exclusion ratio is less than 100% and there are deduction parameters, the output certification eligibility status can be included after adjustment; when it is detected that the same data share identifier, the same physical biochar production share, or the data object corresponding to the same physical biochar production share already has a valid accounting mutual exclusion lock status, the output certification eligibility status can be locked and cannot be included repeatedly, or a write rejection status can be generated.

[0125] In one implementation, the certification eligibility status transition table can be read by a rule engine, and the stage status data, stage status query results, interface return status, abnormal status, target certification rule processing results, deduction parameter lookup table or status transition rules can be converted into at least one certification eligibility status among: eligible for inclusion, excluded, temporarily suspended, pending supplementary certification, included after adjustment, locked and cannot be included again, or refused to write.

[0126] In this way, the data processing system can uniformly convert status data, abnormal status, target verification rule processing results, and interface return status distributed at different lifecycle stages into verification qualification status around data share identifiers, thereby providing a direct basis for subsequent write blocking, value deduction, or accounting mutual exclusion locking; in some implementations, it can also provide a basis for generating status records or audit traceability data.

[0127] Example 8: Verification Data Processing Example This embodiment can be combined with Figure 5 and Figure 8 Understood. This embodiment illustrates how a data processing system performs certification data processing based on certification eligibility status. The certification data processing includes at least one of write blocking, numerical deduction, or accounting mutual exclusion locking. In some implementations, the data processing system may also generate corresponding status records or audit traceability data.

[0128] When the certification eligibility status includes exclusion, deferred inclusion, pending certification, locked non-repeatable inclusion, or write refusal, the data processing system can generate a write blocking flag. The write blocking flag can be a database field, interface rejection code, status table record, message queue event, API response field, locked table entry, or audit log entry. Data share identifiers that are blocked from being written to carbon removal accounting-related datasets can also be blocked from being written to at least one of the following datasets: carbon removal credit accounting input dataset, output report declaration dataset, registration agency declaration dataset, carbon removal credit candidate statement dataset, credit issuance-related dataset, credit statement-related dataset, credit transfer-related dataset, credit retirement or cancellation-related dataset, interface submission dataset, message queue published data, certification declaration package, or buyer declaration verification dataset.

[0129] When the certification eligibility status includes an exclusion status, the exclusion status can include a complete exclusion status or a partial exclusion status. When the exclusion status is a complete exclusion status, the data processing system can mark the corresponding data share as excluded and prevent it from being written into the carbon removal accounting related dataset. When the exclusion status is a partial exclusion status, the data processing system can generate excluded data shares and remaining eligible data shares, or update the corresponding numerical fields in the carbon removal credit accounting input dataset, qualified biochar dry mass candidate dataset, net carbon removal candidate dataset, or carbon removal credit candidate quantity field based on the excluded carbon quantity, exclusion ratio, or excluded data share.

[0130] In one implementation, the data processing system receives or reads nonconformity records. These nonconformity records may include at least one of the following: non-conforming raw material input window, abnormal operating condition time window, discharge impact time window, affected output unit candidate identifier, affected data share identifier, source-side evidence object index, abnormal status identifier, abnormal impact ratio, object hash digest, audit drill-down index, excluded carbon quantity, exclusion ratio, or exclusion share. Based on the nonconformity records, the data processing system can mark the corresponding data share identifier as excluded, temporarily suspended, pending supplementary certification, or included after adjustment, and associate the nonconformity record, excluded carbon quantity, exclusion ratio, or exclusion share with the corresponding audit traceability data.

[0131] When the certification eligibility status includes the adjusted inclusion status, the data processing system can perform numerical deductions on the net carbon removal candidate value field, the verifiable dry biochar quantity field, the qualified biochar dry mass candidate value field, the unitized certification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields. The numerical deduction can be performed based on deduction input fields, which include at least one of the following: path risk adjustment parameter field, data uncertainty parameter field, end-use path traceability parameter field, sample detection confidence parameter field, storage and transportation loss parameter field, storage durability parameter field, or anomaly impact ratio field.

[0132] The data processing system can determine deduction parameters, deduction levels, deduction ratios, or deduction rules based on the deduction input fields, and perform numerical deductions on the net carbon removal candidate value field, the verifiable dry biochar quantity field, the qualified biochar dry mass candidate value field, the unitized verification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields in at least one of the following methods: multiplicative deduction, segmented deduction, lookup table deduction, threshold deduction, or proportional deduction.

[0133] In one specific implementation, a certain abnormal operating condition time window only affects 15% of the physical biochar production share of the corresponding data share identifier. The data processing system can determine the certification eligibility status of the data share identifier as adjusted inclusion, and write the net carbon removal candidate value field, the verifiable dry biochar quantity field, the qualified biochar dry mass candidate value field, the unitized certification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields, multiplied by 0.85, into the corresponding candidate dataset. At the same time, the pre-deduction value, deduction ratio, post-deduction value, deduction basis, and field update record are written into the status record or audit traceability data.

[0134] Status updates may include updating the data share identifier or the data field corresponding to the data share identifier to a status such as eligible for inclusion, excluded, temporarily suspended, pending supplementary certification, included after adjustment, locked for non-repeatable inclusion, refused to write, or other certification eligibility status. In some implementations, the status update record may include at least one of the following: value before status update, value after status update, source of status update, time of status update, triggering abnormal status, target certification rule processing result, rule engine output result, status transition rule identifier, associated data share identifier, operator identifier, system process identifier, or interface call identifier.

[0135] When the certification eligibility status includes an "inclusion eligible" or "adjusted inclusion" status, the data processing system can further generate an accounting mutual exclusion lock status to restrict the data share identifier or data object corresponding to the same physical biochar production share from being repeatedly written, repeatedly referenced, or repeatedly included in the carbon removal accounting-related dataset. The specific generation of the accounting mutual exclusion lock status and the duplicate reference detection can be performed with reference to the subsequent accounting mutual exclusion lock status and duplicate reference detection embodiments.

[0136] Through the above-mentioned verification data processing, the data processing system can perform differentiated processing on different verification qualification statuses at the data share identification granularity, avoiding the expansion of local anomalies into batch exclusion, and reducing the risk of ineligible shares being incorrectly included, repeatedly written, or repeatedly declared.

[0137] Example 9: Non-conformity record and partial exclusion example This embodiment can be combined with Figure 5 and Figure 8 Understood. This embodiment illustrates how a data processing system receives or reads non-conformity records and determines, based on these records, the excluded data share, the remaining data share that can be included, or the corresponding certification eligibility status.

[0138] In one implementation, the data processing system receives or reads non-conformity records. These non-conformity records can be generated by source-side computing nodes, industrial control cabinets, edge computing gateways, external verification platforms, audit terminals, lifecycle stage data sources, or manual review terminals. Alternatively, they can be generated by the data processing system based on relevant source-side data, stage status data, interface return status, or rule engine output results.

[0139] The non-conformity record may include at least one of the following: non-conforming raw material input window, abnormal operating condition time window, discharge impact time window, affected output unit candidate identifier, affected data share identifier, source side evidence object index, abnormal status identifier, abnormal impact ratio, object hash digest, audit drill-down index, excluded carbon quantity, excluded ratio, or excluded share.

[0140] In one implementation, the non-conformity record includes an abnormal operating condition time window and a discharge impact time window. The data processing system can determine the data share identifier affected by the abnormal operating condition time window or the discharge impact time window based on the mapping relationship between the data share identifier and the source-side output unit identifier information, the discharge metering time interval, the packaging unit identifier, the transportation unit identifier, or the delivery unit identifier.

[0141] In another implementation, the nonconformity record includes a nonconforming raw material input window. The data processing system can associate this nonconforming raw material input window with one or more affected data share identifiers based on the feed time interval, actual reaction participation time interval, output baseline information, or process status attribution data in the source-side verification evidence object.

[0142] In another implementation, the non-conformity record includes a state of insufficient terminal application or sealed evidence. The data processing system can use a chain-like mapping relationship to reverse-link from the terminal application or sealed path identifier to the delivery unit identifier, transportation unit identifier, inventory unit identifier, packaging unit identifier, source-side output unit identifier information, or source-side verification evidence object index, and determine the affected data share identifier.

[0143] Based on the non-compliance records, the data processing system marks the corresponding data share as excluded, temporarily suspended, pending supplementary certification, or included after adjustment, and associates the non-compliance records, excluded carbon quantity, excluded ratio, or excluded share with the corresponding audit traceability data.

[0144] When the certification eligibility status includes an exclusion status, the exclusion status can include a complete exclusion status or a partial exclusion status. When the exclusion status is a complete exclusion status, the data processing system can mark the corresponding data share identifier as excluded as a whole and prevent it from being written into the carbon removal accounting related dataset. When the exclusion status is a partial exclusion status, the data processing system can generate excluded data shares and remaining data shares that can be included based on the excluded carbon amount, exclusion ratio, abnormal impact ratio, or exclusion share.

[0145] In one specific implementation, a source-side verification evidence object corresponds to a dry-based biochar production of 1000 kg. The data processing system determines that 200 kg of this production corresponds to an abnormal operating condition time window based on non-conformity records. The data processing system can split the data share identifier corresponding to this source-side verification evidence object into an excluded data share and a remaining eligible data share, where the excluded data share corresponds to 200 kg, and the remaining eligible data share corresponds to 800 kg. The excluded data share is marked as excluded, while the remaining eligible data share can continue to participate in subsequent verification eligibility status determination.

[0146] In another specific implementation, the data processing system determines the exclusion ratio to be 20% based on the proportion of anomalies. The data processing system may not generate independent physical packaging objects, but instead generate the excluded data share and the remaining data share that can be included at the data level, and record the exclusion ratio, exclusion basis, affected stage node, source side evidence object index and field update records in the audit traceability data.

[0147] Through the above processing, the data processing system can limit the impact of non-conformities to the affected data share identifier or excluded data share, avoiding the over-exclusion of unaffected physical biochar production shares simply because of project-level, batch-level, or document-level anomaly markings.

[0148] Example 10: Adjusted Inclusion and Numerical Subtraction Examples This embodiment can be combined with Figure 5 and Figure 8 Understood. This embodiment illustrates how a data processing system performs numerical deductions when the certification eligibility status includes the adjusted inclusion status, and records the deduction process in the status log or audit traceability data.

[0149] When the certification eligibility status includes an adjusted inclusion status, the adjusted inclusion status may include the inclusion status after numerical deductions have been performed on the net carbon removal candidate value field, the verifiable dry biochar quantity field, the qualified biochar dry mass candidate value field, the unitized certification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields.

[0150] The numerical deduction can be performed based on the deduction input fields. The deduction input fields may include at least one of the following: path risk adjustment parameter field, data uncertainty parameter field, terminal usage path traceability parameter field, sample detection confidence parameter field, storage and transportation loss parameter field, sealing durability parameter field, or anomaly impact ratio field.

[0151] The data processing system can determine deduction parameters, deduction levels, deduction ratios, or deduction rules based on the deduction input fields. The deduction rules can employ at least one of the following methods: multiplicative deduction, segmented deduction, lookup table deduction, threshold deduction, or proportional deduction. In one implementation, different deduction methods can correspond to different data field update rules: multiplicative deduction multiplies candidate numerical fields by one or more deduction coefficients; segmented deduction selects the corresponding deduction ratio based on the value range of the deduction input field; lookup table deduction reads the deduction level or deduction ratio from the deduction parameter lookup table; threshold deduction triggers fixed deduction or status updates when the deduction input field reaches a preset threshold; and proportional deduction updates the corresponding numerical field based on the abnormal impact ratio, exclusion ratio, or exclusion share.

[0152] In one implementation, the data processing system reads a deduction parameter lookup table. The deduction parameter lookup table may include at least one of the following fields: deduction rule identifier, deduction input field name, deduction input field value range, deduction ratio, deduction level, applicable stage node, rule version number, rule source, update time, or audit index.

[0153] In one specific implementation, the terminal uses a path tracking accuracy parameter field of 0.90, a sample detection confidence parameter field of 0.95, and a corresponding deduction ratio of 0.03 for the storage and transportation loss parameter field. The data processing system can multiply the net carbon removal candidate value field by 0.90 and 0.95 based on the multiplication deduction rule, and then deduct the corresponding value of storage and transportation loss to obtain the deducted net carbon removal candidate value field.

[0154] In another specific implementation, the anomaly impact ratio field is 15%. The data processing system can perform a 15% numerical deduction on the verifiable dry biochar quantity field, the qualified dry biochar quality candidate value field, the unitized verification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields based on the proportional deduction rule, and write the deducted values ​​into the corresponding candidate dataset.

[0155] In another specific implementation, the storage durability parameter field is below a preset threshold but still meets the adjusted inclusion criteria. The data processing system can determine the deduction level based on the deduction parameter lookup table and perform segmented deductions on the net carbon removal candidate value field, instead of marking the corresponding data share identifier as excluded as a whole.

[0156] The data processing system can write at least one of the following into status records or audit traceability data: the value before deduction, the deduction input field, the deduction parameters, the deduction rules, the deduction ratio, the value after deduction, the field update record, the rule version number, or the audit drill-down index.

[0157] Through the above processing, the data processing system can make numerical adjustments to the physical biochar production share affected by some risks or anomalies at the data share identification granularity, instead of completely excluding it at the project level or batch level, thereby improving the precision and verifiability of the verification data processing.

[0158] Example 11: Example of calculating mutual exclusion locking state This embodiment can be combined with Figure 6 Understanding. This embodiment illustrates the generation, structure, and function of the accounting mutual exclusion lock state. The data processing system can generate the accounting mutual exclusion lock state based on the certification eligibility status before the data share identifier is written, referenced, or incorporated into the carbon removal accounting-related dataset.

[0159] The accounting mutual exclusion lock status may include at least one of the following: lock identifier, lock object, lock scope, lock source, lock time, lock duration, lock release condition, lock status hash digest, lock write record, lock audit index, previous lock record hash, current lock record hash, trusted timestamp, or registration agency interface record identifier.

[0160] The locked objects may include at least one of the following: data share identifier, physical biochar production share, carbon removal credit candidate share, carbon removal accounting related data record, credit issuance related data record, credit statement related data record, credit transfer related data record, or credit retirement or cancellation related data record.

[0161] The scope of the lock-in may include at least one of the following: carbon removal accounting input, output report declaration, registration agency declaration, carbon removal credit candidate declaration, credit issuance related data processing, credit declaration related data processing, credit transfer related data processing, or credit retirement or cancellation related data processing.

[0162] In one implementation, the data processing system receives a write request for a data share identifier. The data processing system queries whether there is a valid lock record for the data share identifier, the corresponding physical biochar production share, or the data object corresponding to the physical biochar production share. When there is no valid lock record and the certification eligibility status meets the preset inclusion criteria, the data processing system generates an accounting mutual exclusion lock status and allows the data share identifier to be written to the corresponding carbon removal accounting-related dataset.

[0163] In one implementation, the accounting mutual exclusion lock status can be written to a lock status table. The lock status table may include at least one field from the following: lock identifier, data share identifier, locked object, lock scope, lock source, lock time, lock duration, lock release condition, lock status hash digest, previous lock record hash, current lock record hash, trusted timestamp, write request result, write rejection reason, registry interface record identifier, external verification platform communication record identifier, purchaser verification system related record or purchaser declaration verification record identifier, or audit drill-down index.

[0164] In another implementation, the accounting mutual exclusion lock state can be written to at least one of the following: hash chain, append-only log, immutable storage unit, trusted timestamp storage unit, registry interface data table, external verification platform communication records, or buyer verification system related records or buyer declaration verification records.

[0165] In one specific implementation, the data processing system generates an accounting mutual exclusion lock state for a certain data share identifier. The lock object of this lock state is the data share identifier and its corresponding physical biochar production share, the lock scope includes carbon removal credit candidate declarations and registration agency applications, the lock source is the registration agency interface submission request, the lock time is the interface submission time, and the lock state hash digest is generated based on the data share identifier, the lock object, the lock scope, the lock source, the lock time, and the hash of the previous lock record.

[0166] By calculating the mutual exclusion lock state, the data processing system can implement mutual exclusion control on the same physical biochar production share at the data level, so that the data share identifier or data object corresponding to the same physical biochar production share cannot be repeatedly written, repeatedly referenced, or repeatedly included in the carbon removal accounting related dataset.

[0167] Example 12: Example of detecting risks of duplicate references and duplicate declarations This embodiment can be combined with Figure 6 Understand. This embodiment illustrates how a data processing system detects the risk of duplicate references, duplicate calculations, or duplicate declarations based on the mutual exclusion locking state of the accounting process.

[0168] In one implementation, the data processing system receives write, reference, inclusion, or declaration requests for another carbon removal credit accounting input dataset, output report declaration dataset, registry declaration dataset, carbon removal credit candidate declaration dataset, credit issuance related dataset, credit declaration related dataset, credit transfer related dataset, or credit retirement or cancellation related dataset. Based on the data share identifier, physical and biochar output share identifier, carbon removal credit candidate share identifier, source-side evidence object index, or stage data reference in the request, the data processing system queries the lock status table, hash chain, append-only log, registry interface data table, external verification platform communication records, or buyer verification system related records or buyer declaration verification records.

[0169] When the system detects that the request references a data share identifier that is already in a mutually exclusive locking state, the data processing system generates a duplicate declaration risk state, a duplicate accounting risk state, a locked non-repeatable inclusion state, or a write rejection state.

[0170] When the request does not directly reference the locked data share identifier, but the referenced data object corresponds to the same physical biochar production share as the locked data share identifier, the data processing system still generates a duplicate declaration risk status, a duplicate accounting risk status, a locked non-repeatable inclusion status, or a write rejection status.

[0171] In one specific implementation, the first dataset uses the packaging unit identifier as the data share identifier to include a certain physical biochar production share in the carbon removal credit candidate claim and generates an accounting mutual exclusion lock state. Subsequently, the second dataset uses the delivery unit identifier as the candidate share identifier to request the same physical biochar production share to be included again in the credit claim related dataset. Although the second dataset uses a different surface identifier, the data processing system determines through a chain mapping relationship that the delivery unit identifier corresponds to the same physical biochar production share as the locked packaging unit identifier, thus generating a duplicate claim risk state or a write rejection state.

[0172] In another specific implementation, the credit candidate share identifier referenced in the registration agency interface dataset differs from the internal reporting data object in the enterprise carbon asset management platform. The data processing system can perform identity determination based on the source-side evidence object index, physical biochar production share, stage data reference, or audit drill-down index. When both correspond to the same physical biochar production share and one of them is already in a mutually exclusive accounting lock state, the data processing system can mark subsequent requests as locked and not allowed to be included repeatedly.

[0173] In one implementation, duplicate reference detection results can be written to a lock status table, audit traceability table, interface data packets, message queue events, or external verification platform communication records. The duplicate reference detection results may include a trigger request identifier, a dataset identifier to be written, a locked data share identifier, the basis for determining the share of the same physical biochar production, a duplicate declaration risk status, a duplicate accounting risk status, a reason for refusal to write, and an audit drill-down index.

[0174] Through the above processing, the data processing system can reduce the risk of duplicate accounting, duplicate declarations, or duplicate inclusions caused by changing identifiers, splitting data objects, repeatedly referencing across datasets, or repeatedly submitting to different external systems.

[0175] Example 13: Audit Output Data and Audit Traceability Path Example This embodiment can be combined with Figure 7 Understanding. This example illustrates how a data processing system generates audit output data and audit traceability paths.

[0176] In one implementation, the data processing system generates audit output data based on data share identifiers, source-side verification evidence objects, chain mapping relationships, verification judgment input data, verification qualification status, verification data processing results, or accounting mutual exclusion lock status.

[0177] Audit output data may include at least one of the following: data share identifier, source-side verification evidence object index, source-side output unit identifier information, output physical quantity record, chain mapping relationship, lifecycle stage node status, verification judgment input data, stage status data, stage qualification status variable, abnormal status propagation record, verification qualification status, write blocking flag, accounting mutual exclusion lock status, deduction calculation record, exclusion record, record to be supplemented, reason for write refusal, lock status hash digest, audit drill-down index, or consistency verification information.

[0178] In one implementation, the data processing system generates an audit traceability path based on data share identifiers, from the source-side verified evidence object to the terminal application or archive path, the verified declaration dataset, the credit issuance related dataset, the credit statement related dataset, the credit transfer related dataset, or the credit retirement or cancellation related dataset.

[0179] An audit traceability path can include multiple traceability nodes. Each traceability node can correspond to a lifecycle stage node, a stage data reference, a stage status data, an anomaly propagation record, a verification eligibility status, a write blocking record, a value deduction record, a field update record, or an accounting mutual exclusion lock status.

[0180] In one specific implementation, auditors start from the data status related to a credit statement and trace back along the audit trail to locate the corresponding carbon removal credit candidate share, data share identifier, delivery unit identifier, transportation unit identifier, packaging unit identifier, source-side output unit identifier information, and source-side verification evidence object index. Auditors can also use the audit drill-down index to read source-side output physical quantity records, process status attribution data, non-conformity records, and object hash digests.

[0181] In another specific implementation, the external verification platform reviews the adjusted inclusion status of a data share identifier based on audit output data. The audit output data includes the value before deduction, deduction input fields, deduction parameters, deduction rules, the value after deduction, field update records, and rule version numbers. The external verification platform can reconstruct the value deduction process based on the above data.

[0182] In another specific implementation, the registration agency system reviews whether a certain credit candidate share has the risk of being included repeatedly based on audit output data. The audit output data includes the accounting mutual exclusion lock status, the lock status hash digest, the locked data share identifier, the dataset identifier to be written, the reason for refusing to write, and the basis for determining the share of the same physical biochar production.

[0183] Through the aforementioned audit output data and audit traceability paths, the data processing system enables the source-side verification evidence objects, lifecycle stage data, abnormal states, verification qualification status, verification data processing results, and lock status to form a verifiable data chain around the same data share identifier.

[0184] Example 14: Interface Data Packet and External Open Query Example This embodiment can be combined with Figure 1 and Figure 7 Understand. This embodiment illustrates how a data processing system outputs, sends, distributes, or opens queries to external systems for audit output data, audit traceability paths, or interface data packets.

[0185] In one implementation, the data processing system generates an interface data packet. The interface data packet may include at least one of the following: data share identifier, verification eligibility status, write blocking flag, accounting mutual exclusion lock status, write refusal reason, deduction calculation record, lock status hash digest, audit drill-down index, or source-side verification evidence object index.

[0186] Interface data packets can be output, sent, distributed, queried, or written to at least one of the following: external verification platforms, registration agency systems, audit terminals, buyer verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources.

[0187] In one implementation, the data processing system responds to the interface request from the registration authority system, outputting the verification eligibility status, accounting mutual exclusion lock status, lock status hash digest, credit candidate share identifier, and audit drill-down index corresponding to the target data share identifier. The registration authority system can then determine whether the data share identifier is allowed to be included in the registration authority's application dataset based on the aforementioned interface data packet.

[0188] In another implementation, the data processing system responds to the open query request from the buyer's verification system and outputs the audit traceability path corresponding to the data status related to the credit statement. The buyer's verification system can then use this audit traceability path to reverse-locate the source-side verification evidence object, lifecycle stage data, terminal application or archived path records, verification eligibility status, write blocking records, numerical deduction records, or accounting mutual exclusion lock status.

[0189] In another implementation, the data processing system sends an interface data packet to the enterprise carbon asset management platform. The enterprise carbon asset management platform can then update its internal carbon asset status fields based on the interface data packet, such as whether the asset is eligible for declaration, awaiting certification, locked, refused to be written, included after adjustment, or retired.

[0190] In one implementation, the interface data packet may include a machine-readable format such as JSON, XML, CSV, structured database records, message queue events, API response objects, hash digest packets, or verifiable credential objects. The interface data packet may include digital signatures, object hash digests, trusted timestamps, or audit drill-down indexes to enable external systems to verify data integrity.

[0191] In some implementations, through interface data packets and open query mechanisms, the data processing system can convert internal certification eligibility status, write control results, lock status, and audit traceability paths into data outputs that can be read, verified, and reconstructed by external systems, thereby improving the consistency of external certification, registration agency declarations, purchaser verification, and corporate carbon asset management.

[0192] Example 15: Abnormal State Types and Detection Examples This embodiment can be combined with Figure 4 and Figure 8 Understanding. This embodiment is used to illustrate the types of abnormal states and the methods by which the data processing system detects abnormal states.

[0193] The abnormal state may include at least one of the following: stage non-compliance state, evidence missing state, data conflict state, path uncertainty state, duplicate declaration risk state, target verification rule non-compliance state, equipment calibration failure state, time synchronization abnormal state, data consistency verification failure state, or insufficient terminal use evidence state.

[0194] The non-compliance status at the stage may include at least one of the following: non-compliance with raw material source qualifications, excessive raw material moisture content, excessive ash content, excessive pollutants, abnormal mixing ratio, missing raw material testing records, unstable production and conversion conditions, abnormal output measurement data, abnormal storage loss, missing evidence of transportation route, missing delivery confirmation, and non-compliance of end-use or storage status with preset verification rules.

[0195] In one implementation, unstable production conversion conditions may include at least one of the following not meeting the preset verification qualification conditions: temperature, pressure, oxygen content, gas flow rate, residence time, power, torque, speed, equipment alarm status, control mode, or pyrolysis stability index.

[0196] In one implementation, a terminal application or archiving status that does not comply with preset verification rules may include at least one of the following: missing geographical location, missing receipt confirmation, inconsistent application amount, archiving path that does not meet requirements, low traceability distribution, insufficient evidence of terminal use, usage category that does not meet preset conditions, or missing evidence of terminal retention.

[0197] The data processing system can detect abnormal states by reading stage status data, interface return status, consistency verification results, rule engine output results, feedback from external verification platforms, registration agency interface results, buyer verification system feedback, or audit terminal input.

[0198] In one specific implementation, when the data reference during the transportation phase lacks trajectory records, carrier records, or delivery confirmation records, the data processing system can generate a transportation path evidence missing status and associate it with the corresponding data share identifier as input data for verification judgment.

[0199] In another specific implementation, when a terminal application or archived path record lacks geographical location, receipt confirmation, or proof of purpose, the data processing system can generate a state of insufficient evidence of terminal purpose and determine the affected data share identifier based on the chain mapping relationship.

[0200] Example 16: Implementation of Abnormal State Propagation, Reverse Association, Bidirectional Verification, Stage State Query, and Rule Engine Processing This embodiment can be combined with Figure 4 Understanding. This embodiment illustrates how a data processing system handles abnormal states based on a chain-like mapping relationship, and determines the affected data share identifier, the affected physical biochar production share, the excluded data share, the remaining data share that can be included, or the adjusted data share that should be included.

[0201] In one implementation, the data processing system propagates the abnormal state of at least one lifecycle stage node to the corresponding data share identifier based on a chain mapping relationship. The abnormal state can propagate forward along the chain mapping relationship to subsequent lifecycle stage nodes, or it can be linked backward along the chain mapping relationship to the corresponding source-side verification evidence object, source-side output unit identifier, batch identifier, packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, terminal application, or sealing path identifier.

[0202] In one specific implementation, the abnormal state occurs during the raw material acquisition stage. The data processing system, based on a chain-like mapping relationship, propagates this abnormal state to the production conversion stage, output measurement stage, packaging stage, transportation stage, delivery stage, end-use or storage stage, and certification and declaration stage, and identifies the affected data share.

[0203] In another specific implementation, the abnormal state occurs during the terminal application or sealing stage. The data processing system can reverse-associate the terminal application or sealing path identifier with the delivery unit identifier, transportation unit identifier, inventory unit identifier, packaging unit identifier, source-side output unit identifier, and source-side verification evidence object, thereby determining the affected data share identifier and the corresponding source-side evidence object index.

[0204] In another implementation, the data processing system performs bidirectional verification. The system can propagate evidence from the source-side verification object to downstream lifecycle stage nodes, and reverse-link it from the terminal application or archive path, credit candidate share, or credit statement status back to the source-side verification object. When the forward propagation path and the reverse linkage path are inconsistent, the data processing system can generate a path uncertainty state or a data conflict state.

[0205] In another implementation, the data processing system does not explicitly perform abnormal state propagation, but instead determines the affected data share identifier based on stage status queries. For example, the data processing system can query all records in the chained mapping table where the stage status data is abnormal, the interface return status is failure, or the stage qualification status variable is pending certification, and determine the corresponding data share identifier as the affected data share identifier.

[0206] In another implementation, the data processing system handles abnormal states through a rules engine. The rules engine reads stage status data, abnormal states, target verification rule processing results, status transition rules, deduction parameter lookup tables or interface return status, and outputs the affected data share identifier, verification eligibility status, exclusion ratio, deduction parameters, pending verification flag or write rejection flag.

[0207] The abnormal state propagation, reverse association, bidirectional verification, stage state query, or rule engine processing can be performed based on at least one of the stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, or verification information in the chain mapping relationship.

[0208] Through the above processing, the data processing system can locate the abnormal states that occur at different life cycle stages to specific data share identifiers and their corresponding physical biochar production shares, rather than just marking the entire project, the entire batch, or the entire source-side verification evidence object with coarse-grained anomalies.

[0209] Example 17: Handling of Substandard Raw Materials This embodiment illustrates the specific application of a data processing system in handling the non-conforming state of raw materials. This embodiment can be implemented in conjunction with Embodiments 9, 15, and 16.

[0210] In one implementation, the raw material stage data source sends raw material source records, raw material testing records, moisture content records, ash content records, contaminant testing records, or blending ratio records to the data processing system. The data processing system generates raw material eligibility status variables based on these records.

[0211] When the raw material source is not qualified, the raw material moisture content exceeds the limit, the ash content exceeds the limit, the pollutant exceeds the limit, the mixing ratio is abnormal, or the raw material testing record is missing, the data processing system generates a raw material unqualified status and associates this status as an abnormal status with the corresponding raw material input window.

[0212] The data processing system determines the affected data share based on the raw material input window, feed time interval, actual reaction participation time interval, source-side output unit identification information, and output baseline information. If the substandard raw material only affects a portion of the physical biochar output share, the data processing system can generate excluded data shares and remaining data shares that can be included.

[0213] In one specific implementation, a batch of raw materials enters the continuous biomass carbonization production equipment between 10:00 and 10:30. The data processing system determines, based on the source-side verification evidence, the impact of this raw material input window on the output share between 11:00 and 12:00. The data processing system further determines three sub-data share identifiers corresponding to this output share based on packaging and inventory records, marking two of these sub-data share identifiers as excluded, while keeping the remaining unaffected sub-data share identifier in a state of inclusion or pending further determination.

[0214] Through the above processing, the data processing system can limit the non-conforming status of raw materials to the affected data share identifier, rather than excluding all source-side verification evidence objects for the entire production day, the entire project, or the entire batch.

[0215] Example 18: Example of Handling Abnormalities in Production Conversion Processes This embodiment illustrates the specific application method of a data processing system in handling abnormal production conversion conditions. This embodiment can be implemented in conjunction with Embodiments 9, 10, 15, and 16.

[0216] The data processing system can receive time-series segments of process operating parameters such as temperature, pressure, oxygen content, gas flow rate, residence time, power, torque, speed, equipment alarm status, control mode, or pyrolysis stability indicators. Based on these time-series segments, the system can generate production conversion qualification status variables.

[0217] When the timing segment of the process operation parameters does not meet the preset verification qualification conditions, the data processing system generates an unstable state of production conversion and determines the abnormal operating condition time window.

[0218] The data processing system determines the affected data share identifier based on the mapping relationship between the abnormal operating condition time window, the material discharge impact time window, the source-side output unit identification information, the output benchmark information, the material discharge metering time interval, and the data share identifier.

[0219] In one implementation, the abnormal operating condition time window only affects a portion of a discharge metering time interval. The data processing system can determine the exclusion ratio based on the proportion of the abnormal impact, or generate the excluded data share and the remaining data share that can be included.

[0220] In another implementation, the abnormal operating conditions do not meet the criteria for complete exclusion, but affect output stability or verification confidence. The data processing system can identify the corresponding data share as included in the adjusted state and perform numerical deduction based on the abnormal impact ratio field, the data uncertainty parameter field, or the sample detection confidence parameter field.

[0221] The data processing system can write the abnormal operating condition time window, the material discharge impact time window, the abnormal impact ratio, the deduction parameters, the value before deduction, the value after deduction, and the field update records into the audit traceability data.

[0222] Example 19: Storage, Transportation, and Delivery Status Processing Example This embodiment illustrates the specific application of a data processing system in handling storage, transportation, and delivery status.

[0223] The data processing system can receive storage records, inventory movement records, storage loss records, transportation route records, carrier records, loading records, unloading records, delivery confirmation records, or recipient confirmation records. These records can be used as lifecycle stage data and linked together with data share identifiers in a chain-like mapping relationship.

[0224] When there are abnormal storage losses, missing transportation route evidence, missing carrier records, missing delivery confirmations, or missing recipient confirmations, the data processing system can generate corresponding abnormal states and associate these abnormal states with the corresponding lifecycle stage nodes.

[0225] In one implementation, a transport unit corresponds to a portion of the physical biochar production share within a source-side verified evidence object. If transport route evidence for that transport unit is missing, the data processing system can simply mark the data share corresponding to that transport unit as pending verification or temporarily deferred, without affecting the data share identifiers of other transport routes that have been verified within the same source-side verified evidence object.

[0226] In another implementation, storage losses exceed a preset threshold but do not lead to complete exclusion. The data processing system can identify the corresponding data share as included after adjustment and perform numerical deductions on the net carbon removal candidate value field, the verifiable dry biochar quantity field, the unitized verification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields based on the storage and transportation loss parameter field.

[0227] In another implementation, the lack of delivery confirmation results in an incomplete chain of evidence for the end-user application. The data processing system can mark the corresponding data share as pending certification and prevent it from being written into the registry declaration dataset, carbon removal credit candidate declaration dataset, or buyer declaration verification dataset until the certification status is updated.

[0228] Example 20: Terminal Application or Encapsulation Path Processing Example This embodiment illustrates the specific application method of the data processing system for processing terminal applications or sealing path states.

[0229] The data processing system can receive terminal application records, sealing path records, application geographical location, receipt confirmation, application volume records, sealing category, proof of use, terminal retention evidence, or purchaser verification records. These records can be linked to delivery unit identifiers, transportation unit identifiers, packaging unit identifiers, data share identifiers, and source-side verification evidence objects in a chain-like mapping relationship.

[0230] When a terminal application or sealed path record lacks geographical location, receipt confirmation, application consistency proof, sealed path proof, usage category proof, or terminal retention evidence, the data processing system can generate a status indicating insufficient terminal usage evidence or a status indicating that the terminal application or sealed status does not conform to the preset verification rules.

[0231] The data processing system can use a chain-like mapping relationship to reverse-link the insufficient evidence status of end-use to the identification information of delivery unit, transportation unit, inventory unit, packaging unit, source-side output unit, and source-side verification evidence object, thereby determining the affected data share identifier.

[0232] In one implementation, the end application lacks sufficient evidence but is allowed to supplement it. The data processing system can determine the certification eligibility status of the corresponding data share identifier as pending supplementation or postponed inclusion, and generate a write blocking flag to prevent it from being written into the carbon removal credit candidate statement dataset, registry declaration dataset, or buyer declaration verification dataset.

[0233] In another implementation, if the terminal application path tracking score is lower than a preset threshold but does not trigger a complete exclusion, the data processing system can identify the corresponding data share as an adjusted inclusion state and perform numerical deduction based on the terminal application path tracking score parameter field or the archive durability parameter field.

[0234] Through the above processing, the data processing system can map the verification risks of terminal applications or sealed paths to specific data share identifiers and generate auditable status records, deduction calculation records, or records to be supplemented with verification.

[0235] Example 21: Example of Certification Declaration, Credit Issuance, Credit Statement, Credit Transfer, and Retirement or Cancellation Processing This embodiment illustrates how the data processing system is applied to data status related to certification applications, credit issuance, credit statements, credit transfers, and credit retirement or cancellation.

[0236] In one implementation, the data processing system establishes a mapping relationship between the physical biochar production share and the candidate values ​​of qualified biochar dry quality, net carbon removal candidate quantity, carbon removal credit candidate share, credit issuance related data records, credit statement related data status, credit transfer related data status, or credit retirement or cancellation related data status based on data share identifiers.

[0237] When the certification eligibility status of a data share identifier is either eligible for inclusion or adjusted for inclusion, the data processing system can write it into the carbon removal credit accounting input dataset or the certification declaration dataset and generate the corresponding accounting mutual exclusion lock status.

[0238] When an external verification platform or registration authority system returns the status of the relevant interface for issuance, the data processing system can write the status returned by the interface as stage status data into the chain mapping relationship and update the credit issuance-related data status corresponding to the data share identifier.

[0239] When a buyer's declaration system or a corporate carbon asset management platform requests to reference a certain credit candidate share or credit declaration related data status, the data processing system can determine whether the physical biochar production share has been used for other declarations, transfers, retirements, or cancellations based on the accounting mutual exclusion lock status.

[0240] When the status of credit transfer-related data changes, the data processing system can write the credit transfer record as a lifecycle stage node into the chain mapping relationship and associate it with the data share identifier, credit candidate share, and corresponding physical biochar production share.

[0241] When credit retirement or cancellation-related data status is written, the data processing system can generate a locked non-repeatable inclusion status or a final locked status based on the data share identifier or credit candidate share identifier, and prevent the physical biochar production share from being used again for credit issuance, credit declaration, credit transfer or other carbon removal accounting related datasets.

[0242] Through the above processing, the data processing system can establish a traceable relationship between the data status of certification declarations, credit issuance, credit statements, credit transfers, and credit retirement or cancellation and the source-side certification evidence objects and physical biochar production share, thereby reducing the risk of duplicate declarations, duplicate transfers, or duplicate retirements or cancellations.

[0243] Example 22: Locked State Storage Module Example This embodiment can be combined with Figure 6 Understand. This embodiment is used to illustrate the structure and function of the locked state storage module.

[0244] The locked state storage module may include at least one of the following: a locked state table, a hash chain storage unit, an append-only log storage unit, an immutable storage unit, a trusted timestamp unit, an audit drill-down index unit, a registry interface data table, an external verification platform communication unit, or a storage unit for records related to the buyer's verification system or records of the buyer's declaration verification.

[0245] The lock status storage module is used to store, index, output, or distribute to external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources at least one of the following: mutually exclusive lock status, lock status hash digest, write-rejected status, or registration agency interface record.

[0246] In one implementation, a lock status table stores currently valid lock records. A hash chain storage unit records lock status changes in chronological order. An append-only log storage unit records non-overwriteable lock write events. A trusted timestamp unit generates time-stamped proofs for lock write events. An audit drill-down index unit associates lock statuses with source-side verified evidence objects, chained mappings, and audit output data.

[0247] In one specific implementation, when generating a mutual exclusion lock state, the data processing system simultaneously writes the current lock record to the lock state table, writes the lock write event to the append-only log storage unit, writes the hash of the current lock record to the hash chain storage unit, and requests a trusted timestamp from the trusted timestamp unit. During subsequent auditing, the audit terminal can verify that the lock state has not been tampered with based on the lock state hash digest, the hash of the preceding lock record, and the trusted timestamp.

[0248] In another specific implementation, the registration agency system requests a query for the lock status of a certain data share identifier. The lock status storage module outputs the accounting mutual exclusion lock status, lock range, lock time, write refusal reason, and audit drill-down index of the data share identifier based on the registration agency interface data table.

[0249] Example 23: Data Processing Equipment and System Example This embodiment illustrates the structure of a carbon removal lifecycle verification data processing device and system based on data share identification.

[0250] In one embodiment, a carbon removal lifecycle verification data processing device based on data share identification includes a communication interface, a memory, and a processor connected to the communication interface and the memory.

[0251] The communication interface is used to acquire source-side verification evidence objects or to receive relevant source-side data, and to communicate with at least one of the following: source-side computing nodes, external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources.

[0252] The memory is used to store at least one of the following: computer program, source-side verification evidence object, source-side related data, source-side evidence object index, source-side data reference address, object hash digest, data share identifier, chain mapping relationship, verification judgment input data, stage status data, abnormal status, abnormal impact information, target verification rule processing result, status transition rule, rule engine output result, verification qualification status, write blocking flag, write refusal status, numerical deduction processing result, accounting mutual exclusion lock status, lock status hash digest, registration agency interface record, interface data packet, status record, audit drill-down index, or audit traceability data.

[0253] The processor is configured to perform the following operations: acquire source-side verification evidence objects, or acquire source-side related data and generate source-side verification evidence objects based on the source-side related data; generate or update data share identifiers based on the source-side verification evidence objects, source-side output unit identification information or output benchmark information in the source-side verification evidence objects, or lifecycle stage data associated with the source-side verification evidence objects; establish a chain mapping relationship using the data share identifiers as association anchors; determine the verification qualification status based on the chain mapping relationship and verification judgment input data; and execute at least one of write blocking, value deduction, or accounting mutual exclusion locking based on the verification qualification status, and generate status records or audit traceability data.

[0254] The processor can also be configured to output, send, distribute, or open-query at least one of the following through a communication interface: status record, audit traceability data, accounting mutual exclusion lock status, write refusal status, lock status hash digest, or interface data packet; to at least one of the following: external verification platform, registration agency system, audit terminal, buyer verification system, enterprise carbon asset management platform, or life cycle stage data source.

[0255] In one implementation, the carbon removal lifecycle verification data processing system based on data share identification includes an evidence acquisition and generation module, a data share management module, a lifecycle chain mapping module, a verification qualification determination module, a verification data processing module, an accounting mutual exclusion locking module, a lock status storage module, and an audit output module.

[0256] The evidence acquisition and generation module is used to acquire source-side verifiable evidence objects, or to receive relevant source-side data and generate source-side verifiable evidence objects based on the relevant source-side data. The data share management module is used to generate or update data share identifiers based on source-side verifiable evidence objects, source-side output unit identification information or output benchmark information within the source-side verifiable evidence objects, or lifecycle stage data associated with the source-side verifiable evidence objects. The lifecycle chain mapping module is used to establish a chain mapping relationship between data share identifiers and multiple lifecycle stage nodes.

[0257] The certification eligibility determination module is used to determine the certification eligibility status based on the chain mapping relationship and the certification judgment input data. In some embodiments, the abnormal status handling module or the abnormal status propagation module is set as an independent functional module or integrated into the certification eligibility determination module. It is used to determine the affected data share identifier associated with the abnormal status based on the chain mapping relationship, and supports at least one of abnormal status propagation, reverse association, bidirectional verification, stage status query, or rule engine processing. The certification data processing module is used to execute at least one of write blocking, numerical deduction, or accounting mutual exclusion locking based on the certification eligibility status. The accounting mutual exclusion locking module is used to generate an accounting mutual exclusion locking status, and when it detects that a data object repeatedly references the same data share identifier or the same physical biochar production share, it generates a duplicate declaration risk status, a duplicate accounting risk status, a locked non-repeatable inclusion status, or a write rejection status.

[0258] The lock status storage module is used to store, index, output, or distribute at least one of the following to external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources: mutually exclusive lock status, lock status hash digest, write-reject status, or registration agency interface record. The audit output module is used to generate audit output data, audit traceability paths, or interface data packets, and to output, send, distribute, enable querying, or write the audit output data, audit traceability paths, or interface data packets to at least one of the following: external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources.

[0259] Example 24: Example of a computer-readable storage medium This embodiment illustrates a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores a computer program, which, when executed by a processor, implements the carbon removal lifecycle verification data processing method based on data share identification as described in any embodiment of the present invention.

[0260] The non-transitory computer-readable storage medium may include read-only memory, random access memory, flash memory, solid-state drive, hard disk, optical disk, server storage, cloud platform object storage, edge computing device storage, industrial control device storage, or combinations thereof.

[0261] The computer program may include program instructions for performing the following operations: acquiring or generating source-side verification evidence objects; generating or updating data share identifiers; establishing a lifecycle chain mapping relationship; generating or reading verification judgment input data; determining verification eligibility status; executing write blocking, numerical deduction, or accounting mutual exclusion locking; generating accounting mutual exclusion locking status; performing duplicate declaration risk detection or duplicate accounting risk detection; in some embodiments, generating status records, audit output data, audit traceability paths, or interface data packets; and outputting, sending, distributing, or making relevant data available for query to external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources.

[0262] The computer program can be deployed on a cloud server, a local server, a registry interface server, an external verification platform, an enterprise carbon asset management platform, a buyer verification system, an audit platform, an edge collaboration server, a source-side computing node, or a combination thereof. The computer program can execute the data processing operations described in any embodiment of the present invention through at least one of batch processing, streaming processing, event-driven processing, message queue processing, API call processing, or database trigger processing.

[0263] Example 25: External Evidence Object Interface Compatibility and Stage State Write-back Example This embodiment illustrates the interface compatibility method for inputting external evidence objects as lifecycle stage data or stage status data into the dMRV data processing system and for updating the state variables corresponding to the data share identifier.

[0264] In some implementations, the carbon removal digital measurement, reporting, and verification data processing system is further configured to receive, read, or invoke external evidence objects, external self-certification objects, external status objects, or external verification feedback objects associated with the data share identifier, and use them as at least one of lifecycle stage data, verification judgment input data, deduction input information, stage status data, or stage eligibility status variables to update the verification eligibility status of the corresponding data share identifier, write blocking flags, numerical deduction results, accounting mutual exclusion lock status, or audit traceability data.

[0265] The external evidence objects, external self-certification objects, external status objects, or external verification feedback objects include at least one of the following: control cabinet root of trust object, raw material verification binding object, source-side verification evidence object, dynamic dry basis net weight self-certification object, sample chain evidence object, representative status object of test report, third-party inspection material verification object, end-use evidence object, sealing path evidence object, reversal risk status object, replacement risk status object, use deviation risk status object, external verification platform feedback object, audit supplementary verification object, or versioned supplementary verification snapshot.

[0266] In one specific implementation, the trusted root object of the control cabinet includes at least one of the following: material discharge time anchor point, batch identity data, hardware time calibration status, hardware signature data, verified path control status, trusted timestamp, batch unique identifier, or system path verification record. The dMRV data processing system associates the trusted root object of the control cabinet with the corresponding data share identifier, source-side production unit identifier, or lifecycle stage node, and updates at least one of the following based on the material discharge time anchor point, batch identity data, hardware signature data, or verified path control status: stage data trusted status, source-side stage qualification status variable, path allowed status, write allowed status, write blocked flag, or audit traceability data.

[0267] In one specific implementation, the raw material verification binding object includes at least one of the following: raw material batch identifier, raw material source status, raw material physical identification status, raw material qualified share, raw material risk share, raw material excluded share, furnace entry attribution information, processing terminal attribution information, contribution information, raw material evidence object identifier, raw material evidence object hash digest, or raw material binding corresponding information. The dMRV data processing system associates the raw material verification binding object with one or more data share identifiers, and based on the raw material qualified share, raw material risk share, raw material excluded share, furnace entry attribution information, or contribution information therein, updates at least one of the following: stage qualification status variable, verification qualification status, deduction input field, suspended inclusion status, exclusion status, adjusted inclusion status, or audit traceability data for the raw material source stage or furnace entry binding stage.

[0268] In one specific implementation, the source-side verification evidence object includes at least one of the following: source-side output unit identifier, output baseline information, discrete evidence boundary, process status attribution data, anomaly impact information, consistency verification information, source-side verification evidence object identifier, source-side verification evidence object hash digest, or source-side stage data reference. The dMRV data processing system associates the source-side verification evidence object with the corresponding data share identifier, and based on the output baseline information, discrete evidence boundary, process status attribution data, anomaly impact information, or consistency verification information therein, updates at least one of the following: stage qualification status variable, verification qualification status, write blocking flag, deduction input field, numerical deduction result, accounting mutual exclusion lock status, or audit traceability data for the continuous production stage, source-side output stage, or anomaly propagation stage.

[0269] In one specific implementation, the dynamic dry basis net weight self-certification object includes at least one of the following: source-side output unit identifier, data share identifier, weighing status data, moisture status data, equipment calibration status, dry basis quality candidate value, dry basis quality fusion estimate, dry basis quality confidence status, or dry basis quality calculation record. The dMRV data processing system associates the dynamic dry basis net weight self-certification object with the corresponding data share identifier, and updates at least one of the following fields based on the dry basis quality fusion estimate, dry basis quality confidence status, or dry basis quality consistency status: qualified biochar dry weight candidate value field, verifiable dry biochar quantity field, net carbon removal candidate value field, deduction input field, stage eligibility status variable, or audit traceability data.

[0270] In one specific implementation, the sample chain evidence object, the representative status object of the test report, or the third-party testing material verification object includes at least one of the following: sample identifier, sampling event identifier, sample chain record, laboratory receiving record, laboratory qualification status, testing method identifier, laboratory test report identifier, report hash summary, report signature, original instrument data index, structured testing parameters, test report coverage boundary, or test report representative status. The dMRV data processing system associates the representative status object of the test report with one or more data share identifiers, and updates at least one of the following variables based on the test report's valid status, representative status, qualified status of testing parameters, or test report coverage boundary: stage qualification status variable, verification qualification status, pending certification status, exclusion status, adjusted inclusion status, or audit traceability data.

[0271] In one specific implementation, the terminal use evidence object, sealing path evidence object, reversal risk status object, replacement risk status object, or use deviation risk status object includes at least one of the following: packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, terminal application or sealing path identifier, outbound weight, transportation path record, logistics node verification record, delivery confirmation record, terminal user entity identifier, terminal usage location, terminal use category, terminal use proof, final use proof, use deviation risk status, replacement risk status, reversal risk status, or terminal use eligibility status. The dMRV data processing system associates the terminal use evidence object or sealing path evidence object with the corresponding data share identifier, and updates at least one of the following in the terminal application or sealing stage based on the terminal use eligibility status, use deviation risk status, replacement risk status, or reversal risk status: stage eligibility status variable, verification eligibility status, write blocking flag, deduction of input fields, write refusal reason, accounting mutual exclusion lock status, audit traceability data, or audit traceability path.

[0272] In one specific implementation, the external verification platform feedback object, audit supplementary verification object, or versioned supplementary verification snapshot includes at least one of the following: field missing information, evidence gap information, data conflict information, supplementary verification request, audit comment, interface return status, supplementary verification data reference, supplementary verification data hash, supplementary verification version number, supplementary verification submission time, or status write-back record returned by the external verification platform. Based on the external verification platform feedback object, audit supplementary verification object, or versioned supplementary verification snapshot, the dMRV data processing system locates the affected data share identifier, source-side verification evidence object, lifecycle stage node, or stage data reference, and updates the corresponding pending supplementary verification status, supplementary verification completed status, temporarily suspended inclusion status, adjusted inclusion status, exclusion status, interface return status, or audit traceability data.

[0273] The external evidence objects, external self-certification objects, external status objects, or external verification feedback objects are input into the dMRV data processing system through at least one of the following interfaces: communication interface, message queue, database interface, file interface, application programming interface, external verification platform interface, audit terminal interface, enterprise carbon asset management platform interface, or lifecycle stage data source interface. The dMRV data processing system performs at least one of the following checks on the external evidence objects, external self-certification objects, external status objects, or external verification feedback objects: object identifier matching, data share identifier matching, stage node matching, hash digest verification, digital signature verification, timestamp verification, version number verification, permission verification, or field integrity verification, to determine whether they can be used to update the stage eligibility status variable of the corresponding data share identifier.

[0274] After completing the aforementioned status write-back, the dMRV data processing system generates a status write-back record. This record includes at least one of the following: data share identifier, external evidence object identifier, external self-certification object identifier, external status object identifier, external verification feedback object identifier, lifecycle stage node identifier, pre-update stage eligibility status variable, post-update stage eligibility status variable, update reason, update time, update source, update rule version, associated hash digest, trusted timestamp, or audit drill-down index. This status write-back record supports tracing and verifying the status changes of the same physical biochar production share across control cabinet trusted roots, raw material verification binding, source-side verification evidence, dynamic dry basis quality, sample testing, end-use, sealing path, audit supplementary verification, or external verification feedback stages.

[0275] In this embodiment, the external evidence object, external self-certification object, external status object, or external verification feedback object can be generated by external systems such as control systems, source-side computing nodes, raw material verification and binding systems, dynamic dry basis net weight self-certification systems, sample chain and test report processing systems, end-use or storage path evidence systems, audit data package processing systems, or enterprise carbon asset management platforms. This embodiment does not limit the specific generation method of the above-mentioned external objects, but is used to illustrate that the dMRV data processing system can perform interface reception, association verification, and stage status write-back of the above-mentioned external objects based on data share identifiers.

[0276] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, adjustments, replacements, or combinations can be made to the data fields, state variables, module deployment methods, chained mapping data structures, abnormal state types, gating rules, locked storage methods, audit output formats, registration agency interfaces, or external verification platform interfaces in the above embodiments without departing from the technical concept of the present invention. All equivalent substitutions, modifications, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing carbon removal lifecycle verification data based on data share identification, characterized in that, Performed by a digital carbon removal measurement, reporting, and verification data processing system, including: S1, Obtain or generate source-side verification evidence objects: The dMRV data processing system obtains source-side verification evidence objects, or obtains source-side related data and generates source-side verification evidence objects based on the source-side related data; the source-side verification evidence objects correspond to source-side output units or at least a portion of physical biochar output shares in continuous or quasi-continuous biochar production processes, and include at least one of the following: source-side output unit identification information, output benchmark information, output physical quantity records, process status attribution data, or consistency verification information; S2, Generate or update data share identifier: Based on the source-side verified evidence object, the source-side output unit identifier information or output benchmark information in the source-side verified evidence object, or the life cycle stage data associated with the source-side verified evidence object, generate or update data share identifier; the data share identifier corresponds to or is associated with at least a portion of the physical biochar output share represented by the source-side verified evidence object, and is used to convert the source-side data formed by the continuous or quasi-continuous biochar production process into a verified data processing granularity that can be associated, propagated, verified, deducted or locked between data at different life cycle stages; S3, Establish a chain mapping relationship: Using the data share identifier as the association anchor point, establish a chain mapping relationship between the data share identifier and multiple lifecycle stage nodes; wherein, the chain mapping relationship includes at least one of stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, or verification information associated with the data share identifier; S4, Determine the certification eligibility status: Based on the chained mapping relationship and the certification judgment input data of at least one lifecycle stage node, determine the certification eligibility status of the data share identifier; the certification judgment input data includes at least one of stage status data, abnormal status, target certification rule processing result, status transition rule, or rule engine output result; when the certification judgment input data includes an abnormal status, determine the affected data share identifier associated with the abnormal status based on the chained mapping relationship, and determine the certification eligibility status of the affected data share identifier; S5, Perform verification data processing: Based on the verification eligibility status, perform verification data processing on the data share identifier or the data field corresponding to the data share identifier. The verification data processing includes at least one of write blocking, numerical deduction, or accounting mutual exclusion locking. The write blocking is used to prevent the data share identifier from being written to the carbon removal accounting related dataset. The numerical deduction is used to update the verification result candidate value, the accounting value that can be included, the carbon removal related numerical field, or a combination thereof, corresponding to the data share identifier. The accounting mutual exclusion locking is used to restrict the data share identifier or data object corresponding to the same physical biochar production share from being repeatedly written, repeatedly referenced, or repeatedly included in the carbon removal accounting related dataset. The data share identifier, chain mapping relationship, and certification eligibility status are used together to convert source-side data generated in continuous or quasi-continuous biochar production processes into certification data processing granularity that matches the life cycle stage data.

2. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The source-side verification evidence objects include at least one of the following: source-side output unit candidate identifier, source-side output unit identification information, discharge reference time information, feed time interval, actual reaction participation time interval, raw material source information, process operation parameter time sequence segment, process status attribution data, output physical quantity record, propagation path segment model parameter status, time synchronization status, measurement equipment calibration status, consistency verification information, object hash digest, source-side evidence object index, source-side data reference address, audit drill-down index, non-conformity record, abnormal impact information, deduction input information, excluded carbon quantity, exclusion ratio or exclusion share; The source-side related data is acquired, generated, or transmitted by at least one of the following: source-side computing node, industrial control cabinet, programmable logic controller (PLC), distributed control system (DCS), industrial personal computer (IPC), edge computing gateway, sensor data acquisition module, or production equipment control system.

3. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The data share identifier includes at least one of the following: raw material share identifier, source-side output unit identifier, batch identifier, packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, end-application or storage path identifier, verification calculation input identifier, carbon removal credit candidate share identifier, credit issuance related data status identifier, credit statement related data status identifier, credit retirement or cancellation related data status identifier, lock status identifier, audit traceability identifier, or registration agency interface record identifier; The data share identifier serves as a verification data processing anchor point for the physical biochar production share across different lifecycle stages.

4. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The physical biochar production share includes at least one of the following: the entirety of a biochar production batch, a portion of a biochar production batch, a combination of multiple biochar production batches, the entirety of a biochar usage batch, a portion of a biochar usage batch, a packaging unit, a storage unit, a transportation unit, a delivery unit, an end-use share, or a storage route share. The data share identifier has a one-to-one, one-to-many, many-to-one, or many-to-many mapping relationship with the source-side verified evidence object, the physical biochar production share, the carbon removal credit candidate share, the credit issuance related data record, the credit statement related data record, or the credit retirement or cancellation related data record. The mapping relationship includes at least one of the following: parent-child relationship, splitting relationship, merging relationship, share ratio relationship, or stage data reference relationship between parent data share identifier and child data share identifier.

5. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The lifecycle stage nodes include at least two of the following stages: raw material acquisition stage, raw material transportation stage, production conversion stage, output measurement stage, output packaging stage, storage stage, transportation stage, delivery stage, end-use application or sealing stage, sample testing stage, certification declaration stage, registration agency interface stage, buyer declaration verification stage, and data status stage related to carbon removal accounting, credit issuance, credit declaration, credit transfer or credit retirement or cancellation.

6. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The stage status data includes stage eligibility status variables corresponding to at least one lifecycle stage node; the stage eligibility status variables are used to characterize at least one of the following lifecycle stage node: data integrity, path determinism, target verification rule satisfaction, anomaly impact, supplementary verification, interface return, lock status, write refusal status, or duplicate declaration risk status. The stage qualification status variables include at least one of the following: raw material qualification status variables, production and transformation qualification status variables, output measurement qualification status variables, packaging qualification status variables, storage qualification status variables, transportation qualification status variables, delivery qualification status variables, end-use or sealing qualification status variables, certification and declaration qualification status variables, credit issuance related status variables, credit statement related status variables, credit transfer related status variables, or credit retirement or cancellation related status variables. The abnormal state is determined based on the stage state data, the interface return state, or the consistency verification result, or the target verification rule processing result is generated based on at least one of the stage state data, the abnormal state, the preset threshold, the rule engine, the deduction parameter lookup table, the stage state query result, or the state transition rule.

7. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The accounting mutual exclusion lock includes generating an accounting mutual exclusion lock state; the accounting mutual exclusion lock state includes at least one of the following: lock identifier, lock object, lock scope, lock source, lock time, lock duration, lock release condition, lock state hash digest, lock write record, lock audit index, previous lock record hash, current lock record hash, trusted timestamp, or registration agency interface record identifier; The locked objects include at least one of the following: data share identifier, physical biochar production share, carbon removal credit candidate share, carbon removal accounting related data record, credit issuance related data record, credit statement related data record, credit transfer related data record, or credit retirement or cancellation related data record; The locked scope includes at least one of the following: carbon removal accounting input, output report declaration, registration agency declaration, carbon removal credit candidate declaration, credit issuance related data processing, credit declaration related data processing, credit transfer related data processing, or credit retirement or cancellation related data processing.

8. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: When it is detected that another carbon removal credit accounting input dataset, output report declaration dataset, registration agency declaration dataset, carbon removal credit candidate declaration dataset, credit issuance related dataset, credit declaration related dataset, credit transfer related dataset, or credit retirement or cancellation related dataset references a data share identifier that is already in a mutually exclusive accounting lock state, or references a data object that corresponds to the same physical biochar output share as a locked data share identifier, a duplicate declaration risk state, a duplicate accounting risk state, a locked non-repeatable inclusion state, or a write rejection state is generated; The accounting mutual exclusion lock state is written to at least one of the following: lock state table, hash chain, append-only log, immutable storage unit, trusted timestamp storage unit, audit drill-down index, registry interface data table, external verification platform communication records, or purchaser declaration verification records.

9. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The abnormal states include at least one of the following: stage non-compliance state, evidence missing state, data conflict state, path uncertainty state, duplicate declaration risk state, target verification rule non-compliance state, equipment calibration failure state, time synchronization abnormal state, data consistency verification failure state, or insufficient evidence of terminal use state. The non-compliance statuses at the stage include at least one of the following: non-compliance with raw material source qualifications, excessive raw material moisture content, excessive ash content, excessive pollutants, abnormal mixing ratio, missing raw material testing records, unstable production and conversion conditions, abnormal output measurement data, abnormal storage losses, missing evidence of transportation routes, missing delivery confirmation, and non-compliance of end-use or storage status with preset verification rules. The unstable production conversion conditions include at least one of the following: temperature, pressure, oxygen content, gas flow rate, residence time, power, torque, speed, equipment alarm status, control mode, or pyrolysis stability index failing to meet the preset verification qualification conditions; the terminal application or storage status failing to meet the preset verification rules includes at least one of the following: missing geographical location, missing receipt confirmation, inconsistent application amount, non-compliant storage path, low traceability distribution, insufficient evidence of terminal use, non-compliant use category, or missing evidence of terminal retention.

10. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: Based on the chain mapping relationship, the abnormal state of at least one lifecycle stage node is propagated to the corresponding data share identifier; or, the abnormal state is propagated forward along the chain mapping relationship to subsequent lifecycle stage nodes; or, the abnormal state is associated backward along the chain mapping relationship to the corresponding source-side verification evidence object, source-side output unit identifier, batch identifier, packaging unit identifier, inventory unit identifier, transportation unit identifier, delivery unit identifier, terminal application or sealing path identifier. The abnormal state propagation, reverse association, bidirectional verification, stage state query or rule engine processing are used to determine at least one of the following: affected data share identifier, affected physical biochar production share, excluded data share, remaining data share that can be included, or adjusted data share that can be included. The abnormal state propagation, reverse association, bidirectional verification, stage state query, or rule engine processing are executed based on at least one of the stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, or verification information in the chain mapping relationship.

11. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The certification eligibility status includes at least one of the following: eligible for inclusion, excluded, temporarily suspended, pending supplementary certification, included after adjustment, locked and cannot be included repeatedly, or refused to be written. Data share identifiers that are blocked from being written to carbon removal accounting-related datasets are also blocked from being written to at least one of the following datasets: carbon removal credit accounting input dataset, output report declaration dataset, registration agency declaration dataset, carbon removal credit candidate declaration dataset, credit issuance-related dataset, credit declaration-related dataset, credit transfer-related dataset, credit retirement or cancellation-related dataset, interface submission dataset, message queue published data, certified declaration package, or buyer declaration verification dataset.

12. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: Receive or read non-conformance records; the non-conformance records include at least one of the following: non-conforming raw material input window, abnormal operating condition time window, discharge impact time window, affected output unit candidate identifier, affected data share identifier, source side evidence object index, abnormal status identifier, abnormal impact ratio, object hash digest, audit drill-down index, excluded carbon quantity, exclusion ratio, or exclusion share. Based on the non-compliance records, the corresponding data share is marked as excluded, temporarily suspended, pending supplementary certification, or included after adjustment, and the non-compliance records, excluded carbon quantity, excluded ratio, or excluded share are associated with the corresponding audit traceability data. Wherein, when the certification eligibility status includes an exclusion status, the exclusion status includes a full exclusion status or a partial exclusion status; when the exclusion status is a partial exclusion status, the excluded data share and the remaining data share that can be included are generated, or the corresponding numerical fields in the carbon removal credit accounting input dataset, qualified biochar dry mass candidate dataset, net carbon removal candidate dataset, or carbon removal credit candidate quantity field are updated based on the excluded carbon quantity, exclusion ratio, or excluded data share.

13. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: When the certification eligibility status includes the adjusted inclusion status, the adjusted inclusion status includes the inclusion status after deducting the net carbon removal candidate value field, the verifiable dry biochar quantity field, the qualified biochar dry mass candidate value field, the unitized certification result candidate quantity field, the carbon removal credit candidate quantity field, or their related numerical fields. The deduction is performed based on the deduction input field, which includes at least one of the following: path risk adjustment parameter field, data uncertainty parameter field, terminal usage path traceability parameter field, sample detection confidence parameter field, storage and transportation loss parameter field, sealing durability parameter field, or abnormal impact ratio field. The data processing system determines the deduction parameters, deduction level, deduction ratio, or deduction rules based on the deduction input fields, and performs deductions on the net carbon removal candidate value field, verifiable dry biochar quantity field, qualified biochar dry mass candidate value field, unitized verification result candidate quantity field, carbon removal credit candidate quantity field, or their related numerical fields in at least one of the following methods: multiplicative deduction, segmented deduction, lookup table deduction, threshold deduction, or proportional deduction. The data processing system also generates status records or audit traceability data, and at least one of the following is written into the status records or audit traceability data: the value before deduction, the deduction input field, the deduction parameter, the deduction rule, the value after deduction, or the field update record.

14. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The physical biochar production share corresponding to the data share identifier, after carbon removal amount calculation, forms a carbon removal credit candidate data unit corresponding to the unitized verification result or carbon removal credit unit measurement granularity. The carbon removal credit candidate data unit corresponds to a candidate value range that is less than one, equal to one, or greater than one unitized verification result or carbon removal credit unit. Alternatively, the data processing system may establish a mapping relationship between the physical biochar production share and the candidate values ​​of qualified biochar dry quality, net carbon removal candidate quantity, carbon removal credit candidate share, credit issuance related data records, credit statement related data status, credit transfer related data status, or credit retirement or cancellation related data status based on the data share identifier.

15. The carbon removal lifecycle verification data processing method based on data share identification according to claim 1, characterized in that: The data processing system also generates status records or audit traceability data, which includes audit output data. The audit output data includes at least one of the following: data share identifier, source-side verification evidence object index, source-side output unit identifier information, output physical quantity record, chain mapping relationship, lifecycle stage node status, verification judgment input data, stage status data, stage qualification status variable, abnormal status propagation record, verification qualification status, write blocking flag, accounting mutual exclusion lock status, deduction calculation record, exclusion record, record to be supplemented verification record, reason for write refusal, lock status hash digest, audit drill-down index or consistency verification information; Alternatively, the data processing system generates an audit traceability path based on the data share identifier, from the source-side verified evidence object to the terminal application or sealing path, the verification declaration dataset, the credit issuance related dataset, the credit statement related dataset, the credit transfer related dataset, or the credit retirement or cancellation related dataset; the audit traceability path is used to locate the stage data reference, abnormal state propagation record, deduction calculation record, exclusion record, write blocking record, or accounting mutual exclusion lock status corresponding to the same physical biochar production share.

16. The carbon removal lifecycle verification data processing method based on data share identification according to claim 15, characterized in that: The audit output data or the audit traceability path is output, sent, distributed, made available for query, or written to an interface data packet to at least one of the following: an external verification platform, a registration agency system, an audit terminal, a purchaser verification system, an enterprise carbon asset management platform, or a lifecycle stage data source; The interface data packet includes at least one of the following: data share identifier, verification qualification status, write blocking flag, accounting mutual exclusion lock status, write rejection reason, deduction calculation record, lock status hash digest, audit drill-down index, or source-side verification evidence object index.

17. A carbon removal lifecycle verification data processing device based on data share identification, characterized in that, Includes a communication interface, a memory, and a processor connected to the communication interface and the memory; The communication interface is used to acquire source-side verification evidence objects or to receive relevant source-side data, and to communicate with at least one of the following: source-side computing nodes, external verification platforms, registration agency systems, audit terminals, purchaser verification systems, enterprise carbon asset management platforms, or lifecycle stage data sources. The memory is used to store at least one of the following: computer program, source-side verified evidence object, source-side related data, source-side evidence object index, source-side data reference address, object hash digest, data share identifier, chain mapping relationship, verification judgment input data, stage status data, abnormal status, abnormal impact information, target verification rule processing result, status transition rule, rule engine output result, verification qualification status, write blocking flag, write refusal status, numerical deduction processing result, accounting mutual exclusion lock status, lock status hash digest, registration agency interface record, interface data packet, status record, audit drill-down index, or audit traceability data; The processor is configured to perform the following operations: Obtain source-side verification evidence objects, or obtain source-side related data and generate source-side verification evidence objects based on the source-side related data; Based on the source-side verification evidence object, the source-side output unit identification information or output benchmark information in the source-side verification evidence object, or the life cycle stage data associated with the source-side verification evidence object, a data share identifier is generated or updated. The data share identifier corresponds to or is associated with at least a portion of the physical biochar output share and is used to form the verification data processing granularity. Using the data share identifier as the association anchor, a chain mapping relationship is established between the data share identifier and multiple lifecycle stage nodes. The chain mapping relationship includes at least one of stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, or verification information. Based on the chain mapping relationship and the verification judgment input data of at least one life cycle stage node, the verification qualification status of the data share identifier is determined. The verification judgment input data includes at least one of stage status data, abnormal status, target verification rule processing result, status transition rule, or rule engine output result. When the verification judgment input data includes an abnormal state, the affected data share identifier associated with the abnormal state is determined based on the chain mapping relationship, and the verification qualification status of the affected data share identifier is determined. Based on the certification eligibility status, certification data processing is performed on the data share identifier or the data field corresponding to the data share identifier. The certification data processing includes at least one of write blocking, numerical deduction, or calculation mutual exclusion locking. Wherein, when the verification data processing includes accounting mutual exclusion locking, the processor is configured to generate an accounting mutual exclusion lock state, the accounting mutual exclusion lock state being used to restrict the data share identifier or data object corresponding to the same physical biochar production share from being repeatedly written, repeatedly referenced, or repeatedly included in the carbon removal accounting related dataset.

18. A carbon removal lifecycle verification data processing system based on data share identification, characterized in that, It includes an evidence acquisition and generation module, a data share management module, a lifecycle chain mapping module, a verification qualification determination module, a verification data processing module, an accounting mutual exclusion locking module, a lock status storage module, and an audit output module; The evidence acquisition and generation module is used to acquire source-side verifiable evidence objects, or acquire source-side related data and generate source-side verifiable evidence objects based on the source-side related data; The data share management module is used to generate or update data share identifiers based on the source-side verification evidence object, the source-side output unit identification information or output benchmark information in the source-side verification evidence object, or life cycle stage data associated with the source-side verification evidence object; the data share identifier corresponds to or is associated with at least a portion of the physical biochar output share represented by the source-side verification evidence object, and is used to represent the at least a portion of the physical biochar output share in the system as a verification data processing granularity that can be individually performed for inclusion, exclusion, adjustment, locking, status output or audit traceability processing; The lifecycle chain mapping module is used to establish a chain mapping relationship between the data share identifier and multiple lifecycle stage nodes. The chain mapping relationship includes at least one of stage node identifier, stage data reference, upstream stage relationship, downstream stage relationship, or verification information. The verification eligibility determination module is used to determine the verification eligibility status of the data share identifier based on the chain mapping relationship and verification judgment input data of at least one lifecycle stage node; the verification judgment input data includes at least one of stage status data, abnormal status, target verification rule processing result, state transition rule, or rule engine output result; when the verification judgment input data includes an abnormal status, the verification eligibility determination module determines the affected data share identifier associated with the abnormal status based on the chain mapping relationship, and determines the verification eligibility status of the affected data share identifier; The verification data processing module is used to perform verification data processing on the data share identifier or the data field corresponding to the data share identifier based on the verification qualification status. The verification data processing includes at least one of write blocking, numerical deduction or accounting mutual exclusion locking. The accounting mutual exclusion locking module is used to generate an accounting mutual exclusion locking state, and when it detects that another carbon removal credit accounting input dataset, output report declaration dataset, registration agency declaration dataset, carbon removal credit candidate declaration dataset, credit issuance related dataset, credit declaration related dataset, credit transfer related dataset, or credit retirement or cancellation related dataset references a data share identifier that is already in an accounting mutual exclusion locking state, or references a data object that corresponds to the same physical biochar output share as the locked data share identifier, it generates a duplicate declaration risk state, a duplicate accounting risk state, a locked non-repeatable inclusion state, or a write rejection state; The locked state storage module includes at least one of the following: a locked state table, a hash chain storage unit, an append-only log storage unit, an immutable storage unit, a trusted timestamp unit, an audit drill-down index unit, a registry interface data table, an external verification platform communication unit, or a buyer's declaration verification record storage unit. The locked state storage module is used to store, index, output, or distribute at least one of the following: the accounting mutually exclusive locked state, the locked state hash digest, the write-rejected state, or the registry interface record, to an external verification platform, registry system, audit terminal, buyer verification system, enterprise carbon asset management platform, or lifecycle stage data source. The audit output module is used to generate audit output data, audit traceability paths, or interface data packages based on at least one of the following: the data share identifier, the chain mapping relationship, the verification judgment input data, the stage status data, the abnormal status, the target verification rule processing result, the verification qualification status, the accounting mutual exclusion lock status, the status record, or the audit traceability data. The module then outputs, sends, distributes, makes available for querying, or writes the audit output data, audit traceability paths, or interface data packages to at least one of the following: an external verification platform, a registration agency system, an audit terminal, a buyer verification system, an enterprise carbon asset management platform, or a lifecycle stage data source.

19. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the carbon removal lifecycle verification data processing method based on data share identification as described in any one of claims 1 to 16.

Images