Dynamic management system and method for property right project state labels

Abstract

The invention relates to the technical field of property right project management, in particular to a dynamic management system and method for property right project state tags. The method comprises the following steps: a data acquisition and processing unit acquires project data and preprocesses the project data; a state label system construction unit constructs a multi-level state label system by using a property right project full life cycle process based on the preprocessed project data; and the state reasoning and dynamic updating unit is used for identifying the change trend of the project state based on the multi-level state tag system by adopting a level state machine model, generating a state tag set, dynamically updating the tag set when a project business event occurs, and generating a dynamically evolved state tag set. According to the method, a hierarchical state machine model and a link correction mechanism are introduced, a label set is dynamically updated when a service event is triggered, and structure-level compensation is carried out on inference interruption caused by data missing or cross-system inconsistency.

Description

Technical Field

[0001] This invention relates to the field of property rights project management technology, and more specifically, to a dynamic management system and method for property rights project status tags. Background Technology

[0002] In current property rights transaction management practices, project status tracking and monitoring generally rely on manual entry, static process node records, or status feedback from isolated business systems, resulting in issues such as fragmented data sources, delayed updates, and semantic inconsistencies. As property rights transactions become increasingly complex, process steps become more detailed, and compliance requirements continue to rise, traditional methods of representing project progress using fixed stages or simple status fields are no longer sufficient to accurately reflect the true dynamics of a project throughout its entire lifecycle. Especially in cross-system collaborative scenarios, incomplete data collection, disordered event timing, missing materials, or compliance anomalies often lead to broken status judgment chains and interrupted tag reasoning, resulting in misjudgments of progress, missed risk reports, and even regulatory failures. Furthermore, existing systems lack structured modeling of the logical relationships between status tags (such as parent-child dependencies, mutual exclusion constraints, and priority coverage), and are unable to proactively identify and quantify potential risks. Therefore, this paper proposes a dynamic management system and method for property rights project status tags. Summary of the Invention

[0003] The purpose of this invention is to provide a dynamic management system and method for property rights project status tags, so as to solve the problems of fragmented property rights project status perception, easy interruption of tag reasoning, and delayed risk warning mentioned in the background art.

[0004] To achieve the above objectives, one objective of this invention is to provide a dynamic management system for property rights project status tags, comprising: A data acquisition and processing unit, which acquires project data and preprocesses the project data; A status label system construction unit, which constructs a multi-level status label system based on preprocessed project data and utilizing the entire lifecycle process of the property project; The state reasoning and dynamic update unit is based on a multi-level state label system and uses a hierarchical state machine model to identify the changing trend of the project state, generate a set of state labels, and dynamically update the label set when project business events occur, generating a dynamically evolving set of state labels. In the process of generating a dynamically evolving tag set, gaps in the triggering link are identified and structural compensation is performed to generate link correction trigger tags to prevent multi-level tag inference from being interrupted. An anomaly identification and risk warning unit identifies anomalies based on a dynamically evolving set of tags and generates corresponding risk warning tags for real-time monitoring of the status of the property project.

[0005] As a further improvement to this technical solution, the data acquisition and processing unit includes a data acquisition module and a data processing module; The data acquisition module collects project data, which includes basic project information, process and progress event data, and document and compliance data. The data processing module is used to preprocess the project data.

[0006] As a further improvement to this technical solution, the status label system construction unit utilizes the entire lifecycle process of a property project to construct a multi-level status label system, including the following steps: S1.1 The entire lifecycle process of the property rights project is analyzed using a process mining method based on event logs to extract the main process nodes, sub-nodes and their business logic relationships, forming a unified standard set of process nodes; S1.2. Key fields are extracted from the basic information data of the project through an automated feature extraction algorithm based on rule templates and field feature recognition, and corresponding first-level basic attribute labels are generated to describe the static attribute characteristics of the property project. The key fields include at least the project category, transaction method, and affiliated unit; S1.3. Based on the standard set of process nodes, sort the process events of the property project by timestamp and match them to the corresponding process nodes using the maximum matching algorithm. This is used to construct multi-level process tags that reflect the current progress status of the project, and to construct the generation conditions and update logic of the tags using the dependencies between nodes. S1.4 Analyze project-related documents and material management information, construct a material tag system, and at the same time construct the dependency and triggering relationship between material tags and multi-level process tags; S1.5. Based on tag attributes, business importance, and risk level, construct a multi-level tag system and define the priority relationship between tags; S1.6. Establish trigger conditions based on project data for each tag; S1.7 Construct the logical relationships between labels using Boolean logic diagrams.

[0007] As a further improvement to this technical solution, the state reasoning and dynamic update unit includes a state reasoning module and a dynamic update module; The state reasoning module performs real-time analysis of the preprocessed project data based on a multi-level state label system, and infers the set of state labels that should be generated by matching the label triggering conditions through a hierarchical state machine model. The dynamic update module dynamically updates the tag set of the project based on the state tag set output by the state reasoning module, generating the final dynamically evolving state tag set.

[0008] As a further improvement to this technical solution, the state reasoning module performs real-time parsing of the preprocessed project data based on a multi-level state label system. It infers the current set of state labels to be generated by matching label triggering conditions through a hierarchical state machine model, including the following steps: S2.1 Map the preprocessed project data to the corresponding fields in the multi-level state label system, and initialize the state of each label in the hierarchical state machine; S2.2 Analyze the parent-child relationships and dependency rules of each tag in the multi-level tag system; S2.3 For each tag, match it according to the trigger conditions built in the hierarchical state machine, and identify gaps in the trigger chain through condition chain scanning and perform structural compensation to generate a link correction trigger tag to prevent multi-level tag inference from being interrupted. S2.4. Use a hierarchical state machine model to infer the state transition of each tag, including the link correction trigger tag; S2.5. Summarize all the labels that need to be generated by the hierarchical state machine to form the current time point's state label set.

[0009] As a further improvement to this technical solution, in step S2.3, by scanning the conditional chain, gaps in the trigger link are identified and structural-level compensation is performed to generate a link correction trigger tag, including the following steps: S2.31. Parse the trigger condition chain of the tag, decompose each condition in the trigger condition chain into a structured form, and map it to the corresponding field name, data source system, value retrieval rule and current project status; S2.32. Scan the trigger condition chain sequentially, identify the condition nodes with missing fields, and form a gap set in the trigger condition chain; S2.33. For gaps in the gap set, make a compensability judgment based on the preset compensation rules; S2.34. For gaps that are determined to be compensable, perform structural-level compensation according to the gap type; S2.35 After obtaining the compensation result at the end of the structural level compensation, the compensated trigger condition chain is reassembled, and the corresponding link correction trigger tag is generated as a temporary trigger input.

[0010] As a further improvement to this technical solution, the dynamic update module dynamically updates the tag set of the project based on the state tag set output by the state reasoning module, including the following steps: S3.1 Receive the set of state labels output by the state reasoning module, and classify and sort the state labels according to item, level, and parent-child relationship; S3.2. Iterate through each received status tag and determine whether its current status conflicts with the status in the existing tag set of the project; S3.3. Perform dynamic update operations based on the judgment results, and introduce a prediction-driven adaptive tag triggering mechanism to identify the risk of future tag link interruption in advance; S3.4. Perform synchronization and dependency updates for multi-level parent-child tags, and check the dependency relationship between the parent tag state and the child tag state; S3.5 After completing the dependency check, output the final set of dynamically evolving state labels.

[0011] As a further improvement to this technical solution, S3.3 introduces a prediction-driven adaptive label triggering mechanism, including the following steps: S3.31. Collect tag trigger sequences, link gaps, and link correction records from historical projects, and construct a tag trigger sequence diagram; S3.32. Based on the current project's state label set, a lightweight graph neural network is used to fuse the state label dependency structure, and a time series model is combined to predict future triggered label links, outputting the predicted trigger probability of each label to be triggered. ; S3.33, Predicting the trigger probability Tags exceeding a preset threshold 'a' are generated as predictive link trigger tags and added to the tag set in advance as temporary trigger inputs; S3.34. Integrate the predictive link triggering tags into the tag set, and perform incremental state adjustment and update on the state tag set according to the tag priority relationship and parent-child dependency rules to form a complete dynamic evolution state tag set.

[0012] As a further improvement to this technical solution, the anomaly identification and risk warning unit includes an anomaly identification module and a risk warning module; The anomaly identification module identifies abnormal states in the operation of the property project based on a dynamically evolving set of state labels, using rule matching algorithms and time-series deviation detection algorithms. The risk warning module, based on the anomaly identification results and combined with the adaptive risk scoring model, performs multi-dimensional quantitative assessment of the project's schedule risk, compliance risk, and circulation risk, and issues warnings based on the multi-dimensional quantitative assessment results.

[0013] On the other hand, the present invention provides a dynamic management method for property status tags. Based on the aforementioned dynamic management system for property status tags, the method includes the following steps: S4.1 Collect project data and preprocess the project data; S4.2. Based on the preprocessed project data, utilize the entire lifecycle process of the property project to construct a multi-level status label system; S4.3. Based on a multi-level state label system, a hierarchical state machine model is used to identify the changing trend of project state, generate a set of state labels, and dynamically update the label set when project business events occur, generating a dynamically evolving set of state labels. In the process of generating a dynamically evolving tag set, gaps in the triggering link are identified and structural compensation is performed to generate link correction trigger tags to prevent multi-level tag inference from being interrupted. S4.4. Based on the dynamically evolving tag set, anomaly identification is performed, and corresponding risk warning tags are generated for real-time monitoring of the status of property projects.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. The dynamic management system and method for property project status labels involved in this invention integrates multi-dimensional project data from property transaction platforms, business processing systems, and document management systems, and combines process mining, rule template extraction, and material compliance analysis to construct a multi-level status label system covering basic attributes, process progress, and material compliance. Simultaneously, a hierarchical state machine model and link correction mechanism are introduced to dynamically update the label set when business events are triggered, and structural compensation is provided for inference interruptions caused by data loss or cross-system inconsistencies. This ensures that status labels can continuously and accurately reflect the true status of the project even in complex business scenarios, effectively solving the problem that traditional static label systems are difficult to adapt to dynamic process changes.

[0015] 2. The dynamic management system and method for property rights project status tags involved in this invention, based on a dynamically evolving set of status tags, comprehensively utilizes rule matching and time-series deviation detection algorithms to identify abnormal states, and quantitatively assesses multi-dimensional risks such as progress, compliance, and transfer through an adaptive risk scoring model; further, it combines graph neural networks and time series prediction technology to introduce a prediction-driven adaptive tag triggering mechanism, generating predictive tags with high probability of triggering in advance, thereby initiating early warning responses before risks become apparent. This mechanism not only improves the sensitivity and coverage of risk identification, but also supports the shift from a "post-event handling" to a "pre-event prevention" regulatory model, significantly enhancing the controllability and security of the property rights transaction process. Attached Figure Description

[0016] Figure 1 This is an overall flowchart of the present invention; The meanings of the labels in the diagram are as follows: 1. Data acquisition and processing unit; 2. Status tag system construction unit; 3. Status reasoning and dynamic update unit; 4. Anomaly identification and risk warning unit. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1: Please refer to Figure 1 As shown, a dynamic management system for property rights project status tags is provided, including: Data acquisition and processing unit 1 acquires project data and preprocesses the project data; In this embodiment, the data acquisition and processing unit 1 includes a data acquisition module and a data processing module; The data acquisition module collects project data from the property rights trading platform, business processing system and document management system respectively. The project data includes basic project information data, process and progress event data, and document and compliance data. The data processing module is used to preprocess project data, including field validation, format standardization, event timestamp alignment, material label mapping, and node status standardization.

[0019] Unit 2 of the status label system construction unit constructs a multi-level status label system based on the preprocessed project data and the entire life cycle process of the property project. In this embodiment, the status label system construction unit 2 utilizes the entire lifecycle process of the property rights project to construct a multi-level status label system, including the following steps: S1.1. The entire lifecycle of a property rights project, from project registration, announcement, application review, transaction organization, result confirmation to contract archiving, is analyzed using a process mining method based on event logs. This extracts key process nodes, sub-nodes, and their business logic relationships, forming a unified set of process node standards. Specifically, the process mining method based on event logs preprocesses project event logs from the property rights transaction platform and business processing system, including event denoising, timestamp sorting, and node identifier standardization. Then, the DFG (Dependent Frontier Group) algorithm is used to analyze the dependency relationships of the event sequences, automatically identifying the key process nodes and their sub-nodes at each stage from project registration, announcement, application review, transaction organization, result confirmation to contract archiving. Next, based on the direct following relationships, loop structures, branch structures, and parallel structures between events, the input conditions, output conditions, and dependency logic of each node are extracted. Finally, the mined flowcharts undergo consistency verification and structured reconstruction to generate a unified set of process node standards for subsequent multi-level tagging system construction. S1.2 Key fields are extracted from the project's basic information data using an automated feature extraction algorithm based on rule templates and field feature recognition, and corresponding first-level basic attribute labels are generated to describe the static attribute characteristics of the property rights project (this label layer serves as a basic supplement to the dynamic process labels, supporting subsequent label condition judgment and filtering); specifically: the project's basic information data is first standardized using an automated feature extraction algorithm based on rule templates and field feature recognition, including field name normalization, value format validation, and missing value completion; then, the input data is processed according to a preset data dictionary and rule template (including field type rules, value range rules, and key field matching rules). The incoming data is scanned item by item, and key fields such as project category, transaction method, and affiliated unit are automatically identified using field feature recognition algorithms. For cases with synonymous fields or conflicting fields from multiple systems, field mapping and priority alignment are performed. After the key fields are identified, each key field is mapped to generate corresponding primary basic attribute tags based on the tag definition table (e.g., project category_equity transfer, transaction method_public bidding, affiliated unit_provincial state-owned assets supervision and administration commission, project status_in progress). Fields that do not meet the conditions are marked as null value tags or tags to be completed. Finally, the generated primary basic attribute tags are structured and encapsulated and written into the tag system to provide basic attribute support for the subsequent determination of process tags and material tags. The key fields include at least the project category, transaction method, and affiliated unit; S1.3. Based on the standard set of process nodes, sort the process events of the property project by timestamp and match them to the corresponding process nodes using the maximum matching algorithm (such as Hungarian matching) to construct multi-level process tags that reflect the current progress status of the project, and use the dependencies between nodes to construct the generation conditions and update logic of the tags. Multi-level process tags include: process stage tags (such as due diligence, assessment filing, listing announcement, and application for registration); node status tags (such as due diligence completed, assessment report filed, and application deadline pending review). Specifically, the collected cross-system process events are first normalized and denoised (time zone difference correction, duplicate / invalid events removed), and then sorted in ascending order of timestamp. For each event and possible candidate nodes in the standard set of process nodes, an event-node matching cost matrix is ​​constructed based on event type, event attribute similarity (field name / field value matching degree), the characteristics of the preceding and following event sequences within the context window, and the node's expected time window. (The cost of each dimension in the event-node matching cost matrix is ​​combined linearly to form the total cost (and the cost of each dimension in the event-node matching cost matrix has been normalized, transforming the cost of each dimension to the [0,1] interval): that is, the field feature similarity cost, timestamp deviation cost, process sequence position deviation cost, and essential field satisfaction cost are multiplied by a preset weight coefficient (determined according to business importance and experience), and then summed to obtain the total matching cost corresponding to the event and node. The smaller the total cost, the better the matching. The entire matrix is ​​composed of the total cost of all events and nodes. (Input for the maximum matching algorithm); For each time window, the maximum matching algorithm (e.g., the Hungarian algorithm) is called to solve for the optimal one-to-one match on the cost matrix, resulting in the allocation scheme of events to process nodes; For events that are not allocated or have excessively high costs, a threshold judgment is applied, and they are marked as "unmatched events" or candidate mappings and recorded for subsequent manual / rule correction; The matching results are written to the node execution log of the process instance and the current status of each node (e.g., not arrived / in progress / completed / timed out) is calculated based on the node's predecessor / successor dependencies (read from the dependency graph of the process node standard set); Based on these node statuses, corresponding multi-level process labels (process stage labels, node status labels) are generated; At the same time, the triggering rules for automatically generating and updating labels are based on the dependency graph (when all predecessor nodes are completed and the material category label meets the entry conditions, the next stage label is triggered; if the node times out, the time status label is triggered and the risk category label is upgraded), and the label generation rules and versioned matching mappings are persisted together to support backtracking and correction; S1.4 Analyze project-related documents and material management information (at least including submission status, completeness of material list, compliance review results, and material change records) to construct a material tagging system, including: material completeness tags (e.g., complete materials, missing materials, inconsistent materials), compliance tags (e.g., compliance passed, compliance pending, compliance rejected), and risk material tags (e.g., missing key materials, overdue materials not submitted), such as complete due diligence report, compliant asset appraisal report, publicly announced employee resettlement party, and complete transferor resolution. Simultaneously, establish the dependency and triggering relationships between material tags and multi-level process tags. For example: incomplete materials prevent entry into the next process node; compliance rejection triggers process node status rollback; risk materials automatically increase the priority of risk status tags. Specifically: first, perform structured analysis of project-related documents and material management information, including... OCR technology is used to identify scanned document content, parse electronic form fields, extract submission status, completeness of material lists, compliance review results, and material change records. Then, based on material type, submission status, and compliance rule base, a rule engine generates material completeness tags (e.g., complete, missing, inconsistent), compliance tags (e.g., compliance passed, pending review, rejected), and risk material tags (e.g., missing key materials, overdue submission). Building on this, and considering the dependencies of multi-level process tags, each material tag is associated with the triggering conditions of the corresponding process node: for example, incomplete materials prevent entry into the next process stage, compliance rejection triggers process node rollback, and risk materials automatically increase the risk level of the relevant process or time status tag. Finally, the dependencies and triggering relationships between material tags and multi-level process tags are structured and stored for subsequent status reasoning and dynamic updates. S1.5. Based on tag attributes, business importance, and risk level, construct a multi-level tag system including first-level, second-level, and third-level tags, and define the priority relationships between tags (tags include material-related tags and multi-level process tags), including: the hierarchical relationship between tags, the mutual exclusion relationship between tags (e.g., "approved" and "returned" cannot exist simultaneously), and the priority coverage rules for risk tags (e.g., risk tags prioritize covering normal tags); specifically, classify all basic attribute tags, process tags, and material-related tags according to tag attributes (e.g., category, function, data source), business importance (e.g., key nodes in the process, approval...). The system quantifies and scores tags based on their priority and risk level (low, medium, high), constructing tag feature vectors. Then, a hierarchical clustering algorithm is used to divide the tags into first, second, and third levels, and tags within each level are sorted according to their scores and business priorities. Simultaneously, a rule engine analyzes the mutual exclusion, coverage, and parent-child dependencies between tags to establish a tag priority matrix, used to determine conflict resolution strategies and priority coverage rules during state reasoning and dynamic updates. Finally, the multi-level tag system and its priority rules are structured and stored, realizing a tag management system that can be automatically parsed, computed, and executed. The construction of the tag feature vector is as follows: First, extract tag attribute features for each tag, including category codes (such as basic attributes, processes, materials), functional categories (such as descriptions, statuses, risks), and data source system identifiers, and map them into discrete or continuous numerical vectors; at the same time, quantify and score the importance of the tags according to the business rule base, such as assigning higher weights to key process nodes or high-priority approval nodes; then, encode the tag risk attributes into numerical values ​​(such as low=1, medium=2, high=3) according to the risk level; combine the attribute features, business importance scores, and risk levels into a unified tag feature vector, and ensure comparability across dimensions through normalization processing, and store it in the tag feature matrix to provide calculable input for subsequent hierarchical clustering, multi-level tag division, and priority determination; S1.6. Establish trigger conditions based on project data for each tag, including: data field conditions (such as whether a field is valid or has changed), event conditions (such as node status update or review behavior), and time conditions (such as whether timeout or the deadline for supplementary submission has been exceeded). Define state machine transition rules for tag generation, updating, upgrading, downgrading, and invalidation. For example, when the "Asset Appraisal Report" is uploaded and approved, the tag node "Appraisal Report Has Been Filed" is triggered; when the listing announcement has been published for 20 working days and the number of applicants is ≥2, the tag node "Application Deadline Pending Review" is triggered. S1.7 Construct logical relationships between labels using Boolean logic diagrams, including: interlocking of normal and risk labels (normal progress labels should be blocked after a risk label is triggered), the collaborative relationship between process labels and material labels (if materials are not completed at a certain stage, the next process label is prohibited), and composite states corresponding to multiple label combinations (e.g., the registration stage and missing materials represent an incomplete registration state). Specifically, the process is as follows: First, each label in the multi-level label system is treated as a node in the Boolean logic graph. Logical edges are defined based on the parent-child, mutual exclusion, and dependency relationships between labels. Parent-child dependencies are represented by "child label trigger → parent label state update", mutual exclusion is represented by the "¬" logical symbol to indicate that conflict is prohibited from triggering, and composite state relationships are represented by "AND / OR" logical connections to indicate multi-label combination conditions. Then, a computable logical expression is generated for each logical edge, and logical consistency is verified by a logical evaluation engine (such as a Boolean expression parser) to identify potential conflicts or circular dependencies. Finally, the Boolean logic graph and its logical expression are stored as a structured rule base so that the state reasoning module can perform label trigger determination and composite state generation when parsing project data in real time.

[0020] The State Reasoning and Dynamic Update Unit 3 uses a hierarchical state machine model based on a multi-level state label system to identify the changing trend of the project state, generate a set of state labels, and dynamically update the label set when project business events occur, generating a dynamically evolving set of state labels. In the process of generating a dynamically evolving tag set, gaps in the triggering link are identified and structural compensation is performed to generate link correction trigger tags to prevent multi-level tag inference from being interrupted. In this embodiment, the state reasoning and dynamic update unit 3 includes a state reasoning module and a dynamic update module; The state reasoning module performs real-time analysis of the preprocessed project data based on a multi-level state label system, and infers the set of state labels that should be generated by matching the label triggering conditions through a hierarchical state machine model. The dynamic update module dynamically updates the tag set of the project based on the state tag set output by the state reasoning module, generating the final dynamically evolving state tag set. The state reasoning module performs real-time parsing of preprocessed project data based on a multi-level state label system. It matches label triggering conditions using a hierarchical state machine model to infer the set of state labels that should be generated, including the following steps: S2.1 Map the preprocessed project data to the corresponding fields or nodes in the multi-level state label system, and initialize the label states in the hierarchical state machine, including the first-level label, second-level label and third-level label states as "not triggered" or the previously stored state, to provide initial conditions for subsequent label inference. S2.2, Analyze the parent-child relationships and dependency rules of each tag in the multi-level tag system: when the parent tag state is not triggered, its child tags are temporarily not generated; changes in the child tag state may trigger an update of the parent tag state; mutually exclusive or overriding tags are marked to facilitate conflict resolution; specifically: first, extract the hierarchical attributes, category, and dependency conditions of each tag in the multi-level tag system, and use the parent-child relationship rule library to divide the tags into parent tags and child tags according to business process logic and material dependencies (the parent-child relationship rule library collects the entire life cycle process of the property project, material dependencies, and business node logic, and defines the parent tag, child tag, and triggering conditions of each tag in a structured way, and stores them in the form of rule tables or databases; each record in the rule library includes the parent tag identifier, child tag identifier, and triggering condition type ( The system includes data types (field-based, event-based, time-based), dependency constraints (interlocking, coverage, order requirements), and priority information, while providing interfaces for dynamic querying and updating to support the state reasoning module in synchronizing parent and child states, determining dependency constraints, and resolving conflicts during multi-level tag triggering. Then, based on a dependency graph construction algorithm, each tag is treated as a node, and parent-child dependencies are connected by directed edges. The triggering conditions, mutual exclusion relationships, and priority information of each node are marked. On this basis, consistency checks are performed on each dependency edge, including circular dependency detection, condition coverage verification, and interlock constraint determination, ensuring the integrity and conflict-free nature of parent-child relationships and dependency rules. Finally, the constructed parent-child dependency graph is stored as structured data for the state reasoning module to perform parent-child state synchronization and dependency constraint determination when matching tag triggering conditions. S2.3 For each tag, match it according to the trigger conditions built in the hierarchical state machine: data field type conditions: determine whether the basic information fields meet the generation conditions; event type conditions: detect the status of process nodes and the occurrence of events; time type conditions: determine whether the node has timed out and whether the material has exceeded the submission deadline; at the same time, consider the status of parent and child tags, tag interlocking and priority to ensure that the tag generation conforms to the multi-level logic, and through condition chain scanning, identify gaps in the trigger chain and perform structural compensation to generate link correction trigger tags to prevent the multi-level tag reasoning from being interrupted; This invention addresses the issue of interrupted tag inference chains in property project status management caused by cross-system data gaps, conflicts, or temporal misalignments, primarily through conditional chain scanning to identify gaps in the triggering chain and perform structural compensation. In complex multi-system collaborative environments, the triggering conditions for key tags may be scattered across different platforms. If a condition (such as missing audit event records, misaligned timestamps, or conflicting field formats in a system) is not met, the entire multi-level tag inference chain will stall, preventing the system from accurately and consistently reflecting the latest project status. This mechanism, through automated conditional chain scanning, gap identification, and structured compensation, aims to ensure the continuous and stable operation of the status inference engine even with imperfect data. Traditional systems often directly report errors or wait for manual repair when encountering data gaps, leading to monitoring stagnation and missed risk reports. This invention automatically generates "link correction trigger tags" as temporary input through preset compensation rules (such as proxy field mapping and temporal interpolation). This not only prevents inference interruptions and ensures the continuity of status evolution but also explicitly records the source, method, and validity period of all compensation operations, providing clear traceability for subsequent data completion and verification. This is equivalent to giving the state management system the ability of "adaptive filling" and "resilient extrapolation", which significantly improves the system's robustness, real-time performance and practicality in real-world environments with incomplete data. By scanning the conditional chain, identifying gaps in the triggering link and performing structural-level compensation, a link correction trigger tag is generated, including the following steps: S2.31. Parse the trigger condition chain of the tag (the tag here is the specific tag object that needs to be determined whether to generate or update in this round of state reasoning. The trigger condition chain includes at least data fields, events, and time nodes). Decompose each condition in the trigger condition chain into a structured form and map it to the corresponding field name, data source system, value rules, and current project status to provide a clear and computable input structure for subsequent link scanning. Specifically, scan the trigger condition chain of the tag to be parsed item by item and classify each condition according to the condition type (data field type, event type, time type). Subsequently, a condition parser is used to decompose the conditional expressions into standardized structures, including conditional fields, operators, thresholds, or expected states, and extract their corresponding data source systems and field names. For event-type conditions, the event trigger type, the process node to which they belong, and the occurrence time are further parsed. At the same time, each condition is associated with the current project status, including node execution status, material submission status, and historical change records. Finally, the decomposed structured conditions are encapsulated into a unified data structure to form a computable and comparable trigger condition mapping table, providing clear and executable input for subsequent conditional chain scanning and structure-level compensation. The trigger condition chain refers to an ordered set of preconditions used to determine whether a tag is generated or updated. These conditions may involve whether data field values ​​meet specific rules, whether process events occur, whether time constraints are met, etc., and are arranged according to logical dependencies (such as sequential order, parent-child dependency, interlocking, or compound conditions) to form a complete determination path from the initial state to the triggering of the target tag. In a multi-level tag system, the trigger condition chain can span multiple systems and nodes to ensure that tag generation conforms to business logic and can be sequentially verified during state reasoning. S2.32. Scan the trigger condition chain sequentially to identify condition nodes with missing fields, cross-source conflicts, or misaligned timing, forming a gap set in the trigger condition chain. Specifically, sort the structured trigger condition chain according to the definition order and traverse each condition node in turn. During the traversal, check the existence of fields or whether the values ​​are empty for data field-type conditions, verify whether the event has occurred or been recorded in the corresponding system for event-type conditions, and determine whether the timestamp of the node falls within the expected time window for time-type conditions. At the same time, for cross-system or cross-source conditions, check whether the field naming, value format, and time base are consistent, and identify possible conflicts or misalignment issues. For each condition node that cannot be satisfied or has an anomaly, mark its type (missing, cross-source conflict, misaligned timing) and record relevant metadata (such as field name, source system, expected value / time). Finally, summarize to form a gap set in the trigger condition chain, providing input basis for subsequent structural compensation. S2.33. For gaps in the gap set, a compensability judgment is made based on preset compensation rules, including whether the preconditions are complete, whether there are substitute surrogate fields, whether cross-source data has alignment space, and whether the time sequence relationship allows interpolation or inference, to determine whether the gap can be compensated at the structural level. Specifically, for the gap set identified in the trigger condition chain, each gap node is traversed sequentially, and a compensability judgment is made according to the preset compensation rules: First, check whether the preconditions of the gap are complete, that is, whether its dependent parent node or antecedent conditions have been met; second, determine whether there are substitute fields or surrogate data that can be used to fill the missing information; third, verify whether the cross-source data has alignment, including whether the field type, unit and time base are consistent; at the same time, evaluate whether the time sequence relationship allows interpolation or inference to fill the misaligned time nodes; if all the above conditions are met, the gap is determined to be compensable, otherwise it is marked as an uncompensable gap, and the reasons for the uncompensable gap and the scope of impact are recorded to provide a basis for subsequent structural compensation or manual intervention. Among them, the preset compensation rules summarize common gap types and business logic constraints in the multi-level tag system, and define compensation strategies for situations such as missing fields, cross-source conflicts and misaligned time sequences. These include rules for judging the completeness of preconditions, rules for mapping proxy fields, rules for cross-source data alignment, rules for time window interpolation or inference, and rules for anomaly marking and recording. Each rule contains information on the applicable gap type, triggering conditions, compensation method and priority, and is stored in a structured table or a rule engine executable format, so that the state reasoning module can automatically determine the compensability of gaps and guide the structural compensation operation during link scanning. S2.34. For gaps that are determined to be compensable, perform structural-level compensation according to the gap type; The gap types include: Field missing type: the required data field in the triggering condition chain does not exist or is empty in the current project data; Cross-system data conflict type: the same data field has inconsistent values ​​in different source systems; Time sequence misalignment type: the timestamp of the process event deviates from the expected time window by more than the set threshold b (in this embodiment, the threshold b is set according to the sensitivity of the business process and the data collection frequency, and the value range can be 1 to 3 days. For example, if the threshold b is set to 2 days, the timestamp deviation is determined to be time sequence misalignment if it exceeds 2 days); Data format incompatibility type: the field value format does not match the preset rule template. The compensation methods are as follows, depending on the type of gap: For fields with missing information, proxy field mapping compensation is performed, which involves filling in data based on historical project data of the same category or preset default values. For cross-system data conflict types, field priority alignment compensation is performed, which involves selecting the optimal field value according to preset system priorities. For time sequence misalignment types, time window interpolation compensation is performed, which involves time correction based on the event sequence of adjacent timestamps. For data format incompatibility types, format conversion compensation is performed, which involves converting the data to a standard format according to preset format mapping rules. During the compensation process, the source, method, execution time, and applicable conditions of the compensation are recorded, and the generated results are verified. S2.35. After obtaining the compensation result at the end of the structural level compensation, the compensated trigger condition chain is reassembled, and a corresponding link correction trigger label is generated as a temporary trigger input to prevent the inference link from being interrupted. Specifically, after the structural level compensation is completed, all compensated condition nodes are first reordered according to the original trigger condition chain order, and the logical dependencies and temporal continuity between nodes are verified. Then, the compensation source, validity period and applicable scope are marked for each compensated condition node in the link, and the entire link is encapsulated into a unified data structure. Next, a corresponding link correction trigger label is generated according to the link triggering rules, its status is marked as "temporary trigger", and it is added to the current label set as the input of the state inference module to ensure that the trigger link is not interrupted during the multi-level label inference process, and the meta-information for subsequent verification and dynamic updates is recorded. Specifically: When the key field "debt-to-asset ratio" is missing during the due diligence phase, preventing the "due diligence completed" milestone from being triggered, the system first identifies the missing link by scanning the trigger condition chain. Based on the compensation rules, a compensability assessment is performed to determine if statistical characteristics from similar historical projects can be used to fill the gap. Then, a debt-to-asset ratio sample is extracted from historical projects of similar size and industry scale, and the average value is calculated as a proxy field for structural-level compensation. After compensation, the system reassembles the trigger condition chain and generates a "compensated debt-to-asset ratio proxy calculation" link correction trigger label, enabling the "due diligence completed" milestone to be triggered normally. Simultaneously, the milestone is marked as "includes compensated data." S2.4. Use a hierarchical state machine model to infer the state transitions of each tag, including the link correction trigger tag: when the triggering condition is met and there is no conflict, the tag state is updated from "not triggered" to "triggered"; when the upper-level tag does not meet the condition, the sub-tag is temporarily suspended; conflicting tags select the priority tag according to priority or interlocking rules; for time-sensitive tags, perform timeout judgment and update to "abnormal" or "pending processing"; specifically: initialize the multi-level tags and link correction trigger tags in the hierarchical state machine to "not triggered" or the previous stored state, and define a state set (such as "not triggered", "triggered", "temporary triggered", "abnormal", "failed") and state transition rules for each tag; then traverse each tag, according to its The system determines whether trigger conditions are met based on trigger condition type (data field type, event type, time type), parent-child dependency relationship, mutual exclusion, and priority constraints. For tags that meet the conditions and have no conflicts, the status is updated from untriggered to triggered. For child tags, triggering is temporarily suspended if the parent tag does not meet the conditions. At the same time, link correction trigger tags are temporarily marked according to the compensation source and validity period. During the status update process, time-out tags are determined using a time window and updated to an abnormal or pending status. Finally, the status of all tags is iteratively updated through a state machine to form a complete status transition result including link correction trigger tags, providing a real-time and computable set of status tags for the dynamic update module. S2.5. Summarize all tags that need to be generated or updated according to the hierarchical state machine to form the current time point's state tag set.

[0021] Furthermore, the dynamic update module dynamically updates the item's tag set based on the state tag set output by the state reasoning module, including the following steps: S3.1 Receive the set of status tags output by the status inference module, including normal trigger tags and link correction trigger tags, and classify and sort the status tags according to items, levels, and parent-child relationships to provide an initial data structure for subsequent dynamic updates; S3.2. Traverse each received status tag and determine whether its current status conflicts with the status in the project's existing tag set. During the traversal, check whether the tag already exists in the project's existing tag set. If it does, compare the status to determine if it is a duplicate tag. At the same time, based on the tag priority matrix and mutual exclusion rules, identify potentially conflicting tags (such as mutually exclusive tags triggering simultaneously or priority overriding conflicts). For time-sensitive tags, determine whether their trigger time or validity period conflicts with existing tags. For each type of conflict, record the conflict type and the tags involved, and mark the tag as a state that needs to be updated, merged, or temporarily retained, providing a decision-making basis for subsequent dynamic update operations. S3.3. Perform dynamic update operations based on the judgment results: For newly triggered tags, add them to the project tag set and update the status of relevant parent tags or trigger child tag checks according to parent-child dependency relationships; for link correction triggered tags, mark them as temporary states and add them to the set, while recording the compensation source, validity period, and verification strategy; for existing tags, perform state overwrite or retention according to the priority matrix and interlocking rules, and synchronously update the timestamp and version information; during the update process, perform dependency checks on multi-level parent-child tags to ensure that the status of parent tags and child tags is consistent, and introduce a prediction-driven adaptive tag triggering mechanism to generate predictive link tags that may be triggered in advance; finally, complete the status update of all tags to form a dynamically evolved tag set after conflict resolution, dependency synchronization, and prediction optimization, and introduce a prediction-driven adaptive tag triggering mechanism to identify the risk of future tag link interruption in advance; The prediction-driven adaptive tag triggering mechanism primarily addresses the monitoring lag and response delay issues in property project status management caused by potential future interruptions in dependency links. In the dynamic evolution of multi-level tags, traditional systems only trigger tag updates after an event occurs. When key preconditions (such as an approval node) fail to be met in time due to data delays, process congestion, or unavailable resources, downstream tag triggering links are forced to wait, causing system status reflection to lag behind actual business progress and hindering proactive risk control. The prediction-driven mechanism, by analyzing historical patterns and current status, aims to proactively identify and fill potential future link gaps, ensuring continuity and lead time in status monitoring. Traditional status management is passively responsive, only updating tags after an event occurs or conditions are met, lacking foresight. This mechanism, by integrating graph neural networks and time series models, jointly learns historical tag triggering patterns and the current project dependency structure to proactively predict high-probability future triggering tags and their links, and generates "predictive link triggering tags" as temporary placeholders to add to the system. This not only maintains the integrity of parent-child dependencies in advance, avoiding monitoring blind spots caused by link interruptions, but also dynamically optimizes the prediction model through subsequent real data feedback, forming a closed loop of "prediction, triggering, verification, and self-learning." This mechanism endows the state management system with "preventive immunity" and "dynamic planning" capabilities, significantly improving the system's intelligence level, the foresight of risk warnings, and the smoothness of business processes; Introducing a prediction-driven adaptive label triggering mechanism includes the following steps: S3.31. Collect the tag trigger sequence, link gaps and link correction records of historical projects, and construct a tag trigger time sequence graph (each node represents a state tag, and the edge represents the trigger dependency relationship or sequence relationship) to provide structured prior knowledge for subsequent predictions; S3.32. Based on the current project's state label set, utilize a lightweight graph neural network to fuse the state label dependency structure and combine it with a time series model to predict future triggered label chains, including potentially delayed labels and possibly missing key labels, and output the predicted trigger probability for each label to be triggered. Specifically, based on the current project's status label set, a graph structure is first constructed. , where the set of nodes For each state label, the edge set This represents the parent-child dependency, order constraint, or interlocking relationship between labels; subsequently, a feature vector is generated for each node. This includes dimensions such as tag status encoding (not triggered, triggered, temporarily triggered, abnormal), normalized trigger time, tag priority weight, and historical trigger frequency, to form a node feature matrix. The diagram With characteristic matrix Input a lightweight graph neural network, through an adjacency matrix containing self-connections. and normalization degree matrix Perform multi-layer graph convolution computation to obtain node embedding representations with fused label dependency structures. The node embedding vectors are then input into a Long Short-Term Memory (LSTM) network in chronological order, and combined with historical trigger sequences to model temporal features, obtaining the temporal hidden state at each time step. Finally, the predicted trigger probability of each tag to be triggered is output through a fully connected layer and a sigmoid activation function. This is used to determine potential future tagging links and their triggering trends; The Lightweight Graph Neural Network (GCN) takes graph-structured data as input, including node feature matrices (feature vectors for each label, such as current state, trigger time, priority, etc.) and adjacency matrices (describing parent-child dependencies, interlocking relationships, and triggering order between labels). The intermediate layers consist of several graph convolutional layers, each updating node features through neighbor feature aggregation and nonlinear transformations, typically using ReLU activation and normalization. The output layer generates node embedding vectors, representing the fused node features, used for subsequent time series prediction or trigger probability calculation. GCN employs fewer graph convolutional layers and smaller node embedding vectors. The input dimension is reduced to decrease the number of parameters and computational complexity, while neighbor sampling or sparse matrix operations can be used to reduce memory usage; the Long Short-Term Memory (LSTM) network model takes a sequence of node embeddings (from GCN output or historical label triggering sequences) as input, with each time step corresponding to the feature vector of the label in the sequence; the intermediate layer consists of one or more LSTM layers, which control the flow of information between time steps through forget gates, input gates, and output gates to achieve long-term dependency capture; the output layer generates a prediction vector for each time step, corresponding to the triggering probability or state prediction of future labels, providing a quantitative basis for predictive link triggering labels; S3.33, Predicting the trigger probability Tags exceeding a preset threshold 'a' generate predictive link trigger tags (in this embodiment, the preset threshold 'a' is flexibly set according to the business scenario, and its value range is...). For example, the preset threshold 'a' is set to... This means that tags with a predicted trigger probability exceeding 80% will be pre-generated as predictive link trigger tags and added to the tag set as temporary trigger inputs. Parent-child dependencies are maintained in advance. The prediction model weights are dynamically adjusted based on the consistency between actual subsequent data and prediction results to achieve self-learning optimization. Specifically, the predicted trigger probabilities of all tags are first traversed. The system identifies tags exceeding a preset threshold 'a' as potential trigger tags. Then, it generates predictive link trigger tags for each matching tag, marks its status as "temporary trigger," and records the prediction source, trigger time window, and parent-child dependency information. Next, it incrementally adds these predictive link trigger tags to the current project's status tag set, while updating the dependency checks of relevant parent and child tags to ensure link consistency. Finally, when actual data arrives, the predicted tags are compared with the actual trigger status, and the prediction model weights are dynamically adjusted based on consistency, achieving self-learning optimization and early maintenance of tag trigger links. S3.34. Integrate the predictive link triggering tags into the tag set, and perform incremental state adjustment and update on the state tag set according to the priority relationship of the tags and the parent-child dependency rules, so as to ensure the consistency of the triggering order and dependency of multi-level tags, while retaining the compensation source and validity information, forming a complete dynamic evolution state tag set. S3.4. For multi-level parent-child tags, perform synchronization and dependency updates, and check the dependency relationship between the parent tag state and the child tag state: When the parent tag state changes, update the child tag state synchronously according to the dependency constraints. For example, if the parent tag is not triggered, the child tag remains suspended; if the parent tag is triggered and the child tag condition is met, update it to triggered. When the child tag state changes, check whether the parent tag state needs to be adjusted upwards. For example, if a critical child tag is triggered, it can trigger the parent tag upgrade or risk state elevation. During the synchronization process, interlocking and priority rules are applied simultaneously to resolve potential conflicts, and the state change timestamp and version information are updated. Ultimately, ensure that the parent and child tag states are consistent and the dependency relationship is complete, providing a reliable guarantee for outputting the final dynamically evolving set of state tags. S3.5 After completing the dependency check, output the final set of dynamically evolving state labels.

[0022] The anomaly identification and risk warning unit 4 identifies anomalies based on a dynamically evolving set of tags and generates corresponding risk warning tags for real-time monitoring of the status of the property project.

[0023] In this embodiment, the anomaly identification and risk warning unit 4 includes an anomaly identification module and a risk warning module; The anomaly identification module, based on a dynamically evolving set of state labels, uses rule matching algorithms and time-series deviation detection algorithms to identify abnormal states in the operation of the property project. Specifically, it applies a rule matching algorithm to each label to check whether its state conforms to predefined business rules or logical constraints, including parent-child dependencies, mutual exclusion relationships, and priority coverage rules, and marks labels that violate the rules as anomalies. At the same time, it uses a time-series deviation detection algorithm to compare the actual trigger time of the label with a preset time window or the expected time of the node to identify abnormal states such as timeouts, delays, or lags. For each abnormal state, it records the anomaly type, occurrence time, associated process nodes, and scope of impact, and summarizes this information to form an anomaly label set, providing structured input for subsequent risk warnings. The risk warning module, based on anomaly identification results and combined with an adaptive risk scoring model, performs multi-dimensional quantitative assessments of project schedule risk, compliance risk, and workflow risk, and issues warnings based on the multi-dimensional quantitative assessment results. Specifically, it receives structured anomaly information output by the anomaly identification module, including anomaly type, involved tags, trigger time, and scope of impact. Then, it inputs the anomaly information into the adaptive risk scoring model (rule matching detects explicit violations, time-series deviations detect implicit anomalies, and the risk scoring model comprehensively quantifies risk levels to form a multi-level risk identification system). This model combines historical project data, tag trigger frequency, anomaly occurrence probability, and business importance to quantitatively assess schedule risk, compliance risk, and workflow risk for each anomaly, generating a multi-dimensional risk score vector. For each risk dimension, a warning threshold or grading standard is set. Projects or tags with scores exceeding the threshold or reaching a high-risk level are identified as potential anomalies, generating early warning tags and marking the warning type, trigger probability, prediction timeframe, and involved node information. Finally, the generated early warning tags are incorporated into the project status management system to achieve predictive risk prevention and real-time monitoring based on risk quantification. The adaptive risk scoring model architecture comprises an input layer, an intermediate layer, and an output layer. The input layer receives structured anomaly information and a dynamically evolving set of status labels, including features such as anomaly type, trigger label, trigger time, involved nodes, historical trigger frequency, business importance, and label priority. It can also access predictive link trigger labels and their trigger probabilities. The intermediate layer consists of a multi-layer fully connected network or a lightweight deep learning network. It fuses and weights the input features through non-linear activation functions and attention mechanisms, dynamically adjusting the contribution of each feature to achieve adaptive quantification of the impact of anomalies. The output layer generates a multi-dimensional risk scoring vector, including quantified values ​​of schedule risk, compliance risk, and flow risk, and outputs predictive warning labels and trigger probabilities for potential anomalies, used for real-time monitoring and predictive risk prevention.

[0024] Example 2: The difference between Example 2 and Example 1 is that this example introduces a status tag management method used in a dynamic management system for property project status tags. The dynamic management method for property rights project status tags, based on the aforementioned dynamic management system for property rights project status tags, includes the following steps: S4.1 Collect project data and preprocess the project data; S4.2. Based on the preprocessed project data, utilize the entire lifecycle process of the property project to construct a multi-level status label system; S4.3. Based on a multi-level state label system, a hierarchical state machine model is used to identify the changing trend of project state, generate a set of state labels, and dynamically update the label set when project business events occur, generating a dynamically evolving set of state labels. In the process of generating a dynamically evolving tag set, gaps in the triggering link are identified and structural compensation is performed to generate link correction trigger tags to prevent multi-level tag inference from being interrupted. S4.4. Based on the dynamically evolving tag set, anomaly identification is performed, and corresponding risk warning tags are generated for real-time monitoring of the status of property projects.

[0025] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A dynamic management system of status labels of property items, characterized in that, The system comprises: a data acquisition and processing unit (1) that acquires project data and pre-processes the project data; a state label system construction unit (2) that constructs a multi-level state label system based on the pre-processed project data using the whole life cycle process of the property project; a state reasoning and dynamic updating unit (3) that identifies the trend of the change of the project state based on the multi-level state label system using a hierarchical state machine model, generates a set of state labels, and dynamically updates the set of labels when a project business event occurs to generate a dynamically evolving set of state labels; wherein, in the process of generating the dynamically evolving set of labels, the gaps in the trigger links are identified and structural level compensation is performed to generate link correction trigger labels for preventing the multi-level label reasoning from being interrupted; an abnormality identification and risk warning unit (4) that identifies abnormalities based on the dynamically evolving set of labels and generates corresponding risk warning labels for real-time monitoring of the state of the property project.

2. The dynamic management system of title project status labels of claim 1, wherein: The data acquisition and processing unit (1) comprises a data acquisition module and a data processing module; wherein, the data acquisition module acquires project data, and the project data comprises project basic information data, process and progress event data, documents and compliance data; the data processing module is used for pre-processing the project data.

3. The dynamic management system of title project status labels of claim 2, wherein: The state label system construction unit (2) constructs a multi-level state label system using the whole life cycle process of the property project, comprising the following steps: S1.1, the whole life cycle process of the property project is parsed by an event log-based process mining method to extract main process nodes, sub-nodes and their business logic relationships to form a unified process node standard set; S1.2, key fields are extracted from the project basic information data by an automatic feature extraction algorithm based on rule templates and field characteristics, and corresponding first-level basic attribute labels are generated by mapping to describe the static attribute characteristics of the property project; wherein, the key fields at least include project category, transaction mode, and belonging unit; S1.3, according to the process node standard set, the process events of the property project are sorted by timestamp and matched to the corresponding process nodes by the maximum matching algorithm to construct a multi-level process label reflecting the current progress state of the project, and the generation conditions and update logic of the label are constructed using the dependency relationship between nodes; S1.4, the project-related document and material management information are parsed to construct a material label system, and the dependency and trigger relationship between the material label and the multi-level process label are constructed; S1.5, a multi-level label system is constructed according to the label attributes, business importance and risk level, and the priority relationship between the labels is defined; S1.6, a trigger condition based on the project data is established for each label; S1.7, the logical relationship between the labels is constructed by a Boolean logic diagram.

4. The dynamic management system of title project status tags of claim 1, wherein: The state reasoning and dynamic updating unit (3) comprises a state reasoning module and a dynamic updating module; The state inference module performs real-time analysis on the preprocessed project data based on a multi-level state label system, matches a label trigger condition through a hierarchical state machine model, and infers a state label set to be generated at present. The dynamic updating module dynamically updates the label set of the project according to the state label set output by the state inference module, and generates a final dynamically evolved state label set.

5. The dynamic management system of title project status tags of claim 4, wherein: The state inference module performs real-time analysis on the preprocessed project data based on a multi-level state label system, matches a label trigger condition through a hierarchical state machine model, and infers a state label set to be generated at present, and includes the following steps: S2.1, mapping the preprocessed project data to the corresponding fields in the multi-level state label system, and initializing each label state in the hierarchical state machine; S2.2, analyzing the parent-child relationship and dependency rules of each label in the multi-level label system; S2.3, for each label, matching the trigger condition constructed in the hierarchical state machine, and through condition chain scanning, identifying the gap in the trigger chain and performing structure-level compensation, generating a link correction trigger label to prevent the multi-level label inference from being interrupted; S2.4, using the hierarchical state machine model to infer the state transition of each label including the link correction trigger label; S2.5, all labels that need to be generated through the hierarchical state machine are summarized to form a state label set at the current time point.

6. The dynamic management system of title project status tags of claim 5, wherein: In S2.3, through condition chain scanning, the gap in the trigger chain is identified and structure-level compensation is performed to generate a link correction trigger label, including the following steps: S2.31, analyzing the trigger condition chain of the label, and decomposing each condition in the trigger condition chain into a structured form, and mapping to the corresponding field name, data source system, value rule and current project state; S2.32, scanning the trigger condition chain in order, identifying the condition nodes with missing fields, and forming a gap set in the trigger condition chain; S2.33, for the gaps in the gap set, judging the compensability based on the preset compensation rules; S2.34, for the gaps judged as compensable, performing structure-level compensation according to the gap type; S2.35, after obtaining the compensation result at the end of the structure-level compensation, reassembling the compensated trigger condition chain, and generating the corresponding link correction trigger label as a temporary trigger input.

7. The dynamic management system of property project status tags according to claim 4, characterized in that: The dynamic updating module dynamically updates the label set of the project according to the state label set output by the state inference module, including the following steps: S3.1, receiving the state label set output by the state inference module, and classifying and sorting the state labels according to the project, level, parent-child relationship; S3.2, traversing each received state label, judging whether the current state conflicts with the state in the existing label set of the project; S3.3, performing dynamic updating operation according to the judgment result, and introducing a prediction-driven adaptive label trigger mechanism for identifying the risk of future label chain interruption in advance; S3.4, synchronously updating the multi-level parent-child labels and checking the dependency relationship between the parent label state and the child label state; S3.5, after the dependency check is completed, output the final dynamic evolution state tag set.

8. The dynamic management system of title status labels according to claim 7, characterized in that: In S3.3, a prediction-driven adaptive tag trigger mechanism is introduced, including the following steps: S3.31, collect the tag trigger sequence, link gap and link correction record of the historical project, and construct a tag trigger timing diagram; S3.32, based on the current set of state labels of the project, fusing the state label dependency structure by using a lightweight graph neural network, and combining a time series model to predict the future triggered label link, outputting the predicted trigger probability of each to-be-triggered label ; S3.33, to predict trigger probability The label greater than the preset threshold a generates a predictive link trigger label, which is temporarily triggered as an input to join the label set in advance; S3.34, integrate the predictive link trigger tag into the tag set, and according to the priority relationship and parent-child dependency rules of the tag, incrementally adjust and update the state tag set to form a complete dynamic evolution state tag set.

9. The dynamic management system of title project status tags of claim 1, wherein: The abnormality identification and risk early warning unit (4) includes an abnormality identification module and a risk early warning module; Wherein, the abnormality identification module identifies the abnormal state in the operation of the property project based on the dynamically evolved state tag set, using a rule matching algorithm and a time sequence deviation detection algorithm; The risk early warning module is based on the abnormality identification result, and combines an adaptive risk scoring model to perform multi-dimensional quantitative evaluation on the progress risk, compliance risk and transfer risk of the project, and performs early warning based on the multi-dimensional quantitative evaluation result.

10. A method for dynamic management of a title project status label based on the dynamic management system of a title project status label according to any one of claims 1-9, characterized in that, Including the following steps: S4.1, collect project data and pre-process the project data; S4.2, based on the pre-processed project data, use the property project full life cycle process to construct a multi-level state tag system; S4.3, based on the multi-level state tag system, use a hierarchical state machine model to identify the change trend of the project state, generate a state tag set, and dynamically update the tag set when a project business event occurs, to generate a dynamically evolved state tag set; Wherein, in the process of generating the dynamically evolved tag set, the gap in the trigger link is identified and structural level compensation is performed to generate a link correction trigger tag, which is used to prevent the multi-level tag reasoning from being interrupted; S4.4, based on the dynamically evolved tag set, identify the abnormality and generate corresponding risk early warning tags for real-time monitoring of the state of the property project.

Images