Deep learning-based management and education monitoring system

Abstract

The invention discloses a management and education monitoring system based on deep learning, relates to the technical field of computers, and is used for solving the problem that a traditional management and education monitoring system usually depends on manual operation or simple automatic scripts and is difficult to deal with high-concurrency and high-reliability requirements in a complex linkage scene. Service actions are constructed into an atomic action graph, and graph rewriting and two-stage convergence batching are carried out in combination with a mutual exclusion matrix, so that the degree of parallelism is maximized, and resource contention is avoided; an idempotent token is generated by the plan fingerprint and only an outgoing box is added, so that first successful receipt reuse and at most one side effect semantics are realized; a main key set capable of being aligned is provided through rehearsal and a state transition diagram, so that the execution premise can be quickly verified; triple verification of an interface level, a state level and a side certificate level is taken as a decision mechanism, a side certificate is taken as a negative criterion, and loss can be stopped quickly when false success and late success occur.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and more particularly, to a discipline monitoring system based on deep learning. Background Art

[0002] In modern complex distributed systems, especially in one-key linkage scenarios such as smart home, industrial control, emergency command, and discipline monitoring, users trigger a series of complex actions across systems and devices through a simple operation. These actions often involve multiple heterogeneous systems, various resources, and have extremely high requirements for the atomicity, consistency, reliability, and traceability of execution. Traditional discipline monitoring systems usually rely on manual operations or simple automation scripts and are difficult to meet the high concurrency and high reliability requirements in complex linkage scenarios.

[0003] Therefore, within a single session of one-key linkage, how to execute multi-system operations in a deterministic batch and idempotent control while maintaining the correctness of causal dependencies, and timely identify the deviation between the interface receipt and the actual state through rehearsal and triple verification, and then implement the minimum necessary compensation without spreading side effects and form an evidence chain that can be independently reviewed, so as to achieve a unified closed loop of atomic completion or causal rollback.

[0004] In view of the above problems, the present invention proposes a solution. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a discipline monitoring system based on deep learning to solve the problems raised in the above background art.

[0006] To achieve the above object, the present invention provides the following technical solutions: A discipline monitoring system based on deep learning, comprising: A session management module, configured to obtain a session identifier, a linkage list, and an action library, obtain a resource view, a mutex matrix, a time policy, and evidence storage constraints, and obtain a session start log entry, where the session identifier is used for subsequent full-link association, and the linkage list and the action library are used to define a set of待执行动作集合与参数模板; An action graph construction and verification module, configured to generate an atomic action graph with causal dependencies and mutex constraints, generate a plan fingerprint and the idempotent token, generate a planned status flag and a corresponding log, where the plan fingerprint is calculated based on a graph structure, an interface version, a parameter key, and a resource identifier, and the idempotent token is bound to the session identifier and a time window; It should be noted that in the original text, there is an unclear part in the description of the "联动清单与动作库用于限定待执行动作集合与参数模板" in Chinese, which is translated as "the linkage list and the action library are used to define a set of待执行动作集合与参数模板" in English for the time being. You may need to further clarify this content for a more accurate translation.The pre-inspection module is used to determine the consistency of the interface contract and the accessibility of the permission path, determine the set of executable nodes and the list of reasons for non-executability, and determine the validity of the authorization closure after the session mid-segment policy update. The determination is based on the parameter template and the results of the registry and health probe. The orchestration module is used to calculate topology batching and rate window rebalancing and form batch plans, calculate the parallel set, threshold conditions and expected timing within a batch, calculate window occupancy priority and deterministic selection sequence and record batch number. The calculation is constrained by the atomic action graph, the mutual exclusion matrix and the resource view. The execution and idempotency control module is used to output out-of-band sending requests and output the idempotency tokens to the target system in batches, output receipt summaries and candidate completion flags, output interface-level, status-level and side-evidence-level verification results, and output session evidence chain fingerprints, wherein the evidence chain fingerprints are associated with the timeline relative sequence number and fingerprint sequence.

[0007] In a preferred embodiment, the session management module obtains the device identifier, timestamp, and random entropy source to generate the session identifier; obtains the interface name, interface version, required parameters, and compensation actions of the action library; and obtains the session start log and writes it into the session identifier, linkage list identifier, and parameter source.

[0008] In a preferred embodiment, the action graph construction and verification module obtains the action input prerequisites and side effect descriptions to generate causal dependency edges; rewrites the concurrent nodes according to the mutual exclusion matrix; calculates the plan fingerprint; and calculates the idempotent token based on the plan fingerprint, the session identifier, and the time window.

[0009] In a preferred embodiment, the system further includes a pre-inspection module, which acquires contract pre-inspection results and compares the local interface version with the registry version; acquires parameter templates and determines the completeness and numerical range of required fields; expands the authentication path from the session subject to the target interface; and acquires health probes to form an executable node list.

[0010] In a preferred embodiment, the orchestration module acquires the atomic action graph and the resource view for topology batching; acquires the rate limit window and performs window rebalancing; generates a batch plan and records the parallel set, threshold conditions, expected timing and batch number; and updates the target system window counter during the selection process.

[0011] In a preferred embodiment, the system further includes a rehearsal and state management module, which obtains the return handle of the target system that supports simulation; generates a temporary session for the target system that does not support simulation; generates a PST and records the state name, ownership subject, resource identifier, generation action identifier and validity period; and writes it into the rehearsal log.

[0012] In a preferred embodiment, the execution and idempotency control module acquires the batch plan and reads out-of-band dispatch requests in batches; outputs the idempotency token to the target system and performs a limited number of retries and backoffs; acquires the receipt status code and receipt fingerprint to form a receipt digest; and acquires candidate completion markers that meet the pre-verification requirements.

[0013] In a preferred embodiment, the system further includes a verification and evidence sealing module, which acquires the necessary interface-level fields and determines the status code set; acquires a status snapshot from the peer system and aligns it with the PST; acquires three samples of the side evidence dual-path and performs median and variance determination; and generates an EvHash and writes it to immutable storage.

[0014] In a preferred embodiment, the system further includes a compensation and rollback module, which acquires the queue to be compensated and calls compensation actions in reverse topology sequence; determines rollback objects based on the PST primary key set; generates shadow state occlusion, freezing and isolation and evidence notes for irreversible objects; and records bypass degradation and reconciliation plans.

[0015] In a preferred embodiment, the system further includes a publishing and fault convergence module and a deep learning decision module. The publishing and fault convergence module acquires the consistency verification completion event and publishes the session handle and evidence chain index; it freezes the mutex resources when the protective shutdown conditions are met; and the deep learning decision module acquires historical and real-time data to generate parameter update instructions.

[0016] The technical effects and advantages of the deep learning-based discipline monitoring system of this invention are as follows: This invention constructs business actions into atomic action graphs and combines them with mutual exclusion matrices for graph rewriting and two-level convergence batching, maximizing parallelism and avoiding resource contention; it generates idempotent tokens using plan fingerprints and, in conjunction with appending only outgoing boxes, enables reuse of first-success receipts and at most one side-effect semantics; it provides a matching set of primary keys through pre-drafting and state transition graphs, allowing for rapid verification of execution prerequisites; it employs a triple verification mechanism at the interface, state, and lateral verification levels, with lateral verification as the veto criterion, enabling rapid loss mitigation in the event of false success or delayed success; and it supports causal rollback executed according to the reverse topology. Minimum necessary compensation limits the impact to the set of state keys related to the failure; evidence sealing generates an evidence chain fingerprint by concatenating receipt fingerprints, state fingerprints, and cross-evidence fingerprints and anchoring it to a trusted time source, combined with lightweight clock calibration, to improve playback consistency and independent auditing capabilities; the deep learning decision module adaptively optimizes timeout, retry and backoff windows, as well as orchestration and cross-evidence thresholds based on historical and real-time observations, to achieve robust scheduling against jitter and load fluctuations, significantly reduce duplicate side effects and false successes, shorten the mean recovery time, and improve evidence playback hit rate and overall maintainability. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a timing diagram of a discipline monitoring system based on deep learning according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0019] Refer to Figure 1 The discipline monitoring system based on deep learning provided by the embodiments of the present invention includes the following functional modules: Session management module.

[0020] This module is responsible for receiving the one-key linkage instruction issued by the user or an external system and generating a unique session identifier for this linkage operation. The generation method of this session identifier is a combination of device identifier, current timestamp, and random entropy source, ensuring its global uniqueness and unpredictability, and is used to track and manage all operations of this session subsequently.

[0021] The session management module will then load the linkage list and action library required for this linkage operation. The linkage list defines all business actions that need to be executed for this one-key linkage. The action library is a core component, which details the interface name, interface version, required parameters, side effect description, and corresponding compensation actions of each executable action. The side effect description is crucial for subsequent causal dependency analysis and rollback strategies, which clarifies the possible impact on the system state after the execution of this action. The compensation action is an operation used to revoke or offset the side effect of the original action.

[0022] At the same time, the session management module will also load a series of policies and constraints, including resource view, mutex matrix, time policy, and log and evidence storage constraints. The resource view provides the current state and allocation of available resources in the system. The mutex matrix defines the mutex relationship between different actions for shared resources. The time policy sets the timeout upper limit, retry count upper limit, retry interval backoff sequence, and cooling time for each type of action, and these parameters are used to control the execution rhythm and exception handling of actions. The log and evidence storage constraints stipulate that all operation logs and evidence must adopt an append-only, retrievable, and replayable storage method to ensure data integrity and auditability. <00,00060>Once all these elements are prepared, the session management module will immediately write a session start log, recording the start time, session identifier, and initial state of this session, serving as the starting point for the entire linkage operation.

[0024] In an optional embodiment, the time policy in the session management module has recommended ranges. For example, the recommended timeout limit for meeting creation is three to five seconds; for intercom activation, it is two to four seconds; for monitoring screen switching, it is one to two seconds; for audio / video recording access, it is three to six seconds; and for displaying announcements, it is one to two seconds. The recommended maximum number of retries is two to three. The retry interval uses an incremental backoff of 200 to 800 milliseconds, meaning the interval between each retry gradually increases to avoid putting excessive pressure on the target system in a short period. The recommended cooldown time for repeated calls on shared devices is no less than one second to prevent overly frequent operations on shared resources.

[0025] In one optional embodiment, specifically, the system collects quantile statistics of session establishment delay distribution, using the 95th percentile of the delay required for successful establishment as an initial value for the action timeout upper limit, and then multiplying it by a safety factor of 1 to 1.5 to obtain the final threshold. The audio-visual synchronization deviation threshold is estimated from the root mean square of the terminal hardware clock drift, and twice the root mean square is taken as the upper limit of the threshold. The number of retries is calculated from the average recovery time of the target system and the backoff sequence, so that the total retry window covers the recovery time interval of the mean plus one standard deviation. This derivation method based on statistics and system behavior analysis ensures the scientificity and adaptability of parameter selection and avoids the uncertainty brought about by empiricism.

[0026] In an optional embodiment, the system adaptively selects the time strategy safety factor and rate window according to the deployment scale. The safety factor ranges from one to one and a half, and the upper limit of the window is dynamically adjusted according to the seven-day rolling quantile and frozen as a constant at the beginning of each session to ensure that the reproduction experiment is comparable under the same conditions.

[0027] The thresholds, windows, and safety factors of this method are all configurable parameters. They can be automatically estimated from historical statistics and then fixed as session constants. The source of the parameters and the freezing point are recorded in the session start log to ensure that the experimental conditions for reproduction are consistent.

[0028] Action graph construction and verification module.

[0029] This module maps the business actions defined in the linkage list to a series of independent action nodes, forming a set of action nodes. For each action node, the module extracts its interface name, interface version, required parameter key set, and compensation action reference. This information forms the basis for building the action graph.

[0030] Based on the input prerequisites and side effect descriptions of each action, the module generates a set of causal dependency edges between action nodes. These dependency edges represent the execution order and logical relationships between actions; for example, the execution of action B depends on the successful completion of action A.

[0031] To ensure the validity of the action graph, the module performs cycle detection and outputs the minimum set of cycles. If a back edge is detected in the graph, indicating a circular dependency, it means that the linkage logic has a deadlock risk or is poorly designed. The module will immediately terminate the current session to prevent entering an unpredictable state.

[0032] For concurrent actions involving shared exclusive resources, the module rewrites the graph based on a mutex matrix. The mutex matrix defines which actions cannot be executed simultaneously. When two concurrent nodes occupy the same exclusive resource, the module adds a causal edge between them, with the edge direction determined by resource priority, thus sequentializing the concurrent operations and avoiding conflicts. If two actions are highly coupled and must occur consecutively, the module merges them into a composite node to reduce the exposure of intermediate states across nodes and simplify management.

[0033] Subsequently, the module performs content addressing hashing using key information such as graph structure, interface version, parameter template, and resource identifier to generate a unique plan fingerprint. This plan hash represents the complete execution plan for this coordinated operation.

[0034] To achieve idempotency, the module generates an idempotency token by performing an irreversible mapping using PlanHash, session identifier, and time window. This idempotency token is used in subsequent execution to ensure that even if requests are sent repeatedly, the target system will only execute the actual side effect once.

[0035] Finally, the module marks all action nodes as "planned" and writes them to the log, recording the construction of the action graph and the generation of PlanHash and idempotent tokens, providing a basis for subsequent execution.

[0036] In an optional embodiment, the mutual exclusion and conflict handling in the action graph construction and verification module adopts a graph rewriting approach. When two concurrent nodes occupy the same exclusive resource, the module adds a causal edge between them according to preset resource priority rules, forcing them to execute sequentially, thereby avoiding resource contention. For example, if action A and action B both attempt to control the same camera, the module adds a causal edge from A to B based on priority, such as A having a higher priority than B, ensuring that B can only execute after A has finished. If two actions are highly coupled and must occur consecutively, such as "open the camera" and "start recording," the module merges them into a composite node, scheduling and executing them as a whole to reduce the exposure and management complexity of intermediate states.

[0037] Pre-check module.

[0038] Before actual execution, this module will conduct a strict triple pre-check to detect and avoid potential execution risks in advance.

[0039] Firstly, there is the contract pre-check: the module will compare the local interface version of each action node with the current version in the registry. If a version inconsistency is found, indicating that the target system interface may have been updated or is incompatible, the module will record the reason for the inconsistency and immediately stop the execution of this session to avoid errors caused by interface mismatches.

[0040] Secondly, there is the permission pre-check: the module will verify the integrity and scope legality of the actual parameters of this session using a parameter template. For example, it checks whether all required parameters have been provided and whether the parameter values are within the allowed range. If there is a situation where a required parameter is missing or the parameter value is out of bounds, the module will stop execution. At the same time, the module will verify the authentication path from the session principal (i.e., the user or system initiating the linkage operation) to the target interface to ensure that the scope and validity period of the token meet the access requirements and prevent unauthorized operations.

[0041] If a permission policy update is detected during the session, the module immediately refreshes the authentication closure and rechecks the authorization path for unexecuted batches. Unauthorized actions do not enter the execution queue to avoid the risk of unauthorized access caused by cross-timezone policy drift.

[0042] The system records the minimized permission evidence, including the authorization policy version number, authorization link hash, and audit label, and does not expose user personal sensitive information fields in the evidence set to meet privacy and compliance requirements.

[0043] Finally, there is the reachability pre-check: the module will send health probes to each target system to collect information such as the heartbeat latency, queue depth, and rate limit window of the target system These information are used to evaluate the health status and processing capacity of the target system.

[0044] Based on the above pre-check results, the module will form a list of executable nodes and a list of reasons for non-execution. If there are any non-executable items, the module will terminate this session and enter the failure convergence path to avoid performing operations that are known to fail.

[0045] In an optional embodiment, the parameter integrity check in the pre-check module is based on strong constraints, that is, the missing required fields are not allowed to be automatically filled with default values and must be provided by the caller. The authentication path from the session principal to the target interface is expanded through a closure check method, that is, recursively checking the permissions of all intermediate links. If the target interface cannot be reached during the expansion process, it is determined as a permission gap and this session is blocked, ensuring the strictness of permission control.

[0046] Orchestration module.

[0047] This module labels each action node with its required resources, mutual exclusion dimensions, and estimated duration, which forms the basis for resource scheduling. Simultaneously, the module sets specific timeout limits, retry limits, backoff intervals, and minimum cooldown times for each type of action; these parameters are used for subsequent execution control.

[0048] Provided that causal dependencies are satisfied, the module performs topological batching. The core idea is to place non-mutually exclusive actions into the same batch for parallel execution to improve efficiency. Mutually exclusive actions are assigned to adjacent batches to ensure they are executed sequentially and avoid conflicts.

[0049] For each generated batch, the module performs rate limit checks and window rebalancing. If the number of actions or resource requirements in a batch exceed the preset rate limit window, the module will move the excess actions to subsequent batches to avoid overloading the target system.

[0050] Finally, the module outputs batch plans and writes them to the log. Each batch plan contains the set of actions to be executed in parallel within that batch, the batch number, threshold conditions, and estimated start and end times. For example, the threshold condition is that the current batch can only start if the previous batch is completely successful.

[0051] In an optional embodiment, the batch orchestration in the orchestration module employs the earliest executable strategy. Among all candidate nodes with an in-degree of zero (i.e., no prerequisites), the module prioritizes nodes that do not conflict with the resources of the current batch and do not trigger the rate cap, placing them into the current batch. When the rate window reaches its limit, the module moves the remaining candidate nodes to the next batch until all nodes are orchestrated.

[0052] To ensure the feasibility of batch orchestration and the robustness of the rebalancing mechanism, this invention introduces a two-level convergence strategy. First-level convergence: If no node can be added to the current batch, the module will roll back the most recently successfully added node and move it to the next batch to ensure the connectivity of batch orchestration and avoid deadlock. Second-level convergence: If the rate window still exceeds the limit after first-level convergence, the module will split the batches according to the window priority of the target system, prioritizing actions that occupy smaller windows to form a "feasible minimum batch". The proof of this strategy is that, under the conditions of a limited number of nodes and a limited window, there always exists a feasible subset selected in ascending window order, thus ensuring that at least one executable batch can be arranged under any circumstances, guaranteeing the determinism and robustness of the orchestration process.

[0053] The rebalancing phase employs a deterministic selection criterion based on window occupancy priority. For the same batch of candidate actions, priority is given to those actions sorted by the amount of window consumption per request in the target system from smallest to largest. When actions with the same level of occupancy occur, they are then selected based on their estimated execution time from shortest to longest. If still the same, they are selected according to the lexicographical order of their action identifiers. Each selected action is updated immediately to the window counters of each target system until all window counts are within limits or the candidate set is empty. The shutdown condition is when the candidate set is empty and still exceeds limits; in this case, the last selected action is rolled back and split into the next batch to ensure convergence.

[0054] Pre-play and status management module.

[0055] To further reduce execution risks and isolate side effects, this module performs pre-execution probing.

[0056] For target systems that support simulation mode, the module sends probing requests that are isomorphic to the actual execution. These requests do not produce any actual side effects, but they do request the target system to return the handle and state to be generated. For example, if "Create Meeting" is executed, the simulation request will return a virtual meeting ID and the expected state.

[0057] For target systems that do not support simulation mode, the module creates a temporary session. This temporary session is marked as recyclable and has a maximum lifespan, and is not visible to the outside world to ensure it does not affect external systems. The temporary session is used to simulate real operation, but its side effects are controllable and cleanable.

[0058] The module connects the expected input states and expected output states of each action to form a complete Expected State Transition Diagram (PST). This diagram includes the name, ownership elements, and validity period information of each state, clearly depicting the final state that the system should reach after the linked operation is successfully executed.

[0059] To ensure that the structured definition of PST can support subsequent accurate verification and compensation, this invention explicitly stipulates that state entries must include the following necessary fields: state name, ownership entity, resource identifier, generation action identifier, validity period start and end, revocability flag, and revocation cost level. Verification and compensation are both based on the primary key combination of the state entry, which is formed by combining the resource identifier and the generation action identifier, ensuring unique identification and accurate matching of states.

[0060] In one optional embodiment, the PST is persisted as a key-value structured carrier. The status primary key is formed by combining the resource identifier and the generation action identifier, and the value field includes fields such as ownership subject, validity period start and end, revocability flag, and revocation cost level. The system generates a PST version number for each session and binds it to the PlanHash to form an index key group. During execution, the session identifier and PST version number are used as query prefixes to retrieve the corresponding entries, ensuring that verification and compensation can be completed within sub-millisecond retrieval latency.

[0061] When log replay is inconsistent with PST, the primary key alignment result of PST is used as the standard for rollback and verification, and the hash and time point of the inconsistency are recorded in the EvHash extension field to ensure audit traceability.

[0062] The module verifies whether all preconditions are met based on the trial results. For example, it checks whether the simulated resources were created successfully and whether the expected state matches the actual simulation results. If any preconditions cannot be met, the module will terminate execution and enter the failure convergence path to avoid executing operations that are known to fail.

[0063] Finally, the module will write a pre-run log, recording the list of handles to be generated, the source actions, and the target system, providing a basis for subsequent real execution and consistency verification.

[0064] In an optional embodiment, the pre-simulation phase of the pre-simulation and state management module creates a temporary session for systems that do not support simulation and sets a maximum lifespan. This temporary session is not visible externally, and any side effects it produces are confined to the temporary session. If any subsequent verification fails, the module will automatically reclaim the temporary session and clean up its shadow states upon expiration, ensuring that no residue is left. The PST records the name, ownership elements, and validity period of each state. Subsequent consistency verification and compensation actions are based on this diagram, ensuring the accuracy of state management.

[0065] Execution and idempotency control module.

[0066] This module writes the request body, batch number, and idempotency token for each action to an out-of-band delivery box and marks the status as "pending delivery." The out-of-band delivery box serves as a temporary storage area for requests, ensuring reliable delivery of requests.

[0067] The module will strictly read requests according to the batch number and trigger all actions within the same batch in parallel.

[0068] Upon receiving a request, the target system uses an idempotent token for deduplication. If the target system detects that the received idempotent token is the same as a token that has been successfully processed previously, it will directly return the digest of the first successful receipt without repeating the actual side effect, thus ensuring the "at most once" side effect semantics.

[0069] The module performs strict sequential control between batches, meaning that the next batch of actions is not started until all actions in the previous batch have succeeded, thus ensuring the correct execution of dependencies.

[0070] For actions that time out, the module will retry a limited number of times, employing an incremental backoff strategy, meaning the interval between each retry gradually increases. If the number of retries exceeds the limit, the module will determine that the action has failed and stop executing subsequent batches, entering the failure convergence path.

[0071] The module writes the receipt status code, receipt fingerprint, timestamp, and target resource index to the receipt digest in real time. This information is an important component of subsequent verification and evidence preservation. When all receipts for an action meet the pre-verification requirements (e.g., a status code indicating success), the module will mark the action as a "candidate completion" status.

[0072] In an optional embodiment, the outgoing box in the execution and idempotency control module adopts an append-only structure, where each delivery is written to the database using an idempotency token as the primary key. The target system uses the idempotency token for deduplication. When network jitter and retries occur, the target system returns the fingerprint of the first successful acknowledgment, thereby ensuring that there are no side effects such as duplicate database writes and repeated switching, and ensuring the idempotency of the operation.

[0073] Verification and evidence sealing module 700.

[0074] This module performs strict triple verification on actions marked as "candidate completed" to ensure that they are actually effective and reach the expected state.

[0075] The first layer is interface-level verification: checking whether the required fields are complete in the receipt returned by the target system, and whether the status code belongs to the success set.

[0076] The second layer is state-level verification: the module will actively query the peer system for the actual state of the target object and check it against the expected state in the PST generated in the pre-play and state management module.

[0077] The third layer is lateral verification: the module collects locally observable evidence to verify the actual effect of the operation from another dimension. This includes media stream connectivity, such as whether the video conference was successfully established; audio-visual synchronization deviation, such as whether the audio and video are synchronized; and physical feedback from the display device, such as whether the display screen lights up as instructed. These indicators are all judged using deterministic thresholds. For example, it is recommended that the media stream establishment time not exceed three seconds, the audio-visual synchronization deviation not exceed eighty milliseconds, and the display device lighting feedback arrive within one second.

[0078] The evidence collection process employs dual-path redundancy and a majority decision based on three samplings. When the indicators from the two pathways are inconsistent, the module uses the one with the larger deviation as the rejection criterion to reduce the risk of false negatives.

[0079] The sampling window for evidence is one to two seconds. The median and variance of three samples within the time window are used as the basis for decision-making. When the variance is higher than the threshold, it is considered that the pathway is unstable and triggers pathway reconstruction.

[0080] To address the potential uncertainty in decision-making when multiple sources of information conflict, this invention specifies the decision-making order and convergence rules for triple consistency verification. Interface-level verification is considered a necessary but not sufficient condition, meaning interface success is a prerequisite for further verification. State-level verification is a sufficiency test, used to confirm whether the target object has reached the expected business state. Evidence-level verification is a rejection test; failure of any evidence-based verification directly rejects the success of the action, even if interface and state verifications pass. Only when both interface success and state success are true, and all evidence-based verifications are true, is the action considered fully successful and enters the evidence sealing queue. This invention also defines an anomaly classification table, such as false success, delayed success, missing evidence, and unqueryable state, and defines corresponding handling paths for each anomaly, ensuring the certainty of decision-making and the standardization of anomaly handling.

[0081] Anomaly classification and handling mapping are implemented using a table-driven approach. False success is mapped to rollback priority and freeze option; delayed success is mapped to extended waiting window and secondary evidence collection; missing evidence is mapped to device self-test and path reconstruction; and unqueryable status is mapped to redundant query on the peer end and cache invalidation refresh. Each anomaly type defines timeout limits, retry limits, and upgrade routing groups to ensure a unique and auditable adjudication path.

[0082] If all three verifications pass, the module will add the action to the evidence sealing queue. The module will concatenate the receipt fingerprint, cross-examination fingerprint, and timeline summary using content addressing to generate a unique session evidence chain fingerprint (EvHash), and write it to immutable storage to ensure the integrity and immutability of the evidence.

[0083] If any validation fails, the module will add the action to the compensation queue and record the inconsistency type and location information. Simultaneously, the module will immediately block all subsequent nodes that depend on this action to prevent further spread of the error.

[0084] In an optional embodiment, the triple verification in the verification and evidence sealing module sets fixed thresholds. For example, the media stream setup time is no more than three seconds, the audio-visual synchronization deviation is no more than eighty milliseconds, and the display device power-on feedback latency is no more than one second. If any of these three indicators is not met, it is considered an inconsistency, and the action is entered into a compensation queue. The module simultaneously blocks all subsequent nodes that depend on this action, ensuring the rigor of verification and timely mitigation.

[0085] Compensation and rollback module 800.

[0086] When an action enters the "compensation queue", this module will initiate a deterministic compensation and rollback process.

[0087] For each action in the compensation queue, the module performs a reverse topological traversal along the upstream direction of the dependency graph, and combines the state keys recorded in the PST to accurately collect the set of all upstream actions that must be rolled back. This means that not only the failed actions themselves are compensated, but also all the preceding actions that caused inconsistencies in state due to their failure are compensated, ensuring the causal consistency of the compensation.

[0088] When there is a partial deviation between the PST and the peer's state and it does not affect the downstream security premise, the module triggers the "minimum necessary compensation" strategy, only rolling back the set of primary keys of the failed alignment, avoiding excessive rollback to irrelevant resources.

[0089] The module will invoke the compensation actions for these actions one by one in the reverse order of execution. If the target system provides an explicit undo interface, the module will directly invoke that undo interface.

[0090] To address edge cases of causal rollback, particularly irreversible actions and cross-session dependencies, this invention introduces a degradation strategy for irreversible actions. This strategy comprises three parts: 1. Shadow State Masking: Marking irreversible objects as invisible and creating alternative resources to ensure subsequent sessions do not conflict with them, achieving logical isolation. 2. Freezing and Isolation: Locking relevant resources and generating a sequence of suggested manual actions to guide operations personnel in manual intervention and recovery. 3. Evidence-Based Notes: Writing the irreversibility flag, cause, and scope of impact into the extended field of EvHash to ensure the visibility and traceability of these special cases during post-event auditing.

[0091] If the target system does not provide an undo interface, the module will perform shadow state cleanup (e.g., clearing temporary states in the local cache) and output manual handling suggestions to guide operations and maintenance personnel to intervene manually.

[0092] When a target system becomes unreachable for an extended period of time, the module enters a bypass degradation mode, replacing it with local buffering actions and delayed reconciliation. At the same time, the reason for degradation and the compensation plan are recorded in the EvHash extended field.

[0093] After each compensation operation is completed, the module writes a compensation receipt summary and a supporting evidence summary, and marks the action as compensated in the log for subsequent auditing.

[0094] If an object cannot be compensated, such as a target system that is permanently offline or the compensation operation itself fails, the module will immediately enter a frozen state, generate a minimum set of evidence, and send an alarm, waiting for manual intervention.

[0095] In an optional embodiment, causal rollback in the compensation and rollback module is performed in reverse topology sequence, i.e., first undoing the last action, then its immediate upstream, until the system is restored to the safety boundary. When the target system does not provide an undo interface, the module achieves a closed loop through a combination of shadow state cleanup and manual handling suggestions, ensuring effective rollback even in extreme cases. A summary of the receipt and supporting evidence after each compensation is written to the log for auditing and review.

[0096] Release and fault convergence module.

[0097] Once all actions have passed the consistency verification and evidence sealing module and the evidence sealing is completed, it indicates that the one-click linkage operation has been successfully and atomically completed. This module will publish the overall result externally in the form of a session handle. External systems can obtain a complete evidence chain summary through this session handle for querying and auditing.

[0098] If any step fails and cannot be recovered through the compensation and rollback modules, the module will immediately enter a failure convergence state. In this state, the module will freeze all relevant resources and prohibit new operations from entering to prevent the problem from escalating further.

[0099] The module will export a minimal evidence set, containing key information sufficient to support post-event auditing and liability determination, and send alerts to relevant personnel. Simultaneously, the module will provide suggested remedial procedures and precautions, including replay recommendations (if conditions permit), manual reversal recommendations, and a checklist of access checks for re-execution, guiding operations personnel in fault recovery.

[0100] When a session fails to converge three times consecutively and points to the same target system, the module enters a protective shutdown, freezes relevant mutually exclusive resources, and publishes a recovery list. The recovery list includes manually verified items and replay preconditions to avoid oscillations.

[0101] In an optional embodiment, the minimum evidence set in the release and fault convergence module includes receipt fragments, cross-cutting snapshots, resource lists, and session timelines. This evidence set is sufficient to support post-event auditing and liability determination. The module provides session handles and evidence chain fingerprint indexes, allowing auditors to quickly replay and verify data, greatly improving the system's auditability and traceability.

[0102] To ensure the minimum completeness of the evidence chain and logs, this invention explicitly lists a minimum set of fields, including: action identifier, batch number, idempotent token, peer receipt fingerprint, peer state snapshot fingerprint, side evidence fingerprint, timeline relative sequence number, execution node clock calibration offset, and execution node version number. These fields are sufficient to uniquely reconstruct the verifiable process of an action, eliminating the risk of "incomplete proof chain" during future review.

[0103] During evidence sealing, the system concatenates the receipt fingerprint, status snapshot fingerprint, and cross-examination fingerprint in a fixed order and performs content addressing by combining them with the relative sequence number of the session timeline to generate an EvHash. During playback by the auditing end, the EvHash is used to reverse-parse the fields and verify fingerprint matching item by item. If any field verification fails, the system marks the evidence as suspicious and triggers a re-evidence collection process, ensuring the consistency of the evidence chain and its independent verification.

[0104] EvHash writes to append-only media with sequence numbers and periodically anchors to checkpoints from trusted time sources. Checkpoint summaries are archived independently for post-hoc external consistency comparisons.

[0105] To ensure consistency in the evidence timeline, the system performs a lightweight clock calibration before each session begins. The edge and orchestration ends employ a dual-channel calibration using unidirectional delay measurement combined with round-trip time estimation. The median of the two measurements is used as the offset estimate, and a calibration offset field is appended to each log entry. When the offset exceeds a preset threshold, execution is rejected and the node is required to reset. This approach ensures that timestamps from different nodes can be restored to a unified time base within the error limit, facilitating evidence playback and causal ordering.

[0106] Deep learning decision-making module.

[0107] This module is the core of the system's intelligent decision-making and adaptive capabilities. It builds and optimizes deep learning models by continuously learning and analyzing historical execution data, real-time system status, environmental parameters such as network latency, device load, resource availability, and external feedback information.

[0108] Specifically, the deep learning decision module can: Optimize timing strategy parameters: Based on historical execution success rate, timeout distribution, retry effect and other data, dynamically adjust the timeout limit, retry limit and retry interval backoff sequence of each type of action in the session management module to adapt to the best execution strategy under different scenarios and system loads.

[0109] Assisted resource orchestration decision-making: Combining the resource view and mutual exclusion matrix of the orchestration module, the deep learning model predicts future resource requirements and conflict probabilities, providing the orchestration module with better batching strategies and resource allocation suggestions to maximize parallelism and minimize conflicts.

[0110] Intelligent anomaly handling suggestions: By analyzing historical anomaly types, frequency of occurrence, and handling results, it provides more accurate remediation sequences and precautions for the release and fault convergence modules, and can even predict potential fault modes and provide early warnings.

[0111] Adaptive cross-verification threshold: Based on the distribution of cross-verification data under different devices and environments, the cross-verification threshold in the verification and evidence sealing module is dynamically adjusted to improve the accuracy and robustness of verification and reduce false alarms and false negatives.

[0112] Risk prediction and early warning: Continuously monitor the system's operating status, use deep learning models to identify potential risk patterns, such as an impending overload of a target system or severe network fluctuations, and issue early warnings to relevant modules in advance so that execution strategies can be adjusted or degradation measures can be initiated in a timely manner.

[0113] The key parameters and engineering boundaries of this application are as follows: The number of concurrent encoder instances should match the number of cameras to ensure video stream processing capabilities. The display bus can only serve one screen-fixing or announcement action at a time to avoid display conflicts. The network egress bandwidth should be estimated before batch orchestration, with a minimum and maximum value provided to ensure sufficient network resources. Log fields should include action identifier, batch number, idempotent token, timestamp, target system, status code, receipt fingerprint, cross-verification fingerprint, and inconsistency type to provide comprehensive tracking information. The evidence chain index is generated by content addressing of the action sequence, timeline, and fingerprint sequence to ensure the uniqueness and retrieval of the evidence chain. The above parameters and boundaries can be adjusted proportionally according to the deployment environment, provided that the four constraints of idempotency, atomicity, rollback, and traceability are not violated.

[0114] This method can be deployed in a hybrid manner across private clouds, remote clouds, and edge nodes, without relying on a specific hardware instruction set; when the network uses any of the QUIC, HTTP2, or WebSocket protocol stacks, the outgoing box and idempotency are established.

[0115] Through the above implementation methods, the deep learning-based discipline monitoring system of this invention employs a continuous mechanism of structured verification, deterministic orchestration, idempotent control, consistency review, causal rollback, and evidence sealing, supplemented by the intelligent decision-making capabilities of deep learning, to ensure the reliable implementation and long-term maintainability of the one-click linkage process. The above modules can be deployed in the discipline desk operating system, platform-side orchestration service, or backend process, without limitation.

[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

[0117] It should be noted that, for the sake of brevity, the foregoing method embodiments are described as a series of actions, but this does not mean that the application limits the order of the steps. Based on the ideas of this application, some steps can be executed in different orders or in parallel without affecting the functional implementation. Secondly, those skilled in the art should also understand that the specific embodiments described in the specification are preferred embodiments of the technical solutions of this application, and not limitations on the scope of protection of this application. All equivalent improvements or substitutions made within the spirit and principles of this application should be covered within the scope of protection of this application.

[0118] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A deep learning-based discipline monitoring system, characterized in that, include: The session management module is used to obtain session identifiers, linkage lists, and action libraries; obtain resource views, mutual exclusion matrices, time policies, and evidence storage constraints; and obtain session start log entries. Session identifiers are used for subsequent full-link associations, and linkage lists and action libraries are used to limit the set of actions to be executed and parameter templates. The action graph construction and verification module is used to generate atomic action graphs containing causal dependencies and mutual exclusion constraints, generate plan fingerprints and idempotent tokens, generate planned status markers and corresponding logs, and calculate the plan fingerprint based on the graph structure, interface version, parameter key and resource identifier. The idempotent token is bound to the session identifier and time window. The pre-inspection module is used to determine the consistency of the interface contract and the accessibility of the permission path, determine the set of executable nodes and the list of reasons for non-executability, determine the validity of the authorization closure after the session mid-segment policy update, and determine the expansion based on parameter templates, registry and health probe results; The orchestration module is used to calculate topology batching and rate window rebalancing and form batch plans, calculate the parallel set, threshold conditions and expected timing within a batch, calculate window occupancy priority and deterministic selection sequence and record batch numbers, and calculate with atomic action graphs, mutual exclusion matrices and resource views as constraints. The execution and idempotency control module is used to output out-of-band request and batch output idempotency tokens to the target system, output receipt summary and candidate completion flag, output interface-level, status-level and side-evidence-level verification results and output session evidence chain fingerprints, and associate the evidence chain fingerprints with the timeline relative sequence number and fingerprint sequence.

2. The deep learning-based parenting monitoring system according to claim 1, characterized in that: The session management module obtains the device identifier, timestamp, and random entropy source to generate a session identifier; obtains the interface name, interface version, required parameters, and compensation actions of the action library; and obtains the session start log and writes it to the session identifier, linkage list identifier, and parameter source.

3. The deep learning-based parenting monitoring system according to claim 1, characterized in that: The action graph construction and verification module obtains the action input prerequisites and side effect descriptions to generate causal dependency edges; rewrites the graph of concurrent nodes based on the mutual exclusion matrix; calculates the plan fingerprint; and calculates the idempotent token based on the plan fingerprint, session identifier, and time window.

4. The deep learning-based discipline monitoring system according to claim 3, characterized in that... ； It also includes a pre-inspection module, which obtains the contract pre-inspection results and compares the local interface version with the registry version; obtains parameter templates and determines the completeness and value range of required fields; expands the authentication path from the session subject to the target interface; and obtains health probes to form an executable node list.

5. The deep learning-based discipline monitoring system according to claim 4, characterized in that: The orchestration module acquires atomic action graphs and resource views to perform topology batching; acquires rate limit windows and performs window rebalancing; generates batch plans and records parallel sets, threshold conditions, expected timings, and batch numbers. The target system window counter is updated during the selection process.

6. The deep learning-based discipline monitoring system according to claim 5, characterized in that: It also includes a rehearsal and state management module, which obtains the return handle of the target system that supports the simulation; generates a temporary session for the target system that does not support the simulation; generates a PST and records the state name, ownership subject, resource identifier, generation action identifier and validity period; And write it into the rehearsal log.

7. The deep learning-based discipline monitoring system according to claim 6, characterized in that: The execution and idempotency control module acquires batch plans and reads out-of-band dispatch requests in batches; outputs idempotency tokens to the target system and performs a limited number of retries and backoffs; acquires receipt status codes and receipt fingerprints to form receipt digests; and acquires candidate completion flags that meet the pre-verification requirements.

8. The deep learning-based discipline monitoring system according to claim 7, characterized in that: It also includes a verification and evidence sealing module, which obtains the necessary fields at the interface level and determines the status code set; obtains a status snapshot from the peer system and aligns it with the PST; obtains three samples of the dual-path side evidence and performs median and variance determination; and generates EvHash and writes it to immutable storage.

9. The deep learning-based discipline monitoring system according to claim 8, characterized in that: It also includes a compensation and rollback module. The compensation and rollback module obtains the queue to be compensated and calls the compensation action according to the reverse topology sequence; determines the rollback object based on the PST primary key set; generates shadow state occlusion, freezing and isolation and evidence notes for irreversible objects; and records bypass degradation and reconciliation plans.

10. The deep learning-based discipline monitoring system according to claim 9, characterized in that: It also includes a publishing and fault convergence module and a deep learning decision module. The publishing and fault convergence module obtains the consistency verification completion event and publishes the session handle and evidence chain index; when the protective shutdown conditions are met, it freezes the mutex resources. The deep learning decision module acquires historical and real-time data to generate parameter update instructions.

Images