A heterogeneous node admission weighting governance method

Abstract

The application discloses a heterogeneous node admission weighting management method. A controlled third-party node forms a candidate anchor edge record and sends the candidate anchor edge record to a server. The server performs source legitimacy, field completeness, subject binding, presence evidence and version compatibility checks, classifies candidate anchor objects, admits the candidate anchor objects, generates a weight vector, a risk disposal object and a state migration result, thereby realizing heterogeneous node registration, weighting, freezing, review and recovery management.

Description

Technical Field

[0001] This invention relates to the fields of trusted anchor edge governance, candidate anchor object normalization, controlled third-party node registration, dynamic weight allocation, state transition control, resource scheduling governance, qualification governance, controlled output and audit replay technology, and in particular to a heterogeneous node trusted access, dynamic weight allocation and resource scheduling governance method, system and storage medium for object-oriented normalization, access classification, trust layering, lifecycle state transition and controlled output of candidate anchor edge records from different controlled third-party nodes. Background Technology

[0002] In scenarios involving multiple parties, such as node access status synchronization, anomaly tracking, environmental consistency verification, audit review, and dispute resolution, existing systems are gradually introducing third-party participation in trust assessment, including controlled service nodes, authorized probe nodes, cooperative sites, and review nodes. However, existing technologies typically suffer from the following problems: 1. Third-party records often exist in the form of ordinary business logs or single-item proof materials, lacking a unified definition of "candidate anchor edge" technical objects, making cross-source unified governance difficult. 2. Different third-party nodes vary significantly in reliability, historical stability, anomaly rate, and verification performance, but existing systems often treat them with equal weight, making it difficult to distinguish between high-value and low-quality witnesses. 3. Once anomalies are detected, they are usually only subject to simple deletion, blocking, or manual marking, lacking a complete lifecycle governance mechanism such as promotion, demotion, freezing, revocation, and reactivation. 4. Graph scoring, node trustworthiness judgment, and dispute resolution often directly consume the plaintext of third-party records, lacking a controlled anchor edge reference output mechanism, which increases data exposure risks and reduces governance flexibility. 5. For complex issues such as batch anomalies, role abuse, task impersonation, cross-site conflicts, duplicate anchor edge submissions, duplicate recovery requests, node collusion, and anomaly handling recovery, there is a lack of a unified dynamic weighting, risk handling parameter linkage, and qualification governance framework.

[0003] Therefore, a new technical solution is needed to standardize the candidate records corresponding to highly trusted third-party witness records into processable candidate anchor objects, and form a controlled third-party trust anchor that is accessible, hierarchical, governable, and replayable through an admission classifier, weight vector allocation, lifecycle state machine, and controlled public reference output mechanism, thereby providing a stable technical foundation for trust judgment in complex multi-party scenarios. Summary of the Invention

[0004] 4.1 Purpose of the Invention The purpose of this invention is to provide a controlled third-party trust anchor registration, hierarchical authorization, and lifecycle governance method, system, and storage medium to solve the problems in the prior art, such as the lack of a unified object structure for third-party witness objects, the inability to perform deterministic access classification for different sources, the lack of continuous state governance after anomalies, the lack of unified linkage between risk handling parameters and qualification governance, and the excessive reliance on plaintext materials for external calls and the difficulty in supporting historical replay.

[0005] 4.2 Technical Solution To achieve the above objectives, the present invention adopts the following technical solution: This invention provides a method for controlled third-party trust anchor registration, hierarchical authorization, and lifecycle governance, which is executed collaboratively by controlled third-party nodes and a server. The controlled third-party nodes perform summary extraction, on-site evidence encapsulation, and integrity binding on original witness materials generated during node access status synchronization, abnormal status tracking, site verification, status recovery review, or audit review, forming candidate anchor edge records and sending them to the server. The server then standardizes these candidate anchor edge records into candidate anchor objects. Each candidate anchor object includes at least two or more of the following: source type reference, institution identity reference, role / permission reference, subject reference, task or event reference, on-site evidence reference, stage chain reference, idempotent reference, integrity reference, and rule version reference.

[0006] In one implementation, the server performs source legitimacy checks, field completeness checks, organization and role mapping checks, subject binding consistency checks, presence evidence sufficiency checks, stage chain minimum closure condition checks, and version compatibility checks on candidate anchor objects.

[0007] In one implementation, the server classifies candidate anchor objects into high admission, medium admission, observation admission, denial with supplementary evidence, or hard denial based on the inspection results, and generates controlled anchor edge public references and corresponding registration records only for candidate anchor objects with high admission, medium admission, or observation admission.

[0008] The server further maintains one or more of `admission_rule_ref`, `repairable_reject_rule_ref`, and `transition_rule_ref`. `admission_rule_ref` describes the minimum admission thresholds for different `source_type_ref`s in terms of field completeness, sufficiency of evidence present, and closure of the phase chain; `repairable_reject_rule_ref` describes which gaps qualify as reparative rejections rather than hard rejections; and `transition_rule_ref` describes the state transition boundaries corresponding to different anomaly hits, reparative evidence results, and recovery thresholds. Thus, the admission classification, reparative rejection, and lifecycle governance of this invention are no longer represented as abstract management configurations, but converge into a set of versionable, replayable rule objects.

[0009] In one implementation, the server assigns trust levels and weight vectors to registration records based on one or more of the following: source base weight, institution stability weight, role stability weight, presence evidence quality weight, stage chain integrity weight, historical anomaly penalty item, and cross-anchor consistency gain item.

[0010] This invention focuses on solving the problems of standardized access, trust layering, and state transition governance of heterogeneous candidate anchor objects from multiple sources. The candidate anchor objects can come from various types of controlled third-party nodes, including but not limited to stage credentials output by service nodes, audit nodes, or probe nodes.

[0011] The server further imposes source diversity constraints on the cross-anchor consistency gain term, meaning that the corresponding gain term is only allowed to enter a high-weight state when different source types, different institutional domains, or different role domains form compatible support. For closed high-weight structures formed by mutual weighting of sources from the same small group over a long period, the server can reduce its final weight through diversity penalty terms, observation flags, or supplementary verification requests. This design can further strengthen the governance boundary of the invention for closed mutual endorsement structures.

[0012] In one implementation, the server causes registration records to migrate between one or more lifecycle states, including registered, weighted, under observation, downgraded, frozen, under review, revoked, reactivated, and reactivated, according to state transition rules, and records state transition path references and corresponding cause vector references.

[0013] In one implementation, when a candidate anchor object or an abnormal event associated with the candidate anchor object, a state recovery or controlled review result hitting evidence consistency anomaly, an abnormal pattern hit result, node collusion association result, historical false alarm correction result, or governance rule hit result, the server further generates a risk handling object. The risk handling object includes at least one or more of the following: risk level reference, handling suggestion reference, cause vector reference, recovery threshold reference, and freeze scope reference. Based on the risk handling object, the server can perform one or more of the following actions on the corresponding registration record: adjusting the risk preparation resource ratio, downgrading the weight vector, freezing handling parameters, lowering handling parameters, extending the observation period, suspending access eligibility, transferring to review, or restoring to normal status.

[0014] In one implementation, the server outputs one or more of the following to the external calling entity: status code, gear code, weight vector reference, parameter status code, qualification status code, cause vector reference, controlled anchor edge public reference, or risk marker, instead of directly outputting the complete candidate anchor edge material in plaintext to the low-privilege calling entity; and retains rule version references and status transition path references to support subsequent audit replay or historical recalculation.

[0015] 4.3 Beneficial Effects Compared with the prior art, the present invention has at least the following beneficial effects: 1. By standardizing third-party witness records into candidate anchor objects, a unified data object foundation for cross-source processing can be established, reducing the fragmentation of field interpretation between different business lines. 2. Through a classification mechanism of high admission, medium admission, observation admission, rejection with supplementary evidence, and hard rejection, the decision on whether to enter the subsequent governance process, whether to allow supplementary evidence, and whether to allow continued consumption can be clarified, improving the certainty of admission processing. 3. Through a weighted vector quantification design, factors such as source, institution, role, on-site evidence, stage chain, and historical anomalies can be expressed separately, improving the interpretability and verifiability of hierarchical weighting. 4. Through a lifecycle state machine and state transition path auditing mechanism, continuous governance can be performed on third-party anchor edges, rather than a one-time acceptance or rejection, and subsequent accountability can be supported. 5. Through a controlled anchor edge public reference output and rule version auditing mechanism, the direct dependence of external consumption nodes on underlying plaintext materials can be reduced, while supporting audit replay and historical review. 6. By linking risk disposal targets, recovery threshold references, and parameter status codes, anti-collusion, node collusion, and abnormal recovery in the recovery process can be incorporated into the same governance framework, improving the consistency of parameter governance and qualification governance. 5. Description of the attached drawings

[0016] This specification can be further understood in conjunction with the accompanying drawings, which may include: Figure 1A schematic diagram of the overall structure of a controlled third-party trust anchor registration, risk management, and qualification governance system; Figure 2 This is a schematic diagram of the candidate anchor edge admission determination process; Figure 3 A schematic diagram illustrating the weighted stratification, risk management, and lifecycle governance process; Figure 4 A schematic diagram illustrating the process of cross-anchor consistency, risk propagation, and qualification linkage; Figure 5 This is a schematic diagram of the controlled output, audit replay, and historical review process. Detailed Implementation

[0017] The present invention will be further described below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0018] 6.1 Candidate Anchor Object Normalization and Source Record Reception like Figure 1 As shown, in one implementation, candidate anchor edge records come from multiple controlled third-party nodes. The source types include at least service process witnessing anchor edges, abnormal event auditing anchor edges, site verification anchor edges, status review anchor edges, audit review anchor edges, or anchor edges formed by other controlled third-party nodes. Each controlled third-party node first performs summary extraction, presence evidence encapsulation, and integrity binding on the original witnessing materials, then forms candidate anchor edge records and sends them to the server.

[0019] Although candidate anchor records from different source types have different business semantics, the server first standardizes them into candidate anchor objects. These candidate anchor objects can include at least two or more of the following: source type reference, organization identity reference, role / permission reference, subject reference, task or event reference, presence evidence reference, stage chain reference, idempotent reference, integrity reference, and rule version reference. The server assigns an internal object identifier to each candidate anchor object and establishes a mapping relationship between the original source record and the candidate anchor object for subsequent admission classification, authorization, and replay.

[0020] 6.2 Admission Classifier and Rejection Path like Figure 2 As shown, in one implementation, the server performs source legitimacy checks, field completeness checks, organization and role mapping checks, subject binding consistency checks, presence evidence sufficiency checks, stage chain minimum closure condition checks, and version compatibility checks for each candidate anchor object.

[0021] In one implementation, the server does not simply output pass or reject, but categorizes candidate anchor objects into high admission, medium admission, observation admission, verifiable rejection, or hard rejection based on the aforementioned check results. If a field is missing but can be supplemented, or the stage chain is not closed but can be supplemented, then it enters verifiable rejection; if the source is illegal, the version is severely incompatible, or there is a serious risk of forgery, then it enters hard rejection; only for high admission, medium admission, or observation admission objects, controlled anchor edge public references and corresponding registration records are generated.

[0022] 6.3 Initial Layered Weighting like Figure 3 As shown, in one implementation, for candidate anchor objects that have entered high-admission, medium-admission, or observation admission, the server further performs initial hierarchical weighting. The weight vector can be determined by a combination of the following factors: 1. Weight of basic source; 2. Weight of institutional stability; 3. Weight of role stability; 4. Weight of the quality of evidence present; 5. Weight of the integrity of the stage chain; 6. Penalty for historical anomalies; 7. Gain for cross-side consistency; 8. Correction for existing review results.

[0023] The server can divide registration records into different trust levels, such as high level, medium level, and observation level, based on the above factors, and assign them different initial weight ranges; the server retains references to each weight component instead of just retaining a single total score to support subsequent review and replay.

[0024] 6.4 Lifecycle State Machine and State Transitions In one implementation, the controlled third-party trust anchor is not a static object, but rather a lifecycle state machine that enters a continuously evolving state.

[0025] The server can trigger status changes based on the following inputs: 1. Supplementary certification result; 2. Dispute review result; 3. Abnormal pattern hit status; 4. Historical stability update value; 5. Cross-edge consistency change value; 6. Manual audit conclusion.

[0026] Correspondingly, the server performs state transitions for registration records between the states of registered, weighted, under observation, downgraded, frozen, under review, revoked, reactivated, and reactivated, and records a state transition path reference and a cause vector reference for each transition. Upgrading, downgrading, freezing, revocation, and reactivation are manifested as state transitions and corresponding weight vector adjustments, rather than simply as label modifications.

[0027] 6.5 Anomaly Pattern Recognition In one implementation, the server focuses on identifying the following anomalous patterns: 1. Batch Anomaly: An abnormally high density of similar candidate anchor edges appears within a short period of time; 2. Role Abuse: The same role's permission references cover a large number of mutually exclusive tasks within an unreasonable time window; 3. Task Impersonation: The task or event described in the candidate anchor edge is inconsistent with the real authorization chain; 4. Cross-Site Conflict: The same organization or role forms conflicting anchor edges in multiple incompatible sites; 5. Duplicate Anchor Edge Submission: The same candidate anchor edge is repeatedly packaged and submitted; 6. Duplicate Recovery Request Hit, Abnormal Stage Chain Expansion Hit, or Abnormal Collaboration Chain Hit; 7. Collusive Maintenance Service Node Hit or Abnormal Review Conclusion: Manual or automatic review clearly points out that the anchor edge has a major problem.

[0028] When one or more of the above anomalies are detected, the server performs actions such as demotion, freezing, revocation, parameter downgrading, access qualification suspension, or transfer to review for the corresponding controlled third-party trust anchor, and records the cause vector and state transition path.

[0029] 6.6 Risk Management Targets, Parameter Control and Recovery Conditions In one implementation, when the server detects a high-risk case but the evidence is not yet closed, it does not directly and permanently revoke the corresponding registration record. Instead, it first performs one or more of the following actions: temporary freeze, observation period extension, and pending recovery status marking. The above governance actions are then bound to recovery threshold references, freeze range references, and execution time window references.

[0030] In one implementation, reactivation is not automatic, but requires at least one or more of the following conditions to be met: successful recertification, passing of the observation period, subsequent stable record reaching the threshold, or manual review to remove the abnormality.

[0031] The server can set different reactivation thresholds for different source types. For example, anchor edges for anomaly audits can require a longer observation period after a major dispute, anchor edges for service process witnessing can require supplementary proof of the closure of the phase chain, and anchor edges for audit review can require higher-level manual confirmation.

[0032] 6.7 Controlled Output Mechanism and Audit Replay like Figure 5 As shown, in one implementation, the server does not directly output the complete candidate anchor edge material in plaintext to the low-privilege calling entity, but instead outputs a controlled anchor edge public reference. The controlled anchor edge public reference may be one or more of an irreversible reference, a de-identified index, or a restricted mapping identifier.

[0033] External consumer nodes can obtain status codes, gear codes, weight vector references, parameter status codes, qualification status codes, cause vector references, and risk results based on the publicly referenced controlled anchor edge, which can be used for graph scoring, process judgment, status review, or dispute resolution, without having to directly read all the plaintext evidence at the underlying level.

[0034] In one implementation, the server further retains rule version references, state transition path references, and related input summary references to support audit replay or historical review. Through this mechanism, when the anchor state changes or regulatory authorities require tracing, the system can either return the current controlled output or reconstruct the processing conclusions under historical rules.

[0035] 6.8 Synergy with Atlas Scoring like Figure 4 As shown, in one implementation, the controlled third-party trust anchor serves as the graph scoring input and performs joint authorization with the device mutual verification edge, the historical consistency edge, the risk propagation edge, or the dispute review edge.

[0036] For example, high-level anchors from service process witness nodes can enhance the credibility of a certain process behavior; high-level anchors from abnormal event audit nodes can enhance the credibility of a certain status review path; when anchors from multiple sources are consistent with each other, the overall judgment score can be improved; when a key anchor is downgraded or frozen, the external judgment result can be affected synchronously through the risk propagation mechanism.

[0037] 6.9 Other Implementation Methods In one implementation, the server can configure independent rule versions for different source types and allow different admission thresholds and state transition strategies to be used within the same unified framework.

[0038] In one implementation, the server can encode historical manual review results as long-term stability parameters to influence the initial weights of subsequent organizations, roles, or sources of the same type.

[0039] In one implementation, controlled anchor references may also carry expiration time, query limit, or disclosure level tags to further enhance controlled use capabilities.

[0040] Summary of methods and processes The method of the present invention includes, in a typical implementation process: 1. Controlled third-party nodes extract summaries, encapsulate on-site evidence, and bind integrity to the original witness materials, forming candidate anchor edge records and sending them to the server. The server then normalizes these records into candidate anchor objects. 2. Candidate anchor objects undergo source legality checks, field completeness checks, institution and role mapping checks, subject binding consistency checks, on-site evidence sufficiency checks, stage chain minimum closure condition checks, and version compatibility checks. 3. Based on the check results, candidate anchor objects are classified into high-admission, medium-admission, observation admission, rejection with supplementary evidence, or hard rejection. Controlled anchor edge public citations and registration records are generated for admission objects. 4. Trust levels and weight vectors are assigned to registration records. Risk disposal objects are generated when one or more of the following are hit: evidence consistency anomaly, anomaly pattern hit, node collusion association result, historical false alarm correction result, or governance rule hit result. 5. Based on the risk disposal objects, one or more of the following are executed: risk preparation resource ratio adjustment, disposal parameter freezing, disposal parameter reduction, observation period extension, admission qualification suspension, transfer to review, or restoration to normal status. 6. Output status codes, gear codes, weight vector references, parameter status codes, qualification status codes, cause vector references, controlled anchor edge public references, or risk markers to external calling entities; 7. Retain rule version references and status transition path references to support audit replay, historical review, and high-privilege review.

[0041] Candidate anchor object structure, source specification and field model expansion To further disclose the governance objects and governance methods of this invention, the following details the candidate anchor edge object structure, source specifications, field model, and unified abstraction method.

[0042] Candidate anchor records are not simply "a third party uploaded a proof," but are uniformly abstracted as candidate_anchor_record. These records can contain at least one or more of the following: anchor_candidate_ref, source_type_ref, org_ref, role_ref, task_or_event_ref, subject_ref, presence_ref, stage_chain_ref, quality_bitmap, integrity_ref, rule version reference, policy_ver, idempotent_ref, and history_hint_ref.

[0043] `source_type_ref` is used to distinguish the source type of candidate anchor edges, such as `SERVICE_PROCESS_WITNESS`, `EVENT_AUDIT`, `SITE_VALIDATION`, `STATE_REVIEW`, `AUDIT_REVIEW`, `LEGAL_CONFIRM`, `MAINTENANCE_CONFIRM`, or other controlled sources. Different source types can adopt different strategies in terms of admission thresholds, initial weights, state transition rules, and reactivation conditions, but the underlying object structure remains unified.

[0044] `presence_ref` is used to express evidence that a third-party node was indeed present or had contact with the user. This `presence_ref` can come from one or more of the following: proximity interaction summary, site environment anchor, session establishment summary, task acceptance summary, or controlled event trigger summary. Through the unified abstraction of `presence_ref`, the server can use a unified judgment interface across different business lines, without requiring external consumer nodes to directly understand all the details of each business.

[0045] `stage_chain_ref` is used to indicate whether a candidate anchor edge has evidence of stage chain closure. For candidate anchors from service process witness sources, `stage_chain_ref` can include start, middle, and end stages; for candidate anchors from exception event audit sources, `stage_chain_ref` can include start, collection, sealing, and submission stages; for candidate anchors from audit review sources, `stage_chain_ref` can only include audit initiation, audit completion, and conclusion sealing stages. The server can interpret the minimum valid conditions for `stage_chain_ref` based on the source type.

[0046] `history_hint_ref` is used to provide historical hints related to the source entity of the candidate anchor edge, such as the organization's historical stability, role anomaly rate, terminal anomaly rate, historical dispute hit rate, or recent review performance. `history_hint_ref` only provides in-domain hints required for server governance and does not expose them directly to low-privilege callers.

[0047] Entry threshold engine, rule splitting and rejection path expansion The server does not use a single Boolean admission rule, but instead performs hierarchical judgment on candidate anchor edges through the admission_engine. The admission_engine can be broken down into at least one or more of the following: field completeness check, source legality check, organization role consistency check, subject binding check, presence validity check, stage chain completeness check, historical anomaly pre-screening, and version compatibility check.

[0048] Field completeness check determines whether candidate_anchor_record has the minimum set of fields required for the current source type; source validity check determines whether source_type_ref comes from a registered controlled source domain; organization role consistency check determines whether org_ref and role_ref are in a valid mapping relationship; subject binding check determines whether task_or_event_ref, subject_ref, and presence_ref revolve around the same business object; presence validity check determines whether presence_ref is sufficient to support "actual presence"; stage chain completeness check determines whether stage_chain_ref meets the minimum closure requirements; historical anomaly pre-screening determines whether the source subject is in a globally frozen or highly anomaly observation state; version compatibility check determines whether field specifications and policy specifications can be correctly interpreted by the current server.

[0049] The admission results can be further divided into five categories: ACCEPT_HIGH, ACCEPT_MID, ACCEPT_OBSERVE, REJECT_REPAIRA (Bluetooth Low Energy), and REJECT_HARD. ACCEPT_HIGH indicates that it can be directly registered as a high-end anchor; ACCEPT_MID indicates that it can be registered but with a low initial weight; ACCEPT_OBSERVE indicates that it is temporarily included for observation; REJECT_REPAIRA (Bluetooth Low Energy) indicates that it can be reapplied for after supplementary certification; REJECT_HARD indicates that there is serious illegal source, serious counterfeiting, or serious version incompatibility, and it is not allowed to enter the subsequent governance process.

[0050] The server records a rejection_reason_vector for each rejection. This vector can include reasons such as missing fields, invalid roles, inconsistent tasks, insufficient presence, stage gaps, excessively high historical data, and unsupported source version. If the source system subsequently requests supplementary certification, the direction of the supplementary certification can be precisely determined based on the rejection_reason_vector.

[0051] Initial weight allocation, trust levels, and multi-factor combination expansion The initial weights are not determined solely by the source type, but are derived from a combination of multiple factors. These factors may include at least one or more of the following: base_source_weight, org_stability_weight, role_stability_weight, presence_quality_weight, stage_chain_weight, history_penalty, cross_anchor_consistency_bonus, and manual_review_bonus.

[0052] `base_source_weight` reflects the basic credibility of the source type. For example, controlled anomaly audit anchors may be higher than ordinary site verification anchors in some scenarios; however, in other scenarios, long-term stable service process witness anchors may be more frequent and easier to statistically analyze, thus having an advantage in stability. `org_stability_weight` reflects the organization's historical stability, long-term anomaly rate, and audit pass rate; `role_stability_weight` reflects the behavioral stability of a specific role; `presence_quality_weight` reflects the quality of `presence_ref`; `stage_chain_weight` reflects whether the stage chain is closed; `history_penalty` reflects historical anomaly penalties; `cross_anchor_consistency_bonus` reflects consistency with other high-level anchors; and `manual_review_bonus` reflects the bonus from manual review.

[0053] The server can categorize successfully registered anchor edges into tiers: TIER_A, TIER_B, TIER_C, OBSERVE, SUSPENDED, and REVOKED. TIER_A indicates high weighting in graph scoring and key decisions; TIER_B indicates medium weighting; TIER_C indicates weak support; OBSERVE indicates temporary observation; SUSPENDED indicates freezing; and REVOKED indicates revocation. Different tiers correspond to different output strategies and different review priorities.

[0054] To prevent a single source type from naturally monopolizing weight, servers can set weight caps, combination usage caps, or diversity requirements for different source types. For example, if external decisions are entirely supported by anchors of the same source type, the system can proactively request the introduction of heterogeneous anchors or other auxiliary materials to reduce the risk of single-source distortion.

[0055] Lifecycle state machine, state transition conditions and governance actions The controlled third-party trust anchor has a complete lifecycle state machine. The state machine may include at least the following states: RECEIVED, ADMITTED, REGISTERED, WEIGHTED, OBSERVING, UPGRADED, DOWNGRADED, FROZEN, UNDER_REVIEW, REVOKED, REACTIVATING, and REACTIVATED.

[0056] RECEIVED indicates that the candidate record has been accepted; ADMITTED indicates that admission has been passed; REGISTERED indicates that it has entered the anchor registration sequence; WEIGHTED indicates that weights have been assigned; OBSERVING indicates that it is under observation; UPGRADED indicates that it has been promoted due to good subsequent performance; DOWNGRADED indicates that it has been demoted due to abnormal or uncertain factors; FROZEN indicates that it is temporarily frozen; UNDER_REVIEW indicates that it is undergoing manual or automatic review; REVOKED indicates revocation; REACTIVATING and REACTIVATED indicate the reactivation process and completion status.

[0057] The conditions for state transition can include at least one or more of the following: successful subsequent supplementary certification, reaching a threshold for the number of subsequent stable windows, passing manual review, encountering an abnormal pattern, an increase in historical anomaly rate, a decrease in cross-anchor consistency, suspension of the source institution, disabling of the role, change in compliance policy, or failure of version compatibility. The server can maintain these conditions in a versioned manner using the format transition_rule_ref.

[0058] In addition to state switching, governance actions may include: adjusting the output range, restricting participation in certain business decisions, delaying participation in key scoring, triggering related anchor reviews, freezing settlement parameters, requiring the source end to conduct batch self-inspections, or increasing the frequency of manual reviews. Therefore, the governance of this invention not only affects individual anchors but also anchor clusters and the source ecosystem.

[0059] Cross-anchor consistency, map coordination and risk propagation In some implementations, the server does not view a single anchor edge in isolation. Instead, it uses `anchor_graph_ref` to integrate multiple controlled third-party trusted anchors, device mutual verification edges, historical consistency edges, and dispute verification edges into the same collaborative framework. After registration, candidate anchors can become high-level nodes in the graph and form cross-support or conflict relationships with other edges.

[0060] In some implementations, `cross_anchor_consistency_bonus` can be calculated as follows: First, whether the same `subject_ref` receives mutual support from anchors of different source types within a similar time window; second, whether anchors generated by the same organization or role are consistent with other independent sources; third, whether there are complementary rather than conflicting anchors in the same event chain; and fourth, whether there are high-level external nodes that break the closed structure. If multiple independent sources are highly consistent in key fields, the overall credibility can be improved.

[0061] In some implementations, risk propagation is not simply a matter of "one anchor causing all anchors to fail." The server propagates risk at different granularities: subject_ref, org_ref, role_ref, terminal_ref, and source_type_ref. For example, if a role frequently exhibits abnormal behavior, it can primarily affect anchors related to that role; if a systemic fraud is discovered across an organization, the impact can extend to the organization level; if only a terminal firmware has a vulnerability, it can preferentially affect anchors related to terminal_ref.

[0062] In some implementations, the server can also identify the risk of a "closed high-weight ecosystem," where anchor edges from a small group of sources are mutually weighted over a long period without external independent source verification. To address this, the system can introduce a diversity penalty term and require high-weight anchors to have a certain proportion of heterogeneous source support.

[0063] Anomaly pattern identification, batch risk and source governance In some implementations, the first abnormal mode is batch similar anchor edges. Attackers generate candidate anchors in a short period of time that are similar in field structure, time distribution, and stage chain template. In response, the server can perform cluster detection based on template repetition rate, time difference distribution, and quality label similarity, and observe or reduce the weight of the entire batch of records beforehand.

[0064] The second abnormal pattern is role abuse. A certain role_ref covers a large number of tasks, multiple sites, or multiple incidents within an unreasonable timeframe. To address this, the server can construct a role_pressure_score and use it as a common input to both the admission_engine and lifecycle_engine.

[0065] Anomaly Mode 3 is an institutional-level systemic anomaly. An institution's failure rate for supplementary certification, success rate in resolving disputes, or revocation rate is significantly higher than the industry baseline over a longer period. In response, the server can lower the institution's base_source_weight overall, or even require it to enter a special review period.

[0066] The fourth abnormal pattern is duplicate packaging submission. The same business facts are repeatedly packaged into different `candidate_anchor_record`s after slight field transformations. To address this, the server can rely on `idempotent_ref`, `subject_ref`, `time_bin_ref`, `stage_chain_ref`, and `anchor_similarity_hash` for deduplication and aggregation.

[0067] The fifth abnormal mode is a version compatibility anomaly. The field specification version submitted by the source is too old, or the field mapping relationships have unclear boundaries, causing the current rules to be unable to interpret them stably. To address this, the server incorporates `version_compatibility_score` into the admission threshold, restricting the registration of high-weight records with low compatibility.

[0068] Abnormal mode six is ​​a false reactivation. The source repeatedly requests to restore the high-level state without actually rectifying the issue. In response, the server requires that reactivation_evidence_ref, observation_pass_ref, or manual_clear_ref form a closure before allowing reactivation.

[0069] Reactivation, observation period and recovery conditions In some implementations, reactivation should not be completed automatically over time, but requires one or a combination of "evidence of rectification + observation period + subsequent stability record". Evidence of rectification may include successful supplementary certification, passing internal audit, terminal version repair, role reset, organizational rectification report or manual review conclusion; the observation period is used to confirm that the anomaly is not persistent; subsequent stability record is used to verify that the recovery is not a short-term accident.

[0070] In some implementations, the reactivation process can be further divided into REQUEST_REACTIVATION, VERIFY_REMEDIATION, OBSERVE_POST_FIX, LIMITED_REENA Bluetooth Low Energy, and FULL_REACTIVATION. REQUEST_REACTIVATION indicates that the source has submitted an application; VERIFY_REMEDIATION is used to check rectification materials; OBSERVE_POST_FIX is used for an observation period; LIMITED_REENA Bluetooth Low Energy indicates limited recovery, allowing only low-weight participants; and FULL_REACTIVATION indicates a complete recovery to the corresponding level.

[0071] In some implementations, different source types can require different observation periods. Service process witness anchors can require a certain number of new closed-loop stages; anomaly audit anchors can require that multiple transactions have not resulted in further unauthorized actions; site verification anchors can require stable environmental anchors to be continuously online; and audit review anchors can require manual confirmation and a longer audit observation period. By using a source differentiation strategy, governance accuracy can be improved.

[0072] Controlled output channels, calling levels, and external consumption methods are discussed. In some implementations, the server does not output complete candidate anchor data, but only controlled objects such as `anchor_public_ref`, `status_code`, `tier_code`, `weight_vector_ref`, `reason_vector_ref`, `risk_tag_ref`, and `expiry_ref`. Low-privilege consumer nodes only consume `status_code`, `tier_code`, and `risk_tag_ref`; graph processing nodes can additionally consume `weight_vector_ref`; and manual review nodes with higher privileges can request more details of `reason_vector`.

[0073] In some implementations, the controlled output channels can be at least divided into summary output channels, graph output channels, review output channels, and audit output channels. The summary output channel is primarily for status assessment, the graph output channel for consistency scoring, the review output channel for dispute review, and the audit output channel for compliance and long-term auditing. Different output channels may share the same anchor base but employ different disclosure strategies and field subsets.

[0074] In some implementations, the server can also output an `attachability_ref` for the anchor edge, informing external consumer nodes whether the anchor edge is allowed to be used as "strong support," "weak support," or "background material only." This allows external consumer nodes to safely consume anchor edge results without having to understand all the governance rules themselves.

[0075] Rule version, deployment strategy and system implementation supplement In some implementations, the server maintains at least the source_schema_ver, admission_rule_ver, weight_rule_ver, lifecycle_rule_ver, reactivation_rule_ver, and output_policy_ver. Each version can be explicitly logged in anchor-side records and output records to support replay of historical results.

[0076] In some implementations, the system can be deployed in layers based on configuration domain, region, industry, or business line. Some regions may have stricter requirements for anomaly audit anchor disclosure, some industries may rely more on service process witness anchors, and some configuration domains may only enable certain source types. Servers can allow differentiated policy configurations within a unified framework without changing the core abstraction of candidate anchor edges.

[0077] In some implementations, this invention can serve as a unified registration, hierarchical authorization, and lifecycle governance solution for service process witness-type strong anchors, abnormal event audit-type strong anchors, or other controlled third-party strong anchors. However, its key technical focus lies in how to uniformly register, authorize, and govern multiple types of third-party strong anchors. Therefore, this invention is applicable to multi-source third-party strong anchor governance scenarios.

[0078] Examples of computational processes, governance cases, and interface implementation. In some implementations, the governance method of the present invention can be further illustrated by exemplifying the calculation process. Suppose a candidate_anchor_record originates from a service process witness scenario, its source_type_ref is SERVICE_PROCESS_WITNESS, org_ref is a chain store institution, role_ref is a quality inspection role, presence_ref is composed of a near-interaction summary and a site environment anchor, and stage_chain_ref is a closed chain of four stages: start, execution, quality inspection, and delivery. The server first executes the admission_engine, finding that the field completeness meets the requirements, role_ref is compatible with org_ref, presence_ref is of high quality, and historical anomaly rate is low; therefore, the admission result is ACCEPT_HIGH. Subsequently, the weight_engine calculates base_source_weight, org_stability_weight, role_stability_weight, presence_quality_weight, and cross_anchor_consistency_bonus, deducts a very small history_penalty, and finally assigns it the TIER_A level. If subsequent abnormal event audit anchors and service process witness anchors support each other on the same device timeline, then the anchor can continue to maintain a high weight.

[0079] In other implementations, if a candidate_anchor_record originates from an anomaly audit scenario, with source_type_ref set to EVENT_AUDIT, but its role_ref has been flagged multiple times for out-of-scope disclosure risks within the past week, and the current stage_chain_ref lacks an end-stage sealing anchor, then the admission_engine can provide an ACCEPT_OBSERVE or ACCEPT_MID result. The weight_engine will then only grant it a TIER_C or OBSERVE status due to a decrease in role_stability_weight and an increase in history_penalty. If subsequent supplementary verification is successful and passes manual review, the lifecycle_engine can upgrade it to TIER_B.

[0080] In some implementations, governance case one is "institutional-level systemic anomaly." Suppose an institution's revocation rate, certificate resubmission failure rate, and dispute hit rate are significantly higher than the industry baseline within a month. The server can mark this institution as an org_watch_ref and uniformly lower the base_source_weight of its newly entered anchor edges. For already registered anchor edges, it's not necessary to revoke them all at once; instead, their status can be changed to OBSERVING or DOWNGRADED, and higher-density heterogeneous source support can be required.

[0081] The second governance case is "Role-Level Abuse Remediation." A certain role_ref was previously FROZEN due to batch anomalies. After the source organization submitted a remediation report, terminal repair proof, and subsequent stability records, the server entered the REQUEST_REACTIVATION and VERIFY_REMEDIATION phases. During the observation period, anchors related to this role only participate with low weight in the LIMITED_REENA Bluetooth Low Energy mode. If the observation period is passed, it will then be upgraded to REACTIVATED. This design illustrates that the governance of this invention is not a simple blacklist, but a recoverable lifecycle governance.

[0082] The third governance case is "Multi-Source Consistency Bonus." A device may simultaneously possess service process witness anchors, anomaly event audit anchors, and site verification anchors within the same time period, and these three are highly consistent in terms of subject, time, and stage. The server can improve the overall credibility through `cross_anchor_consistency_bonus` and `diversity_bonus`, allowing graph processing nodes to treat this multi-source combination as strong support. However, if all three originate from the same closed institutional ecosystem and lack external heterogeneous sources, the system can still apply diversity penalties to prevent misjudgments caused by mutual endorsement within the closed ecosystem.

[0083] In some implementations, the output channels can be further described as follows: The summary output channel can receive `subject_ref`, `time_scope_ref`, and `caller_scope_ref`, and return the status code, level, and risk tag; the graph output channel can return `weight_vector_ref`, `attachability_ref`, and `risk_tag_ref` that can be consumed by graph processing nodes; the review output channel can return more granular `reason_vector_ref`, `transition_path_ref`, and `controlled_material_index_ref` under high privileges; the audit output channel can return the complete lifecycle trajectory, version number, manual review record, and disclosure audit record. Different output channels share the same `anchor_public_ref`, but it is pruned by the `output_policy_ver` control field.

[0084] In some implementations, the server can also output `anchor_dependency_ref` to describe which downstream facts a high-weight anchor currently depends on. For example, a high-weight anchor might depend on `stage_chain_ref` being complete, `presence_ref` being of high quality, and `org_stability_weight` being normal; if any of these prerequisites subsequently fail, the `lifecycle_engine` can re-evaluate the anchor based on `dependency_break_reason`. This dependency output helps external consumer nodes understand "why a certain anchor has been downgraded".

[0085] In some implementations, to support large-scale deployment, servers can employ tiered caching and batch processing governance mechanisms. The admission layer can perform real-time lightweight judgments, the weighting layer can use near real-time batch processing recalculation, the lifecycle layer can recalculate hourly or by event triggering, and the auditing layer can be asynchronously persisted. This balances real-time business judgments with long-term governance accuracy.

[0086] In some implementations, the present invention also allows for configuration of domain-level parameter differences. For example, some configuration domains place greater emphasis on exception audit anchors, thus increasing the base_source_weight of EVENT_AUDIT; other configuration domains place greater emphasis on service process witness anchors, thus increasing the stage_chain_weight requirement of SERVICE_PROCESS_WITNESS. As long as source_schema_ver and the core state machine are not compromised, the present invention can achieve differentiated configurations within a unified framework.

[0087] In some implementations, a set of typical output object examples can be further provided: `anchor_public_ref` is used to externally index a specific anchor edge; `status_code` can be `ACTIVE`, `OBSERVE`, `FROZEN`, or `REVOKED`; `tier_code` can be `TIER_A`, `TIER_B`, or `TIER_C`; `weight_vector_ref` can contain components of stability, source, consistency, and risk dimensions; `reason_vector_ref` can contain reasons for demotion, upgrade, or rejection; `attachability_ref` can be `STRONG_SUPPORT`, `WEAK_SUPPORT`, or `BACKGROUND_ONLY`. Through object-oriented output, external consumer nodes do not need to know all the internal scoring details to safely consume anchor edges according to the governance results.

[0088] Audit replay, historical review and version migration unfold In some implementations, this invention supports audit replay capabilities. Audit replay refers to the ability of a server to reconstruct the admission results, weighting results, and state transition results at a future point in time after receiving a dispute, regulatory inspection, or compliance audit request, based on historically retained candidate_anchor_record, transition_rule_ref, output_policy_ver, and manual_review_trace. To achieve this, the system can maintain long-term traces of key rule versions, cause vectors, and input summary references.

[0089] In some implementations, historical backtesting does not necessarily mean directly rewriting the original historical results, but rather generating `replay_result_ref` or `backtest_result_ref`. This allows the server to explain both "why the conclusion was given under the old rules" and "what changes will occur after recalculation under the new rules." This capability is of significant value for institutional rectification assessments, rule optimization verification, and audit documentation.

[0090] In some implementations, a dual-track strategy can be adopted during version migration: on the one hand, newly entering candidate anchor edges are processed according to the rules of the new version; on the other hand, historical anchor edges retain the conclusions of the old version, but can generate compatibility mapping explanations when necessary. For example, a certain reason_vector in the old version may be split into more granular reason items in the new version. The server can provide the correspondence between the old and new reasons through migration_map_ref, without having to write back the original historical records. In this way, the present invention can maintain governance continuity and audit interpretability in long-term evolution.

[0091] In some implementations, the governance system can also output `profile_ref` or `domain_profile_ref` to indicate under which configuration domain, industry domain, and parameter emphasis the current anchor edge conclusion was reached. This way, external consumer nodes, when consuming anchor edges, not only know "what the conclusion is," but also "under which governance profile the conclusion holds true." For example, a high-privilege review-type configuration domain might emphasize the consistency of anchors related to anomaly event auditing, while a process witness-type configuration domain might emphasize the phase closure of anchors related to service process witnessing. Linking and recording the governance profile with anchor edge results facilitates subsequent cross-configuration domain auditing, policy replay, and parameter tuning.

[0092] In some implementations, the server can also configure a query limit, visibility period, and secondary distribution restriction label for `anchor_public_ref` to prevent high-value anchor results from losing control after being consumed by multiple downstream systems. These restriction labels can also be retained long-term as part of `output_policy_ver` and support automatic expiration upon expiration.

[0093] Field dictionary, interface constraints and object layering supplement In some implementations, the fields of candidate_anchor_record can be further refined into a basic identity layer, a presence evidence layer, a stage chain layer, a history hint layer, and an output pruning layer. The basic identity layer may include at least source_type_ref, org_ref, role_ref, subject_ref, and task_or_event_ref; the presence evidence layer may include at least presence_ref, presence_quality_ref, presence_time_ref, and presence_location_ref; the stage chain layer may include at least stage_chain_ref, stage_count_ref, stage_integrity_bitmap, and closure_state_ref; the history hint layer may include at least history_hint_ref, past_dispute_rate_ref, past_review_pass_rate_ref, and abnormal_density_ref; and the output pruning layer may include at least anchor_public_ref, tier_code, status_code, attachability_ref, and expiry_ref. By layering fields, the server can perform complete internal governance and stable pruning when consumed externally.

[0094] In some implementations, the `admission_engine` and `weight_engine` interact via a `standardized_anchor_bundle`. This `standardized_anchor_bundle` can be bound to at least one or more of `candidate_anchor_record`, `admission_result_ref`, `repairable_flag`, `reject_reason_vector`, and `source_schema_ver`. This allows the `weight_engine` to perform hierarchical weighting around a unified object interface, even if the `admission_engine` uses different source thresholds in different deployment domains.

[0095] In some implementations, the lifecycle_engine and output_policy_engine collaborate via lifecycle_snapshot_ref. The lifecycle_snapshot_ref may at least include the current state, the previous state, the reason for the state transition, a weight vector summary, disclosure level labels, and the applicable output policy version. Thus, external consumer nodes consume the lifecycle snapshot results, rather than the complete underlying governance logic, reducing coupling and minimizing the exposure of sensitive underlying fields.

[0096] Comprehensive governance, source domain isolation, and diversity constraints are supplemented. In some implementations, the server does not only perform governance on a single anchor edge, but can also form batch governance objects (batch_govern_ref) around the same org_ref, role_ref, source_type_ref, or domain_profile_ref. This object can be bound to at least one or more of the following: the number of anchor edges within the batch, the batch anomaly rate, the batch revocation rate, the batch recertification success rate, and the batch diversity results. If the batch governance object shows a persistently high abnormality in a certain source domain, the system can uniformly increase the admission_threshold or decrease the base_source_weight for newly entering candidate anchor edges.

[0097] In some implementations, source domain isolation does not mean completely prohibiting cross-domain anchor participation, but rather that different source domains use different weighting coefficients when calculating `cross_anchor_consistency_bonus`. Anchors from the same closed group of institutions share a lower diversity gain, while anchors from independent groups of institutions that have not experienced long-term conflicts share a higher diversity gain. The server can explicitly record the diversity constraint rules used in a particular weighting calculation via `diversity_constraint_ref`.

[0098] In some implementations, if `batch_govern_ref` hits the batch anomaly threshold, the server can first apply the `OBSERVE` or `DOWNGRADED` initial state to all newly entering anchor edges within that batch, without immediately revoking all historical anchor edges. When subsequent `manual_review_trace` or `cross_domain_audit_ref` further confirms a systemic anomaly, the entire source domain can be switched to a `FROZEN` or `REVOKED` strongly governed state. Thus, this invention balances timely governance with control of false alarms.

[0099] Archiving, Failure Control, and Long-Term Audit Supplements In some implementations, the server retains the `archive_anchor_ref` for anchor objects that have been withdrawn, archived, or no longer involved in online scoring. The `archive_anchor_ref` can be bound to at least one or more of the following: the original `anchor_public_ref`, the final `tier_code`, the final `status_code`, the last `reason_vector_ref`, the last `transition_path_ref`, and the `archive_time_ref`. By archiving references, the system can reduce the burden of online governance and recover historical evidence in long-term dispute resolution.

[0100] In some implementations, failure control can be achieved not only through `expiry_ref`, but also through restrictions such as `view_budget_ref`, `query_count_limit_ref`, and `redistribution_limit_ref`. `view_budget_ref` limits how many callers can consume a high-value anchor within a certain time window; `query_count_limit_ref` limits repeated queries; and `redistribution_limit_ref` limits redistribution by downstream systems. The server binds these restrictions to `output_policy_ver` to ensure that controlled output remains manageable throughout its lifecycle.

[0101] In some implementations, long-term auditing does not require constant access to the complete plaintext of candidate anchor materials. The audit output channel can initially return summary objects such as `archive_anchor_ref`, `transition_digest_ref`, `reason_digest_ref`, and `version_digest_ref`. Upon explicit request from regulatory, judicial, or high-privilege compliance review bodies and with authorization granted, the server can further expose `controlled_material_index_ref` or a finer-grained material index. This reduces the risk of long-term plaintext exposure while meeting audit requirements.

[0102] Fault degradation, version compatibility and rollback supplementation In some implementations, if the source schema submitted by the source is in a transitional version, the server can first generate a compatibility warning ref instead of immediately using REJECT_HARD. If the transitional version still satisfies the minimum field set and key semantic mapping, the admission engine can provide an ACCEPT_OBSERVE or REJECT_REPAIRA Bluetooth Low Energy result and require the source to complete the upgrade in a subsequent window. This mechanism enables the system to maintain continuous governance during version migration.

[0103] In some implementations, if `weight_rule_ver` or `lifecycle_rule_ver` is upgraded, the server does not directly write back the historical state. Instead, it generates `rollback_safe_ref` or `migration_map_ref`. `rollback_safe_ref` identifies whether a historical result can be directly reused in the new version; `migration_map_ref` records how the old weight components or cause vectors are mapped to the new version. Thus, the system can maintain the continuity of governance interpretation across multiple rounds of rule upgrades.

[0104] In some implementations, fault degradation can also be reflected in the degradation of `output_policy_engine`. When a low-priority external channel becomes unavailable, the server can only return a simplified status code and `tier_code` without blocking the main governance link; when the audit output channel becomes unavailable, the server can first cache `lifecycle_snapshot_ref` and asynchronously rewrite it after the channel is restored. This design ensures that the invention remains maintainable in complex distributed deployment environments.

[0105] Supplementary Boundary Scenarios and Extended Cases In some implementations, the first boundary scenario is "the source is stable for a long time, but the critical end stage of a single task's stage_chain_ref is missing." In this case, the server provides ACCEPT_OBSERVE or REJECT_REPAIRA Bluetooth Low Energy instead of directly setting ACCEPT_HIGH due to source stability. The second boundary scenario is "a role's role_ref has a history of anomalies, but the organization's recent rectification performance is excellent." In this case, the system can retain both role_penalty_ref and org_recover_bonus_ref, reflecting a cautious but recoverable governance logic in the initial weighting.

[0106] Scenario 3 is when "multiple anchor edges are consistent, but all come from a single closed ecosystem." In this case, the server can reduce `cross_anchor_consistency_bonus` through `diversity_constraint_ref` to prevent self-reinforcement within the closed ecosystem. Scenario 4 is when "a high-level anchor is no longer suitable for strong support due to changes in external rules, but still has background material value." In this case, the system can adjust `attachability_ref` from `STRONG_SUPPORT` to `BACKGROUND_ONLY` instead of directly revoking it. This demonstrates that controlled third-party anchor governance does not only have two extreme outcomes: acceptance or rejection.

[0107] In some implementations, Extended Case 1 addresses the conflict between audit review anchors and abnormal event audit anchors. The server can increase the interpretation weight of `manual_review_bonus` and perform fine-grained splitting of `conflict_reason_vector`, rather than simply suppressing one side based on source type. Extended Case 2 addresses the issue of "Organization A reapplying for activation after rectification, but another source within the same organization continues to be abnormal." The system can allow only certain source types to enter LIMITED_REENA Bluetooth Low Energy, rather than allowing the entire organization to fully recover. Therefore, this invention supports fine-grained recovery and hierarchical governance within the source domain.

[0108] Parameter matrix and end-to-end tracing supplement In some implementations, the server can further maintain the following parameter matrices: 1. `admission_threshold_matrix`, used to map different `source_type_ref` and different `org_ref` risk profiles to different admission thresholds; 2. `weight_cap_matrix`, used to control the weight cap of different `tier_code`s; 3. `diversity_matrix`, used to control the gain difference between intra-domain and inter-domain anchors; 4. `lifecycle_matrix`, used to control the state transition threshold from `OBSERVE`, `DOWNGRADED`, `FROZEN` to `REACTIVATED`; 5. `archive_matrix`, used to control the retention time and query budget of different `anchor_public_ref`s. Through matrix configuration, governance rules are no longer scattered across different modules, but can form an auditable and transferable unified parameter domain.

[0109] In some implementations, the system can also maintain a full-link tracing chain `trace_chain_ref` around the same `anchor_public_ref`. This tracing chain can concatenate at least one or more of `candidate_anchor_record`, `admission_result_ref`, `weight_vector_ref`, `transition_path_ref`, `attachability_ref`, `archive_anchor_ref`, and `replay_result_ref`. In this way, external high-privilege review entities can not only see the current result of a single anchor, but also understand the complete historical trajectory of that anchor from reception, admission, weighting, state transition, archiving to replay.

[0110] In some implementations, if an anchor edge undergoes multiple stages during long-term governance, including ACCEPT_HIGH, DOWNGRADED, FROZEN, LIMITED_REENA Bluetooth Low Energy, and REACTIVATED, the server synchronously attaches the key version_digest_ref, reason_digest_ref, and domain_profile_ref for each stage to the trace_chain_ref. Therefore, this invention not only supports static auditing but also "stage-based explanation," that is, explaining why an anchor edge exhibits different levels and attachmentability_refs at different points in time.

[0111] Supplementary Examples of Operation and Maintenance Audits In one implementation, an example of an operations and maintenance audit is "a large number of ACCEPT_OBSERVEs appearing after a version upgrade of a certain source domain". In this case, the server can use `source_schema_ver` and `migration_map_ref` to determine whether the problem stems from incomplete fields on the source side, changes in role mapping rules, or an overly strict new threshold in `admission_threshold_matrix`. The operations and maintenance team can quickly pinpoint the source of the problem without having to review each candidate anchor individually.

[0112] The second example of an operations and maintenance audit is "a high-end anchor being excessively queried in an external consumption system." In this case, the server can determine whether to prematurely invalidate the `expiry_ref`, or simply reduce `attachability_ref` while retaining `archive_anchor_ref`, based on `view_budget_ref`, `query_count_limit_ref`, and `redistribution_limit_ref`. This example illustrates that this invention incorporates "controlled consumption" itself into the governance chain.

[0113] Example 3 of the operation and maintenance audit is "An organization was found to have successfully completed partial rectification but not full-domain restoration". The server can generate LIMITED_REENA low-power Bluetooth only for the subdomains that pass manual_review_trace, while keeping other subdomains DOWNGRADED or FROZEN. Thus, the governance granularity of this invention can be refined not only to a single anchor, but also to different roles, different task lines and different deployment subdomains within the source domain.

[0114] in conclusion This invention standardizes and unifies highly trusted witness records formed by different controlled third-party nodes into candidate anchor objects, and implements admission classification, weight vector allocation, lifecycle state migration, controlled public reference output, and audit replay traceability on the server side. It establishes a controlled third-party trust anchor governance framework that can be reused across scenarios, which can effectively improve the trust judgment capability, anomaly management capability, audit interpretability, and data protection capability in complex multi-party scenarios.

Claims

1. A method for trustworthy admission, dynamic weight allocation, and resource scheduling governance of heterogeneous nodes, characterized in that, The process is executed collaboratively by a controlled third-party node and a server. The controlled third-party node performs summary extraction, on-site evidence encapsulation, and integrity binding on the original witnessing materials generated during service process witnessing, abnormal event witnessing, site verification, status review, or audit review, forming candidate anchor edge records and sending them to the server. The server standardizes these candidate anchor edge records into candidate anchor objects. Each candidate anchor object includes at least two or more of the following: source type reference, institution identity reference, role / permission reference, subject reference, task or event reference, on-site evidence reference, stage chain reference, idempotent reference, integrity reference, and rule version reference. The method includes: processing the candidate anchor edge records... The anchor selection process performs source legality checks, field completeness checks, institution and role mapping checks, subject binding consistency checks, presence evidence sufficiency checks, stage chain minimum closure condition checks, and version compatibility checks on the selected anchor objects. Based on the check results, candidate anchor objects are classified into one of the following categories: high admission, medium admission, observation admission, rejection with supplementary evidence, or hard rejection. Controlled anchor edge public references and corresponding registration records are generated for the high admission, medium admission, or observation admission candidate anchor objects. Based on one or more of the following factors—source base weight, institution stability weight, role stability weight, presence evidence quality weight, stage chain completeness weight, historical anomaly penalty item, and cross-anchor consistency gain item—the selected anchor objects are assigned a specific value. The registration record generates trust levels and weight vectors; when the candidate anchor object or the abnormal event, state recovery or controlled review result associated with the candidate anchor object hits one or more of the following: evidence consistency anomaly, abnormal pattern hit result, node collusion association result, historical false alarm correction result or governance rule hit result, a risk disposal object is generated, which includes at least one or more of the following: risk level reference, disposal suggestion reference, cause vector reference, recovery threshold reference, and freeze scope reference. Then, one of the following is performed on the corresponding registration record: communication concurrency priority adjustment, database write quota adjustment, weight vector downgrade, observation period extension, access qualification suspension, transfer to review, or restoration to normal status. One or more types; enabling the registration record to perform state transitions according to state transition rules between one or more lifecycle states such as registered, weighted, under observation, downgraded, frozen, under review, revoked, reactivated, and reactivated, and recording the state transition path reference and corresponding cause vector reference; outputting one or more of the status code, gear code, weight vector reference, parameter status code, qualification status code, cause vector reference, controlled anchor edge public reference, or risk mark corresponding to the registration record to the external calling entity, and retaining the rule version reference, state transition path reference, and controlled anchor edge public reference as governance objects that can be audited for replay or historical review.

2. A controlled third-party trust anchor registration, hierarchical authorization, and lifecycle governance system, characterized in that, The system includes a candidate anchor edge encapsulation and receiving module, an admission determination module, a hierarchical weighting module, a lifecycle governance module, and a controlled output module. The candidate anchor edge encapsulation and receiving module receives candidate anchor edge records from multiple controlled third-party nodes, which are then processed through digest extraction, on-site evidence encapsulation, and integrity binding. The admission determination module normalizes the candidate anchor edge records into candidate anchor objects and performs checks on source legality, field completeness, institution and role mapping, subject binding consistency, on-site evidence sufficiency, minimum closure condition of the stage chain, and version compatibility to output a classification result of high admission, medium admission, observation admission, rejection with supplementary evidence, or hard rejection. The hierarchical weighting module generates controlled anchor edge public rules for candidate anchor objects with high admission, medium admission, or observation admission. The system is configured to: open references, register trust levels, and assign weight vectors; generate risk disposal objects based on one or more of the following: evidence consistency anomalies, anomaly pattern hit results, node collusion association results, historical false alarm correction results, or governance rule hit results; perform one or more of the following: risk preparation resource ratio adjustment, weight vector downgrading, disposal parameter freezing, disposal parameter reduction, observation period extension, access qualification suspension, transfer to review, restoration to normal state, or lifecycle state migration; and record state transition path references and cause vector references; the controlled output module is configured to output status codes, level codes, weight vector references, parameter status codes, qualification status codes, cause vector references, controlled anchor edge public references, or risk markers to external systems; and the system is configured to execute the method described in claim 1.

3. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of claim 1.

4. The method according to claim 1, wherein the presence evidence reference includes at least one or more of the following: close-range interaction summary reference, site environment anchor reference, session establishment summary reference, task acceptance summary reference, or controlled event triggering summary reference.

5. The method of claim 1, wherein the stage chain reference includes at least a minimum set of closed stages corresponding to the source type, and the server allows the candidate anchor object to enter the high-admission or medium-admission classification only when the stage chain reference satisfies the minimum closure conditions of the start stage, key execution stage, and end stage of the corresponding source type.

6. The method according to claim 1, wherein the weight vector includes at least one or more of the following: source base weight component, institution stability weight component, role stability weight component, presence evidence quality component, stage chain integrity component, historical anomaly penalty component, and cross-anchor consistency gain component.

7. The method of claim 1, wherein the server performs deduplication, aggregation, or rejection processing on candidate anchor objects submitted in duplicate packages based on one or more of the idempotent reference, subject reference, time binning reference, stage chain reference, and anchor-edge similarity summary.

8. The method according to claim 1, wherein when one or more of the following occurs: batch anomaly, role abuse, task impersonation, cross-site conflict, duplicate anchor edge submission, duplicate recovery application, abnormal expansion of stage chain, abnormal collaborative chain, collusion edge service node, or abnormal review conclusion, the server performs one or more governance actions on the corresponding registration record: downgrading, freezing, revocation, adjustment of disposal parameters, suspension of access qualification, or transfer to review.

9. The method according to claim 1, wherein when a high risk is hit but the evidence is not yet closed, the server first performs one or more of the following on the corresponding registration record: temporary freeze, observation period extension, and pending recovery status marking. And only when one or more of the following conditions are met: the rectification evidence reference passes verification, the observation period passes, the subsequent stable record reaches the threshold, or the abnormality is resolved by manual review, the corresponding registration record is first migrated to the reactivation state, and then migrated to the reactivated state when the recovery threshold is met.

10. The method according to claim 1, wherein the controlled anchor edge public reference is one or more of irreversible reference, desensitized index or restricted mapping identifier, and the low-privilege calling subject can only read one or more of status code, gear code, risk mark, parameter status code, qualification status code or weight vector reference, while the rule version reference, status transition path reference, complete recovery threshold reference and underlying candidate anchor material are only for audit replay, historical backtesting or high-privilege review.

Images