General auditing and punishment system for live auditing platform

Abstract

The invention relates to a universal auditing and punishment system for a live auditing platform. The system comprises the following steps: carrying out expansion modeling on reason configuration, and newly adding an ext field in a reason table to generate a configured JSON strategy; the dynamic punishment interpretation execution engine carries out structured strategy interpretation on the configured JSON strategy and executes related punishment operation; searching the configured JSON strategy corresponding to the reason when the user triggers violation, counting the violation times in a configuration period, indexing corresponding operation according to the violation times, and executing role linkage punishment action; and managing the violation frequency of the user in a specified time window, and dynamically executing multi-level punishment actions according to the frequency. By adopting the system, the problems of single punishment means, poor expansibility, redundant configuration, untimely response and the like under a traditional reason-operation static binding mechanism can be solved.

Description

Technical Field

[0001] The present application relates to the field of content review and content security technology, and in particular to a universal review and punishment system for a live broadcast review platform. Background Art

[0002] Most technologies in the current industry still rely on static configuration and rule engines, with weak support for dynamic demands and complex penalty chains, and lack of flexible multi-role linkage mechanisms and data-based real-time optimization capabilities.

[0003] However, current live broadcast review technology has the following problems: it relies on fixed rules, cannot dynamically adjust strategies, cannot gradually upgrade penalties based on the number of user violations, cannot synchronously handle related violations between anchors and viewers, and lacks a visual interface and real-time optimization mechanism. Summary of the Invention

[0004] Based on this, it is necessary to address the above technical issues and provide a universal review and punishment system for live broadcast review platforms that can solve the problems of single punishment means, poor scalability, redundant configuration, and untimely response under the traditional "reason-operation" static binding mechanism.

[0005] A universal review and punishment system for a live broadcast review platform, comprising: a reason configuration extension module, a dynamic penalty interpretation and execution engine, a universal penalty status module, and a cooling period and step-by-step timing scheduling module; The reason configuration extension module is used to extend the modeling of reason configuration, add the ext field in the reason table, support structured JSON data, and generate configuration JSON policies; The dynamic penalty interpretation and execution engine interprets the configured JSON policy and executes relevant penalty operations; The general penalty status module is used to find the configured JSON policy corresponding to the reason when a user violation is triggered and count the number of violations within the configuration period. It then indexes the corresponding operation based on the number of violations and executes the role-linked penalty action. The cooling-off period and stepped timing scheduling modules are used to manage the frequency of user violations within a specified time window and dynamically execute multi-level penalty actions based on the frequency.

[0006] This application addresses the aforementioned universal review and penalty system for a live broadcast review platform. This application establishes a reason configuration extension module that supports structured JSON data through a new ext field, generating configurable JSON policies. When faced with new violation scenarios or penalty requirements, review and penalty capabilities can be rapidly expanded by simply modifying or adding JSON policies, without requiring large-scale changes to the underlying code. This significantly improves system adaptability. The dynamic penalty interpretation and execution engine interprets the configured JSON policies in a structured manner. This JSON-policy-centric configuration approach manages rules and actions in a structured, lightweight data storage, avoiding the duplication and waste associated with traditional separate configuration of each "reason-action" combination, achieving streamlined and efficient configuration. Furthermore, a universal penalty status module is integrated with the cooldown period and tiered timer scheduling modules, breaking the traditional fixed operation model. The system can dynamically execute role linkage and multi-level penalty actions based on the number and frequency of violations, changing the previous practice of using a single penalty method regardless of the violation to a more diversified, graded approach. The reason configuration extension module supports structured JSON data through a new ext field, generating configurable JSON policies. When faced with new violation scenarios or penalty requirements, simply modifying or adding JSON policies without making large-scale changes to the underlying code allows for rapid expansion of review and penalty capabilities, significantly improving system adaptability. The dynamic penalty interpretation and execution engine provides structured interpretation of configured JSON policies. This JSON-based configuration approach manages rules and actions in a structured, lightweight data store, avoiding the duplication and waste associated with traditional separate configuration of each "reason-action" combination, and achieving streamlined and efficient configuration. This effectively addresses the shortcomings of traditional mechanisms, significantly improving the flexibility, management efficiency, and execution effectiveness of the live broadcast review platform's penalty policies, and possesses high practical value. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A schematic diagram of a flow chart of a universal review and punishment system for a live broadcast review platform in one embodiment; Figure 2 A schematic diagram of a list of reasons in one embodiment; Figure 3 FIG. 1 is a schematic diagram of a configuration of a ground plane in an embodiment. DETAILED DESCRIPTION

[0008] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0009] In one embodiment, Figure 1As shown, a universal review and punishment system for a live broadcast review platform is provided, comprising: a reason configuration extension module 102, a dynamic punishment interpretation and execution engine 104, a universal punishment status module 106, and a cooling period and step-by-step timing scheduling module 108; The reason configuration extension module 102 is used to extend the reason configuration model, add an ext field in the reason table, support structured JSON data, and generate a configuration JSON strategy; the reason list is as follows: Figure 2 As shown, the reason configuration is as follows Figure 3 shown.

[0010] The dynamic penalty interpretation and execution engine 104 performs structured policy interpretation on the configured JSON policy and executes relevant penalty operations; The general penalty status module 106 is used to find the configured JSON policy corresponding to the reason when a user violation is triggered and count the number of violations within the configuration period. It then indexes the corresponding operation based on the number of violations and executes the role-linked penalty action. The cooling-off period and stepped timing scheduling module 108 is used to manage the frequency of user violations within a specified time window and dynamically execute multi-level penalty actions based on the frequency.

[0011] In the universal audit and penalty system for a live broadcast audit platform described above, the reason configuration extension module 102 extends the modeling of the reason configuration, adds a new ext field to the reason table, supports structured JSON data, and generates a configured JSON policy. This approach frees the system from being limited to preset, limited rules. When new violation scenarios or new penalty requirements arise, the system's audit and penalty capabilities can be rapidly expanded simply by modifying or adding JSON policies, without requiring large-scale changes to the underlying code. This significantly improves the system's scalability in the face of complex and changing requirements, overcoming the difficulty of traditional static binding mechanisms in adapting to new situations and requirements. The dynamic penalty interpretation and execution engine 104 performs structured policy interpretation on the configured JSON policy. This configuration approach, centered around JSON policies, stores and manages complex rules and operations in a structured, lightweight data format. Compared to traditional static binding mechanisms, where each "reason-action" combination requires separate configuration, this system reduces a significant amount of duplicate and similar configuration content, achieving streamlined and efficient configuration utilization, and avoiding management confusion and resource waste caused by configuration redundancy. The general penalty status module 106 and the cooling-off period and stepped timing scheduling module 108 work together to break the traditional static binding fixed operation mode. When a user violation is triggered, the general penalty status module 106 will search for the configured JSON policy corresponding to the reason and count the number of violations. According to the index of the corresponding operation based on the number of violations, it can realize the role-linked penalty action; the cooling-off period and stepped timing scheduling module 108 manages the frequency of user violations within the specified time window and dynamically executes multi-level penalty actions based on the frequency. The system can execute diversified and graded penalties according to the specific circumstances of the violation, changing the situation under the traditional mechanism where the penalty means are always single regardless of the degree and frequency of the violation. The dynamic penalty interpretation and execution engine 104 can quickly interpret the configured JSON policy and execute relevant penalty operations. The general penalty status module 106 and the cooling-off period and stepped timing scheduling module 106 can monitor the violation in real time and dynamically execute penalty actions. The system can perceive violations in real time, respond quickly based on dynamic strategies, and execute corresponding penalties in a timely manner. Compared with the traditional static binding mechanism that requires manual intervention or handles violations according to fixed cycles, it greatly improves the response speed, ensures timely control of violations, and greatly improves the flexibility, management efficiency and execution effect of the penalty strategy of the live broadcast review platform, and has high practical value.

[0012] In one embodiment, the ext field includes custom operation logic, cooling cycle, step-by-step penalty list, maximum number of warnings, prompt method and role linkage; the configured JSON policy includes multiple fields, among which the custom_operation field is a required field, which contains the penalty policy configuration; the stat_day field is a required field, which indicates the number of days in the cooling cycle. The system counts the user's violations during this period; the operation array is a required field, which indicates the sequential configuration of step-by-step penalty actions. Each item is an operation object, which includes a type field. Some operations additionally include a duration field. The max_warn_num field is an optional field, which indicates the maximum number of "warning" operations to be issued. After exceeding the limit, the subsequent operation will be directly executed. The live_send_message_type field is optional and indicates the live broadcast prompt method. 1 indicates a pop-up window, 2 indicates a private message, and 3 indicates a pop-up window + a private message. The customized_black_user field is optional and has a Boolean value. True indicates that the user will be added to the personalized blacklist system. The black_host field is optional and has a Boolean value. True indicates that the host or anchor will be punished simultaneously. The relation_with_host field is optional and has a string value. It defines the punishment linkage logic for viewers and anchors.

[0013] In a specific embodiment, the operation type type corresponding to the penalty policy configuration is an integer field, which indicates the penalty action type, specifically including: type: 1, indicating "warning", which is used to issue a violation prompt to the user; type: 2, indicating "blacklist", which adds the user to the blacklist and restricts access rights; type: 3, indicating "blocking / removing the microphone", which is used to interrupt speaking or broadcasting during the live broadcast; type: 4, indicating "deletion", which is used to delete the illegal content posted by the user; type: 5, indicating "account ban", which prohibits the user account from logging in or using; type: 6, indicating "marking", which adds the user to the key attention list; type: 7, indicating "review and blacklist", which means that the violation information is submitted for review first and then blacklisted; type: 11, indicating "mute", which prohibits the user from speaking; type: 16, indicating "black screen", which forces the screen to be black during the live broadcast; type: 17, indicating "restrict live broadcast", which prohibits the user from starting the live broadcast; type: 18, which indicates "add review successfully", which marks that the penalty has passed manual review. Among them, operations such as type 2, 5, and 17 require additional configuration of the duration field, which indicates the duration of the penalty in hours and supports decimal points.

[0014] The extended field configuration system breaks through the traditional fixed pattern of a single reason corresponding to a single penalty, and adopts a structured JSON storage method to realize the dynamic definition and flexible expansion of the penalty strategy. It is compatible with the old logic and supports multi-parameter, multi-role, and multi-stage penalty configuration, which greatly improves the platform's response capabilities and management accuracy for complex violations. Through real-time analysis and scheduling, the intelligence and automation level of the system are significantly enhanced. This configuration system enables the live broadcast platform to flexibly and quickly adjust and optimize the penalty strategy based on a unified data structure, and new strategies can be launched without code changes, effectively reducing operation and maintenance costs. At the same time, precise multi-dimensional configuration ensures the fairness and rationality of penalties, improves user experience and platform content security management efficiency, and meets the complex and changing content review needs in large-scale, high-concurrency live broadcast scenarios.

[0015] The following are examples: Assuming the reason is "abusive behavior in the live broadcast room", the JSON configuration is as follows: ```json { "custom_operation": { "stat_day": 1, "operation": [ {"type": "1"}, {"type": "2", "duration": "0.001"}, {"type": "2", "duration": "1"}, {"type": "2", "duration": "3"}, {"type": "5"} ] }, "max_warn_num": 1, "live_send_message_type": 3, "black_host": true, "relation_with_host": "first_all_then_host" } This configuration example is an extended configuration of a generalized penalty policy for a specific violation reason in the live broadcast review platform. It includes multi-dimensional parameter settings. The specific rules and meanings are as follows: custom_operation (custom operation configuration): stat_day = 1: Sets the cooldown period to 1 day. This means that within a single day, the system will accumulate the number of violations for this reason and apply tiered penalties accordingly. After the cooldown period, the violation count will reset.

[0016] Operation (operation list): defines the specific penalty steps, which are triggered in the order of the number of violations: First violation: type is "1", which means a "warning" action is issued.

[0017] Second violation: type is "2", which means executing the "blacklist" operation, which lasts for 0.001 hours (about 3.6 seconds) and is used to temporarily block user behavior.

[0018] Third violation: Same as “blacklisting”, but the duration is extended to 1 hour and the punishment is strengthened.

[0019] Fourth violation: Continue to enforce "blacklisting" for 3 hours and further increase the penalty.

[0020] Fifth violation: Execute the "account blocking" operation (type is "5"), which prohibits the user from logging in and implements the highest level of punishment.

[0021] max_warn_num = 1: sets the maximum number of warnings to 1. That is, during this cooling-off period, only one warning will be issued at most to avoid a decline in user experience or an increased burden on reviewers due to multiple warnings.

[0022] live_send_message_type = 3: Sets the violation notification sending method to "private message + pop-up window" dual prompts to ensure that users can receive violation notifications in a timely and clear manner, improving the coverage and effectiveness of information communication.

[0023] black_host = true: This policy applies to linked penalties, and the host (or streamer) of the offending user's livestream will also be penalized. This mechanism ensures the safety of the livestream and prevents the host from causing disruptions to the overall order of the livestream.

[0024] relation_with_host = "first_all_then_host": This parameter defines the linkage relationship between the punishment strategy between the anchor and the user. That is, the first punishment will punish both the anchor and the violating user at the same time, and subsequent punishments will only be implemented against the anchor. This reflects the dynamic linkage punishment strategy of the master and slave roles, effectively balancing the intensity of punishment and platform operation management.

[0025] In summary, this configuration enables dynamic execution of multi-step tiered penalties, effectively preventing excessive penalties through a cool-down period. It also supports multi-channel violation alerts and a master-slave role-based penalty mechanism, meeting the complex and ever-changing content review and management needs of live streaming platforms. This configuration allows the platform to flexibly adjust the severity and scope of penalties at different stages, improving review efficiency and management accuracy.

[0026] In one embodiment, the dynamic penalty interpretation and execution engine is also used to perform syntax parsing and structural verification on the custom_operation field in the configured JSON policy, build a memory-level policy tree, determine the cooling-down period based on the stat_day field, and read the user's historical violation count through the middleware; select the corresponding penalty action from the operation array by index based on the user's current trigger count, and check the type legitimacy and required field integrity; encapsulate the penalty action into an operation task, complete the specific execution by calling the corresponding module through the unified scheduling center, and record the audit log.

[0027] In a specific embodiment, after the platform review system receives a violation event, the system retrieves the corresponding reason table record based on the event meta-information, such as the violating user ID, live broadcast room ID, and reason code, and extracts the JSON configuration in the ext field; the engine performs syntax parsing and structural verification on the custom_operation field in the JSON to build a memory-level policy tree; the cooling period is determined based on the `stat_day` value in the configuration, and the number of historical user violations is read through middleware such as Redis; based on the current number of user triggers, the corresponding penalty action is selected from the `operation` array by index, and the legality of the type and the integrity of required fields, such as duration, are checked; the penalty action is encapsulated into an operation task, and the corresponding module is called through the unified scheduling center, including the blacklist service, the mute service, and the notification service, to complete the specific execution and record the audit log.

[0028] In one embodiment, the dynamic penalty interpretation and execution engine is further used to map the operation types in the penalty policy configuration to achieve new operation types after operation decoupling.

[0029] In this specific embodiment, the engine maintains a mapping table from "type → executor". Each operation type has a corresponding executor: for example, type:2 maps to `GlobalBlockExecutor(duration)`, type:5 maps to `BanAccountExecutor`, and type:1 maps to `WarningExecutor(msg_type)`.

[0030] This decoupled structure supports the subsequent addition of new operation types, requiring only the expansion of the registry and corresponding processing logic.

[0031] In one embodiment, the dynamic penalty interpretation and execution engine is further configured to use a cooling period counting and a double-layer bucket counting strategy to accurately record the number of hits in the cooling period of stat_day and ensure periodic cleanup to avoid state drift.

[0032] In a specific embodiment, if `black_host: true` is set and the host and viewer are bound, the engine will add a penalty action for the host during the scheduling phase. If the `max_warn_num` threshold is reached, the engine will skip the type:1 warning type and proceed to the next penalty action. If there are syntax errors or missing fields in the JSON, the engine will return an error status and refuse to execute to prevent system abnormalities.

[0033] In one embodiment, the general penalty status module includes a status enumeration definition module, a status transition linked list module, a penalty action binding module, a status scheduling engine and a status rollback mechanism module; the status enumeration definition module is used to predefine multiple penalty statuses, including normal, warning, blacklist, ban, account suspension and waiting for review; the status transition linked list module is used to bind a state transition path to each penalty reason, and migrate to the next state after each trigger; the penalty action binding module is used to bind the corresponding operation type and parameters to each state transition node to realize the modularization of operation behavior; the status scheduling engine is used to schedule the transfer logic and update the user status in real time according to the user's current status, historical trigger times and violation frequency during the cooling period; the status rollback mechanism module is used to provide a manual intervention interface, and in the event of a misjudgment, roll back to the previous state and cancel the corresponding penalty operation.

[0034] In one of the embodiments, the general penalty status module is also used to trigger the system processing flow when a user violates the rules to find the corresponding configured JSON policy, count the number of violations of the user within the configuration period, index the corresponding operation according to the number of times, and execute the penalty action. If the penalty is time-sensitive, the expiration time is recorded and the unscheduling task is arranged; if the penalty is linked, the penalty is synchronized and the status is updated synchronously; after the penalty is executed, the log is recorded and the user's current status is updated for reference in subsequent policy judgments.

[0035] In a specific embodiment, a penalty action is performed based on the number of indexes corresponding to the operation, for example: First → Warning → Status updated to `warned`; Second time → Block for 3 seconds → Status updated to `blocked`; Fifth time → Account blocked → Status updated to `banned`.

[0036] In one embodiment, the cooling-off period and step-by-step timing scheduling module is also used to obtain the cooling-off period and operation list in the configured JSON policy of the corresponding reason when the user triggers a violation event; determine whether the current time is within the cooling-off period, and obtain the number of times the user triggers the reason in the current period; execute the corresponding penalty action according to the corresponding operation configuration based on the number index; if the penalty is time-sensitive, set a scheduled task to restore the user status and update the user penalty status and counter for next use.

[0037] In this specific embodiment, `"stat_day": N` in the JSON configuration indicates a penalty counting period of N days. The platform maintains a violation counter for each user based on the reason ID (e.g., user_id + reason_id). During the cooldown period, if a user triggers the same penalty reason multiple times, the configured steps are executed sequentially. If the cooldown period expires, the user's violation counter for that reason is automatically reset to zero, and the penalty chain restarts.

[0038] The order in which penalties are executed is specified by the `"operation` array. The first trigger executes the first operation; the second trigger executes the second operation. If the configured number of steps is exceeded, the default is to enter the "tail operation" logic or not escalate. If the operation defines a `duration` field, the penalty countdown will begin after execution and will automatically resume.

[0039] Example ladder setup: First time: warning (type: 1); Second time: blacklist for 3 seconds (type:2, duration:0.001); Third time: Blacklisted for 1 hour (type:2, duration:1).

[0040] In one embodiment, executing the role linkage penalty action includes when the audience user A triggers a violation in the live broadcast room B, the system first parses the room context, queries the ID of the anchor user B and establishes a master-slave role association, then reads the policy fields of whether to punish the room host and the linkage penalty order from the configured JSON policy of the reason, and then determines whether to impose penalties on the anchor based on the role relationship and policy. The first time, the audience and the anchor are punished at the same time, and subsequently only the anchor is punished or the penalty is upgraded according to the anchor's violation record. Then the penalty engine performs corresponding operations on the audience and the anchor, including blacklisting, muting, restricting live broadcasts, etc. Finally, all penalty behaviors are written into the audit log and the status is synchronized, and the policy effect is fed back to the background.

[0041] In a specific embodiment, when the platform identifies that viewer user A has violated regulations in live streaming room B, the system penalty process is triggered. The system queries the user ID of the host or anchor corresponding to live streaming room B (user B), establishes a master-slave role association mapping (slave: viewer A, master: anchor B), and reads the following key fields from the reason configuration JSON: `"black_host"`: whether to impose penalties on the host; `"relation_with_host"`: defines the linkage penalty sequence (such as `"first_all_then_host"`); `"customized_black_user`: determines whether to add the viewer or host to a personalized blacklist.

[0042] Based on role relationships and policy configurations, determine whether to impose penalties on the anchor. The execution logic includes but is not limited to: first, punish the audience + anchor; for subsequent violations, only punish the anchor; and determine whether to escalate the penalty based on the anchor's violation record.

[0043] The penalty engine executes corresponding operations for viewers and anchors based on the operation configuration of each role, including but not limited to: blocking and silencing viewer A; restricting live broadcasts and marking violations for anchor B.

[0044] All role penalty behaviors are written into the audit log, recording the role type, association relationship, penalty action and timestamp, and feedback the policy effect to the background visualization system.

[0045] JSON configuration example ```json { "black_host": true, "relation_with_host": "first_all_then_host", "customized_black_user": true } ``` `black_host: true` means the host needs to be linked when punishing; `relation_with_host: first_all_then_host` means that the first time both the viewer and the host are penalized, and only the host will be penalized subsequently; `customized_black_user: true` means that the user will enter the personalized blacklist mechanism.

[0046] The following example illustrates this: User A posts illegal remarks in live broadcast room B.

[0047] First trigger: The system warns user A based on the configuration and restricts live streaming for anchor B for 6 hours. Second trigger (during the cooldown period): The system imposes an additional 12-hour live broadcast restriction on anchor B, and viewer A is automatically banned due to being on the blacklist; The third time: Anchor B was marked as a high-risk account due to multiple violations in the room, and his broadcasting rights were suspended.

[0048] This module uses the session context to map the relationship between offending users and room owners in real time, establishing a master-slave link. The penalty logic is completely based on structured policy JSON configuration, eliminating the need for hard coding and providing flexible adaptability. It supports initial linkage and subsequent transfer of primary responsibility, meeting actual audit business needs. Personalized control: Combined with the blacklist system, more precise audience behavior intervention is achieved. The entire penalty process is traceable, improving risk control transparency and audit decision support.

[0049] Those skilled in the art will appreciate that all or part of the processes in the above-described system embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described system embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0050] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0051] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and such modifications and improvements are intended to fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A universal audit and punishment system for a live broadcast audit platform, characterized in that: The system includes: a reason configuration expansion module, a dynamic penalty interpretation and execution engine, a general penalty status module, and a cooling period and step-by-step timing scheduling module; The reason configuration extension module is used to extend the modeling of the reason configuration, add an ext field to the reason table, support structured JSON data, and generate a configuration JSON policy; The dynamic penalty interpretation and execution engine performs structured policy interpretation on the configured JSON policy and executes relevant penalty operations; The general penalty status module is used to find the configured JSON policy corresponding to the reason when a user violation is triggered and count the number of violations within the configuration period, index the corresponding operation according to the number of violations, and execute the role linkage penalty action; The cooling-off period and stepped timing scheduling module are used to manage the frequency of user violations within a specified time window and dynamically execute multi-level penalty actions based on the frequency.

2. The system according to claim 1, wherein: The ext field includes custom operation logic, cooling cycle, stepped penalty list, maximum number of warnings, prompt method and role linkage; the configured JSON strategy includes multiple fields, among which the custom_operation field is a required field, which contains the penalty strategy configuration; the stat_day field is a required field, which indicates the number of days in the cooling cycle. The system counts the user's violations during the cycle; the operation array is a required field, which indicates that the stepped penalty actions are configured in sequence. Each item is an operation object, which includes a type field. Some operations additionally include a duration field. The max_warn_num field is an optional field, which indicates the maximum number of "warning" operations to be issued. After exceeding the limit, subsequent operations will be executed directly. The live_send_message_type field is an optional field, which indicates the live prompt method. 1 indicates a pop-up window, 2 indicates a private message, and 3 indicates a pop-up window + private message. The customized_black_user field is an optional field, a Boolean value, true Indicates adding the user to a personalized blacklist system. The black_host field is an optional field with a Boolean value. True indicates that the host or anchor will be punished simultaneously. The relation_with_host field is an optional field with a string value. It defines the linkage logic of the punishment between viewers and anchors.

3. The system according to claim 1, wherein: The dynamic penalty interpretation and execution engine is also used to perform syntax parsing and structural verification on the custom_operation field in the configured JSON policy, build a memory-level policy tree, determine the cooling period based on the stat_day field, and read the user's historical violation count through the middleware; based on the user's current trigger count, select the corresponding penalty action from the operation array by index, and check the type legitimacy and required field integrity; encapsulate the penalty action into an operation task, complete the specific execution by calling the corresponding module through the unified scheduling center, and record the audit log.

4. The system according to claim 2, wherein: The dynamic penalty interpretation and execution engine is further used to map the operation types in the penalty policy configuration to realize the newly added operation types after the operation decoupling.

5. The system according to claim 3, wherein: The dynamic penalty interpretation and execution engine is also used to use a cooling period counting and a double bucket counting strategy to accurately record the number of hits in the cooling period of stat_day and ensure periodic cleaning to avoid state drift.

6. The system according to claim 1, wherein: The general penalty status module includes a status enumeration definition module, a status transfer linked list module, a penalty action binding module, a status scheduling engine and a status rollback mechanism module; the status enumeration definition module is used to predefine multiple penalty statuses, including normal, warning, blacklist, ban, account suspension and waiting for review; the status transfer linked list module is used to bind a state transfer path to each penalty reason, and migrate to the next state after each trigger; the penalty action binding module is used to bind the corresponding operation type and parameters to each state transfer node to realize the modularization of operation behavior; the status scheduling engine is used to schedule the transfer logic and update the user status in real time according to the user's current status, historical trigger times and violation frequency during the cooling period; the status rollback mechanism module is used to provide a manual intervention interface, and in the event of a misjudgment, roll back to the previous state and cancel the corresponding penalty operation.

7. The system according to claim 1, wherein: The general penalty status module is also used to trigger the system processing flow when the user violates the rules to find the corresponding configured JSON policy, count the number of violations of the user within the configuration period, index the corresponding operation according to the number of times, and execute the penalty action. If the penalty is time-sensitive, the expiration time is recorded and the scheduling task is arranged to be unscheduled; if the penalty is linked, the penalty is synchronized and the status is updated synchronously; after the penalty is executed, the log is recorded and the user's current status is updated for reference in subsequent policy judgments.

8. The system according to claim 1, wherein: The cooling-off period and step-by-step timing scheduling module is also used to obtain the cooling-off period and operation list in the configurable JSON policy of the corresponding reason when the user triggers a violation event; determine whether the current time is within the cooling-off period, and obtain the number of times the user's reason is triggered in the current period; Execute the corresponding penalty action according to the operation configuration corresponding to the number of times index. If the penalty is time-sensitive, set a scheduled task to restore the user status and update the user penalty status and counter for next use.

9. The system according to claim 1, wherein: The execution of the role linkage penalty action includes that when the audience user A triggers a violation in the live broadcast room B, the system first parses the room context, queries the ID of the anchor user B and establishes a master-slave role association, and then reads the policy fields of whether to punish the room owner and the linkage penalty order from the configured JSON policy of the reason, and then determines whether to execute the penalty on the anchor based on the role relationship and policy. The first time, the audience and the anchor are punished at the same time, and subsequently only the anchor is punished or the penalty is upgraded according to the anchor's violation record. Then the penalty engine performs corresponding operations on the audience and the anchor, including blacklisting, banning, and restricting live broadcasts. Finally, all penalty behaviors are written into the audit log and the status is synchronized, and the policy effect is fed back to the background.

Images