Dual-wheel parallel method for gradual migration of data security obligation implementation from rule-driven to semantic-driven

Abstract

The application discloses a double-wheel parallel method for gradually migrating data security obligation execution from rule driving to semantic driving. The method runs in parallel through a rule engine (a first obligation execution engine) and a semantic reasoning engine (a second obligation execution engine). In the data security obligation execution system, the fields that have completed semantic classification in the security semantic knowledge base instance layer are routed to the semantic reasoning engine for obligation processing; the fields that have not completed semantic classification are continuously executed by the rule engine for obligation processing. When the data administrator completes the semantic classification confirmation of a certain field and writes it into the instance layer, the system triggers the route switching of the obligation execution engine with the field as the granularity atom. The system maintains the semantic coverage rate index and the high-risk unclassified field priority modeling list in real time, and provides real-time visibility of the migration progress to the operation team. The application solves the engineering feasibility problem of the data security system driven by semantic reasoning that "must be fully modeled before going online", realizes smooth technical migration without interruption of obligation execution, and is suitable for the engineering scene of upgrading the data security obligation execution system from the rule era to the semantic era.

Description

Technical Field

[0001] This invention relates to the field of data security technology, specifically to a method for the parallel operation and gradual migration of a rule-driven engine and a semantic reasoning engine in a data security obligation execution system. It is applicable to data security system engineering scenarios that require a smooth transition from an existing rule-driven obligation execution system to a semantic reasoning-driven obligation execution system. Background Technology

[0002] In the era of data elementization, the methodology of data security is undergoing a fundamental paradigm shift. A new generation of data security obligation enforcement systems, centered on ontology and employing AI semantic reasoning, defines the security obligations of data fields as intrinsic components of their semantic attributes, fundamentally changing obligation enforcement from "external rule configuration" to "semantic reasoning-driven." In this system, the instance layer (ABox) of the security semantic knowledge base (P1) records the mapping relationship between data field instances and semantic classes. Based on this mapping relationship and the reasoning rule set of the concept layer (TBox), the inference engine automatically derives the set of obligations that each field should execute in each access scenario.

[0003] However, the aforementioned system faces severe feasibility challenges in actual engineering deployment. Taking a typical tertiary-level hospital as an example: a hospital's data system typically includes multiple heterogeneous systems such as HIS, LIS, EMR, and PACS, involving a total of 3,000 to 10,000 fields. Field naming is highly irregular (e.g., the pinyin abbreviation "jzrxm," the numerical code "f001," etc.), and complete semantic modeling usually takes 2 to 6 weeks to complete. If the system is required to go live only after all modeling is completed, it means that data security obligations are completely absent during this period, creating an unacceptable security risk window.

[0004] On the other hand, existing rule-based obligation execution systems (hereinafter referred to as "rule-driven systems") can be launched immediately, but they have the following well-known defects: (1) low rule coverage, typically 40%-60%, with a large number of fields not covered by rules; (2) rules repeatedly fail as the system iterates, requiring dedicated personnel for continuous maintenance; (3) unable to reason about unpreset scenarios, resulting in a large security blind spot when facing new access patterns; (4) coarse rule granularity, making it impossible to achieve semantic-based fine-grained and differentiated obligation execution.

[0005] Currently, there is no effective technical solution that can achieve a smooth technological migration from rule-driven to semantic reasoning-driven approaches while ensuring uninterrupted execution of obligations. This engineering problem hinders the implementation and promotion of semantic reasoning-driven data security systems in production environments. Summary of the Invention

[0006] This invention provides a dual-wheel parallel method for the gradual migration of data security obligation execution from rule-driven to semantic-driven, solving the following technical problems: (1) how to launch the obligation execution system before the completion of full semantic modeling; (2) how to ensure that obligation execution is not interrupted during the migration process; (3) how to make the semantic coverage naturally increase to full coverage as the modeling progresses; and (4) how to enable the operations team to keep track of the migration progress in real time and optimize the modeling priority.

[0007] The technical solution adopted by this invention to solve its technical problem is: A dual-wheel parallel method for progressively migrating data security obligation enforcement from rule-driven to semantic-driven approaches is proposed. This method is applied to a data security obligation enforcement system with a security semantic knowledge base, which comprises a concept layer and an instance layer. The method includes the following steps: Step S1: Dual-wheel parallel initialization—When the data security obligation execution system starts, the first obligation execution engine and the second obligation execution engine are started and run in parallel: The first obligation execution engine is a rule-driven engine that performs obligation processing on data fields based on a pre-compiled rule set, and the rule set maintains semantic alignment with the concept layer reasoning rules of the security semantic knowledge base; The second obligation execution engine is a semantic reasoning engine that performs obligation processing on data fields based on the reasoning results of the security semantic knowledge base. Step S2: Field-level Obligation Routing – During the obligation execution phase of each data access request, the obligation execution path is determined independently for each data field involved in the request: If the field has a confirmed semantic class attribution record in the security semantic knowledge base instance layer, the obligation execution of the field is routed to the second obligation execution engine for processing; if the field does not have a confirmed semantic class attribution record in the security semantic knowledge base instance layer, the obligation execution of the field is routed to the first obligation execution engine for processing. The method execution process also includes: Classification event triggers switching—when the security semantic knowledge base instance layer receives confirmation of semantic classification for a certain field from the data administrator, it triggers a switch of the obligation execution path for that field: the field is removed from the processing scope of the first obligation execution engine and added to the processing scope of the second obligation execution engine; the switching is completed atomically without stopping the system operation, and subsequent requests for that field are automatically routed to the second engine after the switching is completed; Real-time coverage maintenance—The system maintains the following semantic coverage status indicators in real time: the ratio of the number of semantically covered fields to the total number of fields in the data system; a list of fields with high access frequency that have not yet been semantically categorized; the number and proportion of requests processed by the first engine and the second engine respectively; these indicators are updated when a categorization event triggers a switching event and are pushed to the operation monitoring system in real time. The fallback guarantee is that the first execution engine continuously performs the obligation processing on all fields not routed to the second engine until the field completes the classification event that triggers the switch; the fallback execution of the first engine ensures that there are no fields with blank obligation execution during the entire migration process.

[0008] Furthermore, the semantic alignment of the rule set of the first obligation execution engine with the reasoning rules of the concept layer of the security semantic knowledge base in step S1 is specifically manifested as follows: the rule set adopts the form of production rules, and each rule includes a condition part and a conclusion part. The condition part covers a type of field feature, and the field feature includes: the field name contains a specific pattern and the data type is a specific type; the conclusion part specifies the type of obligation to be executed and the parameters; the condition part of each rule is expressed as an equivalent semantic query, and the conclusion part of the rule is expressed as an equivalent obligation class instantiation; the alignment relationship is maintained by the system, which supports the semi-automatic conversion of the rules of the first engine into reasoning rules in the security semantic knowledge base, providing technical support for the gradual migration from rule patterns to semantic reasoning patterns.

[0009] Furthermore, the field-level obligation routing judgment described in step S2 is executed independently at the field level in the obligation execution pipeline of data access requests. Different fields in the same request are simultaneously routed to different engines for processing. The routing judgment result is cached in the local cache with the field identifier as the key to avoid repeated querying of the instance layer for each request. When the classification event triggers a switch, the routing cache entry for the corresponding field becomes invalid, and subsequent requests trigger a re-routing judgment.

[0010] Furthermore, in the classification event-triggered switching, the atomicity of the obligation execution path switching is guaranteed by the following mechanism: the switching operation uses the field identifier as the key to perform an atomic write operation on the routing state table; before the switching operation is completed, concurrent requests for the field continue to be routed to the first engine for processing; after the switching operation is completed, newly arriving requests are routed to the second engine for processing; there is no intermediate state where the same field is processed by two engines at the same time.

[0011] Furthermore, when implementing fallback protection, the fallback protection of the first task execution engine also includes a rollback mechanism: if the second task execution engine fails or returns an error when processing a certain field, the system automatically switches the current request for that field to the first engine for processing and triggers an alarm to notify the operations personnel; the rollback is a temporary measure and does not change the persistent routing settings of that field in the routing status table, and the next request will restore the normal routing.

[0012] Furthermore, when performing real-time coverage maintenance, the semantic coverage status indicator also supports grouped statistics at the data system level: the system maintains the total number of fields, the number of categorized fields, and the coverage rate for each access business data system; the grouped statistics are displayed in a visual manner in the coverage monitoring dashboard, supporting the operations team to plan semantic modeling work according to the data system priority.

[0013] Furthermore, the method also includes a shadow mode operation mechanism: In shadow mode, fields that have completed semantic classification are processed in parallel by two engines. The processing result of the second engine is only recorded and not externally effective. The system automatically calculates the consistency rate of the two engines' decision-making on the same field. When the consistency rate is lower than a preset threshold, an alarm is triggered, indicating that there may be deviations in the semantic classification or reasoning rules of the relevant fields, so that knowledge engineers can make corrections before the formal switch.

[0014] Furthermore, the method can be used in conjunction with a secure semantic knowledge base, a data access obligation execution framework, and an operation monitoring system; the introduction of the aforementioned external systems does not change the five core technical mechanisms of parallel operation of the first and second obligation execution engines, field-granular obligation routing, classification event-triggered switching, real-time coverage maintenance, and fallback protection.

[0015] This invention also provides a method for monitoring and prioritizing execution coverage based on the above-mentioned dual-round parallel method, which further includes the following steps: High-risk field identification – After each classification event triggers a switch, the system scores the risk of unclassified fields based on the following two dimensions: the historical access frequency of the field; and the business sensitivity of the data table where the field is located. The system generates a priority modeling list of high-risk unclassified fields based on both dimensions, and pushes the list to the data administrator to guide them to prioritize the semantic classification of high-risk fields. Milestone alerts – When semantic coverage reaches a preset threshold, the system pushes a milestone notification to the operations team; when the number of fields in the high-risk unclassified field list exceeds a preset limit, the system triggers a priority modeling alert; the preset thresholds are set through the operations configuration interface without modifying the system code.

[0016] Furthermore, the high-risk field identification also incorporates the following dimensions for comprehensive scoring: the expected security level of the semantic class to which the field belongs, which is determined based on pre-analysis of the field name and data type; the number of business scenarios associated with the field; the frequency of the field's appearance in external data sharing requests; and the comprehensive score is dynamically updated, automatically adjusting the recommendation priority as access patterns change.

[0017] The present invention also provides a dual-wheel parallel system for implementing the above-described method for data security obligation execution, comprising the following functional modules: Obligation routing engine: For each field in each data access request, it queries the routing status table to determine the obligation execution path, and schedules the field to the first obligation execution engine or the second obligation execution engine for processing, maintains the routing cache and responds to cache invalidation events; The first obligation execution engine performs obligation processing on fields routed to this engine based on the pre-compiled rule set, and maintains the semantic alignment relationship between the rule set and the concept layer of the security semantic knowledge base; The second obligation execution engine calls the security semantic knowledge base reasoning service and performs obligation processing on the fields routed to this engine based on the reasoning results; The route switching management module listens for field classification confirmation events in the security semantic knowledge base instance layer, atomically updates the route status table, and triggers precise invalidation of the route cache. Coverage monitoring module: Maintains semantic coverage status indicators, a list of high-risk unclassified fields, and dual-engine request volume statistics in real time, and pushes real-time data to the operation monitoring system.

[0018] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described method.

[0019] Compared with the prior art, the present invention has the following technical effects: Effect 1: The system can be launched immediately after the first batch of fields are semantically classified, without waiting for the full modeling to be completed, thus eliminating the engineering deployment threshold of the semantic reasoning system; Effect 2: Throughout the migration process, the rule engine continuously executes the rules for unclassified fields as a fallback, ensuring the continuity of execution for any blank fields. Effect 3: The switching of the task execution engine is performed atomically with fields as the smallest granularity. The system runs continuously during the switching process, and there is no intermediate inconsistency. Effect 4: Real-time visualization of semantic coverage and accurate identification of high-risk unclassified fields enable the operations team to advance modeling work with the highest priority and maximize the security value of each unit of modeling investment. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the overall dual-wheel parallel architecture of the present invention.

[0021] Figure 2 This is a flowchart illustrating the progressive switching of field granularity in this invention.

[0022] Figure 3 This is a schematic diagram of the coverage monitoring dashboard of the present invention.

[0023] Figure 4 This is an integration and interaction diagram of the present invention with the security semantic knowledge base, business system, and operation monitoring system. Detailed Implementation

[0024] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0025] Figure 1 This is a schematic diagram of the dual-wheel parallel architecture of the present invention, illustrating the parallel operation architecture of the rule engine (first obligation execution engine) and the semantic reasoning engine (second obligation execution engine), as well as the field-granularity routing scheduling mechanism of the obligation routing engine. The upper part of the diagram represents the data access request entry point, which is routed through the obligation routing engine (ObligationRouter). The obligation routing engine queries the routing status table and routes the fields involved in the request to either the first obligation execution engine (rule engine) on the left or the second obligation execution engine (semantic reasoning engine) on the right, based on field granularity. The first engine (left, red border) connects to the pre-compiled rule set, with the label "Handling Unclassified Fields - Last-Hand Protection" below it; the second engine (right, blue border) connects to the security semantic knowledge base P1, with the label "Handling Classified Fields - Semantic Reasoning" below it. The lower part of the diagram represents the routing switching management module, which subscribes to ABox change events at the P1 instance layer and atomically updates the routing status table. The right side of the diagram represents the coverage monitoring module, which provides real-time statistics on coverage metrics and pushes them to the operations dashboard. Solid arrows between components represent request / data flow, while dashed arrows represent event notification flow.

[0026] Figure 2 This is a flowchart illustrating the progressive switching process of field granularity in this invention, showing the complete process from field metadata collection, AI-assisted classification suggestions, data administrator confirmation, ABox writing to route switching triggering. Figure 2This demonstrates the complete process of migrating a single data field from "processed by the rules engine" to "processed by the semantic reasoning engine." The process is divided into five stages from top to bottom, with a swimlane diagram used to distinguish the operational boundaries of each component: the left swimlane represents the SSC (Source Semantic Access Connector), the middle swimlane represents the AI ​​classification module and data administrator, and the right swimlane represents the P1 knowledge base and routing switching management module. Stage 1 (Metadata Collection): The SSC collects the physical metadata of the field in read-only mode and writes it to the metadata buffer. Stage 2 (AI Classification Suggestion): The AI ​​module calculates the similarity between the field and each semantic class, generating a candidate list based on confidence level (≥85% / 60%-85% / <60%). Stage 3 (Administrator Confirmation): The data administrator performs confirmation operations on the candidate lists at each level. Stage 4 (ABox Write): The confirmation result transaction is written to the P1 instance layer, and a classification confirmation event is published. Stage 5 (Route Switching): The routing switching module receives the event, atomically updates the routing status table, and subsequent requests for this field are routed to the second engine. The diamond-shaped decision nodes in the flowchart mark the two key decision points: "Confidence Level Judgment" and "Administrator Confirmation."

[0027] Figure 3 This is a schematic diagram of the coverage monitoring dashboard of the present invention, showing a visual layout of semantic coverage progress bar, high-risk unclassified field list, dual-engine request volume comparison and milestone warning. Figure 3 This section demonstrates the interface layout of the coverage monitoring dashboard. The top of the dashboard displays an overall coverage progress bar, color-coded to distinguish different stages (red 0-50%, yellow 50%-80%, green 80%-100%). Below the progress bar, the current coverage value and statistics on switched / total fields are displayed. The left side of the dashboard shows a list of high-risk unclassified fields, displayed in a table format with field name, data system, historical access frequency, and risk score, sorted in descending order of risk score. Each record has an "Immediate Classification" shortcut button on the right. The upper right of the dashboard displays a real-time comparison chart of request volume between the two engines, showing the trend of the number of requests processed by the first and second engines over the past 24 hours using a line graph. The lower right of the dashboard displays milestone progress; the 50% / 80% / 95% milestones are indicated by circular icons, while milestones not yet reached show their estimated completion dates. The bottom of the dashboard displays coverage tables grouped by data system, with each row showing the total number of fields, the number of classified fields, and the coverage percentage for each business system (HIS / LIS / EMR / PACS, etc.).

[0028] Figure 4 This is an integration interaction diagram of the present invention with the security semantic knowledge base (P1), business system and operation monitoring system, showing the data flow and event triggering relationship between the components. Figure 4This diagram illustrates the integrated interaction between the dual-wheel parallel task execution system and external components. The diagram centers on the dual-wheel parallel task execution system (including the task routing engine, dual engines, and routing switching module). On the left is the business system cluster (HIS / LIS / EMR / PACS, etc.), which initiates task execution requests to the system via a data access request interface (solid arrow pointing right). At the bottom left is the SSC (Source Semantic Access Connector), which provides field metadata to the system via a metadata collection interface (dashed arrow pointing right). The SSC is connected to the business system database via a read-only connection (double-sided dashed line). On the right is the security semantic knowledge base P1. The system queries P1 for field semantic classes and inference results (solid arrow pointing right), and P1 publishes ABox change events to the system (dashed arrow pointing left). At the top right is the AI-assisted classification module, which receives metadata collected by the SSC (dashed arrow pointing right) and pushes classification suggestions to the data administrator interface (dashed arrow pointing downwards). At the bottom is the operations monitoring dashboard, which receives real-time data pushes from the coverage monitoring module (solid arrow pointing downwards). The labels between the nodes in the diagram indicate the protocol type of each interface (REST API / Kafka event / WebSocket, etc.).

[0029] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0030] I. System Overall Architecture (see...) Figure 1 ) The core architecture of the dual-wheel parallel task execution system includes the following components: (1) Obligation Router: Located in the obligation execution phase of the data access request processing pipeline, it queries the routing status table for each data field involved in the request and schedules the field to the first or second obligation execution engine respectively. The routing status table uses the field identifier as the key and the engine number (1 or 2) as the value. In the initial state, all fields are routed to the first engine. The caching layer of the routing status table (preferably using Redis or Caffeine local caching) ensures that the latency of routing decision is less than 1ms, which does not affect the overall response time of the data access request; (2) First Obligation Execution Engine (Rule Engine): This engine performs obligation processing on fields based on a pre-compiled rule set. The rule set adopts the form of production rules (IF-THEN). The condition part of each rule covers a class of field characteristics (such as field names containing a specific pattern, data types being specific, etc.), and the conclusion part specifies the type of obligation to be executed and the parameters. The rule set maintains semantic alignment with the reasoning rules of the conceptual layer of the security semantic knowledge base, ensuring that the obligation decisions of the two engines for the same field are semantically equivalent. In a typical tertiary hospital scenario, the initial rule set usually contains 200 to 500 rules, covering the most common field types and obligation scenarios; (3) Second Obligation Execution Engine (Semantic Reasoning Engine): Invokes the reasoning service of the secure semantic knowledge base (P1), and automatically derives the obligation set and executes the obligation processing based on the semantic class attribution of the fields and the ternary semantic context (subject class × resource class × destination class) of the access scenario through the OWL2 reasoning engine. In a typical implementation, the reasoning engine uses the ELK inferencer to handle high-frequency requests, and its materialized cache ensures that the inference decision latency is less than 5ms; for complex reasoning scenarios, it degrades to the HermiT inferencer for asynchronous processing. (4) Route Switch Manager: Subscribes to the Field Classification Confirmation Event (ABox Change Event) in the Security Semantic Knowledge Base instance layer. When the event arrives: (a) Updates the engine number of the corresponding field in the route status table from 1 to 2; (b) Triggers the precise invalidation of the corresponding key in the route cache; (c) Pushes a field switching notification to the coverage monitoring module. The above three steps are executed atomically within the same transaction. (5) Coverage Monitor: Maintains global semantic coverage metrics, including: total number of fields (obtained from the metadata collection component), number of fields switched to the second engine (accumulated statistics from route switching events), coverage percentage, list of high-risk unclassified fields, and real-time statistics of dual-engine request volume. The above metrics are pushed to the operations monitoring dashboard in real time via WebSocket or Server-Sent Events.

[0031] II. Gradual switching process for field granularity (see...) Figure 2 ) The complete process of migrating each field from "rule engine processing" to "semantic reasoning engine processing" is as follows: Phase 1 (Metadata Acquisition): The Source Semantic Access Connector (SSC) connects to the business system database metadata interface in read-only mode to collect field physical metadata (field name, data type, comments, etc.) and write it to the metadata buffer; Phase Two (AI Classification Suggestions): The AI-assisted semantic classification module calculates the similarity between fields in the metadata buffer and each semantic class in the concept layer of the security semantic knowledge base, generating a list of candidate semantic classes and a confidence score. Fields with a confidence score higher than 85% enter the batch pre-filling queue, fields with a confidence score between 60% and 85% enter the recommendation confirmation queue, and fields with a confidence score lower than 60% enter the manual review queue. Phase Three (Administrator Confirmation): Data administrators confirm fields in each queue through the management interface. The batch pre-population queue supports one-click selection of all for confirmation; the recommended confirmation queue displays a candidate list for selection; the manual review queue displays field details for manual evaluation. The administrator's confirmation triggers the next phase. Phase 4 (ABox Write): The semantic classification results confirmed by the administrator are written to the security semantic knowledge base instance layer (ABox) in a transactional manner. After the write is completed, the knowledge base publishes the field classification confirmation event. Phase 5 (Route Switching): After receiving the field classification confirmation event, the route switching management module atomically updates the route status table, triggering route cache invalidation. Subsequent requests for this field are automatically routed to the second obligation execution engine for processing. Thereafter, the semantic reasoning engine determines the obligation set for this field through real-time reasoning, no longer relying on the rule set.

[0032] III. Coverage Monitoring Dashboard (see...) Figure 3 ) The coverage monitoring dashboard is an operational management tool with a dual-engine mechanism, containing the following core display content: (1) Overall coverage progress bar: Displays the percentage of fields that have completed semantic classification in percentage form, with color coding to distinguish the stage (red 0-50%, yellow 50%-80%, green 80%-100%). (2) List of high-risk unclassified fields: The top N high-risk fields that have not been classified are displayed in descending order of risk score. Each record displays the field name, the data system to which it belongs, the historical access frequency and the estimated obligation type. It supports one-click jump to the classification operation interface. (3) Dual Engine Request Volume Comparison: Real-time display of the number and percentage of obligation requests handled by the first and second engines respectively, and line chart showing the trend changes over the past 24 hours; (4) Milestone progress: Displays the achievement status of 50%, 80%, and 95% coverage milestones, and shows the estimated completion time for milestones that have not been achieved (based on the current modeling speed extrapolation). (5) Coverage by data system group: Display the coverage of each access business system (HIS / LIS / EMR / PACS, etc.) in a table or tree diagram, supporting the operation team to plan modeling priority according to system importance.

[0033] IV. Typical Application Scenarios (see...) Figure 4 ) Taking the deployment in a tertiary-level Class A hospital as an example, the typical application scenario of this invention is illustrated as follows: Initial deployment (0% modeling rate): When the system goes live, all fields are routed to the first task execution engine, which processes tasks based on pre-configured rule sets. At this time, task coverage equals rule set coverage (typical value 40%-60%). SSC synchronously collects field metadata from all data systems, and AI-assisted classification suggestions begin to be generated; Modeling in progress (modeling rate 0%-95%): Data administrators continuously confirm semantic classification. After each batch of fields is confirmed, the relevant fields are switched to the semantic inference engine for processing. Semantic coverage naturally increases with modeling progress. During this stage, the two engines run in parallel, and the coverage monitoring dashboard displays the progress in real time. High-risk fields are prioritized for identification and modeling to ensure maximum security value. Modeling complete (modeling rate ≥ 95%): The vast majority of fields have been switched to the semantic reasoning engine, while a small number of low-frequency, low-risk fields may still be handled by the primary engine. At this point, the system's obligation execution capability is close to the level of full semantic-driven systems, with an obligation coverage rate 30%-50% higher than that of pure rule-driven systems, and a significantly reduced false alarm rate (inapplicable obligations being executed incorrectly).

Claims

1. A dual-wheel parallel method for progressively migrating data security obligation execution from rule-driven to semantic-driven approaches, applied to a data security obligation execution system with a security semantic knowledge base, wherein the security semantic knowledge base comprises a concept layer and an instance layer, characterized in that... Includes the following steps: Step S1: Dual-wheel parallel initialization—When the data security obligation execution system starts, the first obligation execution engine and the second obligation execution engine are started and run in parallel: The first obligation execution engine is a rule-driven engine that performs obligation processing on data fields based on a pre-compiled rule set, and the rule set maintains semantic alignment with the concept layer reasoning rules of the security semantic knowledge base; The second obligation execution engine is a semantic reasoning engine that performs obligation processing on data fields based on the reasoning results of the security semantic knowledge base. Step S2: Field-level Obligation Routing – During the obligation execution phase of each data access request, the obligation execution path is determined independently for each data field involved in the request: If the field has a confirmed semantic class attribution record in the security semantic knowledge base instance layer, the obligation execution of the field is routed to the second obligation execution engine for processing; if the field does not have a confirmed semantic class attribution record in the security semantic knowledge base instance layer, the obligation execution of the field is routed to the first obligation execution engine for processing. The method execution process also includes: Classification event triggers switching—when the security semantic knowledge base instance layer receives confirmation of semantic classification for a certain field from the data administrator, it triggers a switch of the obligation execution path for that field: the field is removed from the processing scope of the first obligation execution engine and added to the processing scope of the second obligation execution engine; the switching is completed atomically without stopping the system operation, and subsequent requests for that field are automatically routed to the second engine after the switching is completed; Real-time coverage maintenance—The system maintains the following semantic coverage status indicators in real time: the ratio of the number of semantically covered fields to the total number of fields in the data system; a list of fields with high access frequency that have not yet been semantically categorized; the number and proportion of requests processed by the first engine and the second engine respectively; these indicators are updated when a categorization event triggers a switching event and are pushed to the operation monitoring system in real time. The fallback guarantee is that the first execution engine continuously performs the obligation processing on all fields not routed to the second engine until the field completes the classification event that triggers the switch; the fallback execution of the first engine ensures that there are no fields with blank obligation execution during the entire migration process.

2. The method according to claim 1, characterized in that, In step S1, the semantic alignment of the rule set of the first obligation execution engine with the reasoning rules of the concept layer of the security semantic knowledge base is specifically manifested as follows: the rule set adopts the form of production rules, and each rule includes a condition part and a conclusion part. The condition part covers a type of field feature, and the field feature includes: the field name contains a specific pattern and the data type is a specific type; the conclusion part specifies the type of obligation to be executed and the parameters; the condition part of each rule is expressed as an equivalent semantic query, and the conclusion part of the rule is expressed as an equivalent obligation class instantiation; the alignment relationship is maintained by the system, which supports the semi-automatic conversion of the rules of the first engine into reasoning rules in the security semantic knowledge base, providing technical support for the gradual migration from rule pattern to semantic reasoning pattern.

3. The method according to claim 1, characterized in that, The field-level obligation routing judgment described in step S2 is executed independently at the field level in the obligation execution pipeline of data access requests. Different fields in the same request are simultaneously routed to different engines for processing. The routing determination result is cached in the local cache, using the field identifier as the key, to avoid repeatedly querying the instance layer with each request; when the classification event triggers a switch, the routing cache entry for the corresponding field becomes invalid, and subsequent requests trigger a re-routing determination.

4. The method according to claim 1, characterized in that, In the classification event-triggered switching, the atomicity of the obligation execution path switching is guaranteed by the following mechanism: the switching operation uses the field identifier as the key to perform an atomic write operation on the routing status table; before the switching operation is completed, concurrent requests for the field continue to be routed to the first engine for processing; after the switching operation is completed, newly arriving requests are routed to the second engine for processing; there is no intermediate state where the same field is processed by two engines at the same time.

5. The method according to claim 1, characterized in that, When implementing fallback protection, the fallback protection of the first task execution engine also includes a rollback mechanism: if the second task execution engine fails or returns an error when processing a certain field, the system automatically switches the current request for that field to the first engine for processing and triggers an alarm to notify the operations personnel; the rollback is a temporary measure and does not change the persistent routing settings of that field in the routing status table, and the next request will restore the normal routing.

6. The method according to claim 1, characterized in that, In real-time coverage maintenance, the semantic coverage status indicator also supports grouped statistics at the data system level: the system maintains the total number of fields, the number of categorized fields, and the coverage rate for each access business data system; the grouped statistics are displayed in a visual manner in the coverage monitoring dashboard, supporting the operations team to plan semantic modeling work according to the data system priority.

7. The method according to claim 1, characterized in that, It also includes a shadow mode operation mechanism: In shadow mode, fields that have completed semantic classification are processed in parallel by two engines. The processing results of the second engine are only recorded and not made public. The system automatically calculates the consistency rate of the two engines' decision-making on the same field. When the consistency rate is lower than a preset threshold, an alarm is triggered, indicating that there may be deviations in the semantic classification or reasoning rules of the relevant fields, so that knowledge engineers can make corrections before the formal switch.

8. The method according to claim 1, characterized in that, The method can be used in conjunction with a secure semantic knowledge base, a data access obligation execution framework, and an operation monitoring system. The introduction of the above external systems does not change the five core technical mechanisms: parallel operation of the first and second obligation execution engines, field-granular obligation routing, classification event-triggered switching, real-time coverage maintenance, and fallback protection.

9. A method for monitoring and prioritizing execution coverage and recommending priority models based on the method described in claim 1, characterized in that, It also includes the following steps: High-risk field identification – After each classification event triggers a switch, the system scores the risk of unclassified fields based on the following two dimensions: the historical access frequency of the field; and the business sensitivity of the data table where the field is located. The system generates a priority modeling list of high-risk unclassified fields based on both dimensions, and pushes the list to the data administrator to guide them to prioritize the semantic classification of high-risk fields. Milestone alerts – When semantic coverage reaches a preset threshold, the system pushes a milestone notification to the operations team; when the number of fields in the high-risk unclassified field list exceeds a preset limit, the system triggers a priority modeling alert. The preset threshold is set through the operation configuration interface without modifying the system code.

10. The method according to claim 9, characterized in that, The high-risk field identification also incorporates the following dimensions for comprehensive scoring: the expected security level of the semantic class to which the field belongs, which is determined based on pre-analysis of the field name and data type; the number of business scenarios associated with the field; the frequency of the field's appearance in external data sharing requests; and the comprehensive score is dynamically updated, automatically adjusting the recommendation priority as access patterns change.

11. A dual-wheel parallel system for implementing the data security obligation execution of the method of claim 1 or 10, characterized in that, Includes the following functional modules: Obligation routing engine: For each field in each data access request, it queries the routing status table to determine the obligation execution path, and schedules the field to the first obligation execution engine or the second obligation execution engine for processing, maintains the routing cache and responds to cache invalidation events; The first obligation execution engine performs obligation processing on fields routed to this engine based on the pre-compiled rule set, and maintains the semantic alignment relationship between the rule set and the concept layer of the security semantic knowledge base; The second obligation execution engine calls the security semantic knowledge base reasoning service and performs obligation processing on the fields routed to this engine based on the reasoning results; The route switching management module listens for field classification confirmation events in the security semantic knowledge base instance layer, atomically updates the route status table, and triggers precise invalidation of the route cache. Coverage monitoring module: Maintains semantic coverage status indicators, a list of high-risk unclassified fields, and dual-engine request volume statistics in real time, and pushes real-time data to the operation monitoring system.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images