A live broadcast auditing platform generalization auditing and punishing system

Abstract

The application relates to a live broadcast auditing platform generalization auditing and punishing system. The system comprises the following steps: extending modeling of reasons and configuration, adding an ext field in a reason table to generate a configuration JSON strategy; a dynamic punishment explanation execution engine performs structured strategy explanation on the configuration JSON strategy and executes relevant punishment operations; when a user violates a rule, the corresponding configuration JSON strategy of the reason is found, the number of violations in a configuration period is counted, corresponding operations are indexed according to the number of violations, role linkage punishment actions are executed, the frequency of violations of a user in a specified time window is managed, and multi-level punishment actions are dynamically executed according to the frequency. The system can solve the problems of single punishment means, poor expansibility, configuration redundancy and untimely response under the traditional "reason-operation" static binding mechanism.

Description

TECHNICAL FIELD

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

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

[0003] However, the current live broadcast review technology has the following problems: it relies on fixed rules, cannot dynamically adjust strategies, cannot gradually upgrade the punishment intensity according to the number of user violations, cannot synchronously process associated violations between anchors and audiences, and lacks a visual interface and real-time optimization mechanism. SUMMARY

[0004] Therefore, it is necessary to provide a live broadcast review platform universal review and punishment system to solve the problems of single punishment means, poor scalability, redundant configuration, and untimely response under the traditional "reason-operation" static binding mechanism.

[0005] A live broadcast review platform universal review and punishment system, the system comprising: a reason configuration extension module, a dynamic punishment explanation execution engine, a universal punishment state module, and a cooling period and ladder type timing scheduling module;

[0006] The reason configuration extension module is used to extend the modeling of reasons configuration, add an ext field in the reason table, support structured JSON data, and generate a configured JSON strategy;

[0007] The dynamic punishment explanation execution engine performs structured strategy interpretation on the configured JSON strategy and executes related punishment operations;

[0008] The universal punishment state module is used to find the configured JSON strategy corresponding to the reason when the user violates the rules, and to count the number of violations within the configuration period, to index the operation according to the number of violations, and to execute the role linkage punishment action;

[0009] The cooling period and ladder type timing scheduling module is used to manage the violation frequency of the user within a specified time window, and to dynamically execute multi-level punishment actions according to the frequency.

[0010] The aforementioned generalized review and penalty system for a live streaming review platform, through the addition of an `ext` field to the reason configuration extension module, supports structured JSON data and generates configurable JSON strategies. When faced with new violation scenarios or penalty requirements, only the JSON strategy needs to be modified or added, without large-scale changes to the underlying code, to quickly expand review and penalty capabilities, significantly improving system adaptability. The dynamic penalty interpretation and execution engine provides a structured interpretation of the configurable JSON strategy. The configuration method, centered on the JSON strategy, stores rules and operations in a structured and lightweight data format, avoiding the duplication and waste caused by configuring each "reason-operation" combination separately in the traditional way, achieving streamlined and efficient configuration. Furthermore, the general penalty status module, in conjunction with the cooldown period and tiered timed scheduling module, breaks the traditional fixed operation mode. The system can dynamically execute role-based linkage and multi-level penalty actions based on the number and frequency of violations, changing the past situation where the penalty method was always the same regardless of the violation, and achieving diversified and tiered penalties. The reason configuration extension module supports structured JSON data by adding an `ext` field to generate configurable JSON strategies. When faced with new violation scenarios or penalty requirements, the system can quickly expand its review and penalty capabilities simply by modifying or adding JSON policies, without large-scale changes to the underlying code, significantly improving system adaptability. The dynamic penalty interpretation and execution engine provides a structured interpretation of the configurable JSON policies. This JSON-policy-centric configuration method stores rules and operations in structured, lightweight data, avoiding the duplication and waste associated with configuring each "reason-action" combination separately in traditional methods, achieving streamlined and efficient configuration. This effectively compensates for the shortcomings of traditional mechanisms, significantly improving the flexibility, management efficiency, and execution effectiveness of the live streaming review platform's penalty policies, demonstrating high practical value. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a generalized review and penalty system for a live streaming review platform in one embodiment.

[0012] Figure 2 This is a schematic diagram of a list of reasons in one embodiment;

[0013] Figure 3 This is a schematic diagram illustrating the rationale configuration in one embodiment. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0015] In one embodiment, such as Figure 1As shown, a live broadcast audit platform universal audit and punishment system is provided, comprising: a reason configuration extension module 102, a dynamic punishment explanation execution engine 104, a universal punishment state module 106, and a cooling period and stepwise timing scheduling module 108;

[0016] The reason configuration extension module 102 is used for extending modeling of reasons configuration, adding an ext field in a reason table, supporting structured JSON data, and generating a configuration JSON strategy; a reason list is as shown in Figure 2 As shown, the reason configuration is as shown in Figure 3 As shown.

[0017] The dynamic punishment explanation execution engine 104 performs structured strategy interpretation on the configuration JSON strategy and executes related punishment operations;

[0018] The universal punishment state module 106 is used for finding the configuration JSON strategy corresponding to the reason when a user violates a rule, and counting the number of violations within a configuration period, performing role linkage punishment actions according to the number of violations index operations;

[0019] The cooling period and stepwise timing scheduling module 108 is used for managing the violation frequency of a user within a specified time window, and dynamically executing multi-level punishment actions according to the frequency.

[0020] In the live broadcast review platform generalization review and punishment system, the reason configuration expansion module 102 expands the modeling of the reason configuration, adds an ext field in the reason table, supports structured JSON data, and generates a configured JSON strategy. This way makes the system no longer limited to the preset limited rules. When new violation scenarios and new punishment requirements appear, the system can quickly expand the review and punishment capabilities of the system by modifying and adding JSON strategies, without the need for large-scale changes to the underlying code, greatly improving the scalability of the system when facing complex and changing requirements, and overcoming the difficulty of traditional static binding mechanisms to adapt to new situations and new requirements. The dynamic punishment explanation execution engine 104 performs structured strategy interpretation on the configured JSON strategy. This JSON strategy-based configuration method stores and manages complex rules and operations in a structured and lightweight data format. Compared with the traditional static binding mechanism, where each "reason - operation" combination needs to be configured separately, this system reduces a large amount of repetitive and similar configuration content, achieves efficient use of configuration, and avoids the management confusion and resource waste caused by configuration redundancy. The general punishment state module 106 and the cooling period and stepwise timing scheduling module 108 work together to break the fixed operation mode of the traditional static binding. When the user violates the rules, the general punishment state module 106 will find the corresponding configured JSON strategy for the reason and count the number of violations. According to the index of the number of violations, the corresponding operation can be implemented to realize role linkage punishment action. The cooling period and stepwise timing scheduling module 108 manages the violation frequency of the user within a specified time window, dynamically executes multi-level punishment actions according to the frequency, and the system can execute diversified and gradient punishment according to the specific circumstances of the violation, changing the situation that the punishment means is always single regardless of the degree and frequency of violation in the traditional mechanism. The dynamic punishment explanation execution engine 104 can quickly interpret and execute the configured JSON strategy. The general punishment state module 106 and the cooling period and stepwise timing scheduling module 106 can monitor the violation situation in real time and dynamically execute the punishment action. The system can sense the violation behavior in real time, respond quickly based on dynamic strategy, and execute the corresponding punishment in time. Compared with the traditional static binding mechanism, which needs manual intervention or processes violations according to a fixed period, the system greatly improves the response speed, ensures timely control of violation behavior, and greatly improves the flexibility, management efficiency and execution effect of the punishment strategy of the live broadcast review platform, which has high practical value.

[0021] In one of the embodiments, the ext field includes custom operation logic, cooling period, step penalty list, maximum warning number, prompt mode and role linkage; the configuration JSON strategy includes multiple fields, wherein the custom operation field is a mandatory field, contains penalty strategy configuration, the stat_day field is a mandatory field, represents the cooling period, the system counts the user's violation behavior in the period, the operation array is a mandatory field, represents the configuration of step penalty action in order, each item is an operation object, contains the type field, some operations additionally contain the duration field, the max_warn_num field is an optional field, represents the maximum number of "warning" operations, and the subsequent operations will be directly executed after exceeding, the live_send_message_type field is an optional field, represents the live prompt mode, 1 represents pop-up window, 2 represents private message, 3 represents pop-up window + private message, the customized_black_user field is an optional field, a Boolean value, true indicates that the user is added to the personalized blacklist system, the black_host field is an optional field, a Boolean value, true indicates that the host or anchor is synchronized for punishment, the relation_with_host field is an optional field, a string, defines the punishment linkage logic of the audience and the anchor.

[0022] In specific embodiments, the operation type type corresponding to the penalty strategy configuration is an integer field, representing the penalty action type, which specifically includes: type: 1, representing "warning", used to issue a violation prompt to the user; type: 2, representing "blacklist", adding the user to the blacklist, which can limit access rights; type: 3, representing "block / mic off", used to interrupt the speaking or streaming behavior in the live broadcast process; type: 4, representing "delete", used to delete the user's published violation content; type: 5, representing "ban", prohibiting the user account from logging in or using; type: 6, representing "mark", adding the user to the list of key attention; type: 7, representing "review blacklist", submitting the violation information for review before executing the blacklist; type: 11, representing "mute", prohibiting the user from speaking; type: 16, representing "black screen", forcibly blacking the screen during live broadcast; type: 17, representing "limit live broadcast", prohibiting the user from starting live broadcast; type: 18, representing "add review success", marking that the penalty has passed the manual review. Among them, the operations of type 2, 5, 17, etc. need to additionally configure the duration field, which represents the duration of the penalty, with the unit of hours, supporting decimal points.

[0023] The extended field configuration system breaks the traditional fixed pattern of single reason corresponding to single punishment, and realizes the dynamic definition and flexible expansion of punishment strategy by using structured JSON storage method. It is compatible with the old logic, supports multi-parameter, multi-role and multi-stage punishment configuration, greatly improves the response ability and management precision of the platform to complex violation behaviors. Through real-time analysis and scheduling, the intelligence and automation level of the system is significantly enhanced. The configuration system enables the live streaming platform to adjust and optimize the punishment strategy based on a unified data structure, and new strategies can be put online without code changes, effectively reducing the operation and maintenance cost. At the same time, the precise multi-dimensional configuration ensures the fairness and reasonableness of punishment, improves user experience and platform content safety management efficiency, and meets the complex and variable content review needs in large-scale and high-concurrency live streaming scenarios.

[0024] The following is an example:

[0025] Suppose the reason is "live room abuse behavior", and its JSON configuration is as follows:

[0026] ```json

[0027] {

[0028] "custom_operation": {

[0029] "stat_day": 1,

[0030] "operation": [

[0031] {"type": "1"},

[0032] {"type": "2", "duration": "0.001"},

[0033] {"type": "2", "duration": "1"},

[0034] {"type": "2", "duration": "3"},

[0035] {"type": "5"} ]

[0037] },

[0038] "max_warn_num": 1,

[0039] "live_send_message_type": 3,

[0040] "black_host": true,

[0041] "relation_with_host": "first_all_then_host"

[0042] }

[0043] This configuration example is the extension configuration of the general punishment strategy for a certain violation reason in the live broadcast review platform, which contains multi-dimensional parameter setting. The specific rules and meanings are as follows:

[0044] custom_operation (custom operation configuration): stat_day = 1: Set the cooling period to 1 day, that is, within 1 day, the system will accumulate the number of violations of the user for this reason, and execute the step-by-step punishment operation in turn. After exceeding the cooling period, the violation count is reset.

[0045] operation (operation list): Defines the specific punishment steps, triggered in order of violation number:

[0046] First violation: type is "1", that is, send a "warning" operation.

[0047] Second violation: type is "2", that is, execute "blacklist" operation, duration is 0.001 hours (about 3.6 seconds), used to temporarily block user behavior.

[0048] Third violation: also "blacklist", but the duration is extended to 1 hour, to strengthen the punishment.

[0049] Fourth violation: continue to execute "blacklist", for 3 hours, to further increase the punishment.

[0050] Fifth violation: execute "ban" operation (type "5"), that is, prohibit user login, implement the highest level of punishment.

[0051] max_warn_num = 1: Set the upper limit of warning times to 1, that is, within this cooling period, only one warning can be sent at most, to avoid the decline of user experience or the increase of review personnel burden due to multiple warnings.

[0052] live_send_message_type = 3: Set the sending method of violation prompt to "private message + pop-up window" dual prompt, to ensure that the user can receive the violation notice in time and clearly, and to improve the coverage and effectiveness of information transmission.

[0053] black_host = true: Indicates that this punishment strategy is applicable to joint punishment, and the host (presenter) of the live broadcast room where the violating user is located is also punished. This mechanism ensures the safety of the live broadcast room and prevents the whole order from being affected by the host's violation behavior.

[0054] relation_with_host = "first_all_then_host": This parameter defines the linkage relationship of the punishment strategy between the host and the user, that is, the host and the user are punished at the same time for the first time, and subsequent punishment is only executed on the host, which embodies the dynamic linkage punishment strategy of the master-slave role, effectively balancing the punishment intensity and platform operation management.

[0055] In summary, the configuration scheme realizes dynamic execution of multi-step step-by-step punishment, effectively avoids over-punishment in combination with the cooling period, and supports multi-channel violation reminding and master-slave role linkage punishment mechanism, meeting the complex and variable content review and management needs of the live broadcast platform. Through the configuration, the platform can flexibly adjust the punishment intensity and range at different stages, improving the review efficiency and management accuracy.

[0056] In one of the embodiments, the dynamic punishment interpretation execution engine is also used for syntax parsing and structure verification of the custom operation field in the configured JSON strategy, building a memory-level strategy tree, determining the cooling period according to the stat_day field, and reading the historical violation times of the user through the middleware; according to the current trigger times of the user, the corresponding punishment action is selected from the operation array according to the index, and the type legality and required field integrity are checked; the punishment action is encapsulated into an operation task, and the corresponding module is called through the unified scheduling center to complete the specific execution, and the audit log is recorded.

[0057] In a specific embodiment, after the platform review system receives a violation event, the system retrieves the corresponding reason table record and extracts the JSON configuration in the ext field according to the event meta information, such as the violation user ID, the live room ID, and the reason code; the engine performs syntax parsing and structure verification on the custom operation field in the JSON, and builds a memory-level strategy tree; the cooling period is determined according to the stat_day value in the configuration, and the historical violation times of the user are read through Redis and other middleware; according to the current trigger times of the user, the corresponding punishment action is selected from the operation array according to the index, and the type legality and required fields such as duration integrity are checked; the punishment 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, the notification service, to complete the specific execution, and the audit log is recorded.

[0058] In one of the embodiments, the dynamic punishment interpretation execution engine is also used for mapping the operation type in the punishment strategy configuration to realize the newly added operation type after operation decoupling.

[0059] In specific embodiments, the engine internally maintains a set of "type → executor" mapping table. Each operation type has a corresponding execution function (Executor): such as type:2 maps to `GlobalBlockExecutor(duration)`, type:5 maps to `BanAccountExecutor`, and type:1 maps to `WarningExecutor(msg_type)`.

[0060] This decoupled structure supports the subsequent addition of operation types, which only requires the extension of the registry and the corresponding processing logic.

[0061] In one of the embodiments, the dynamic punishment interpretation execution engine is also used to adopt a double-layer bucket counting strategy to accurately record the number of hits within the stat_day cooling period and ensure periodic cleaning, avoiding state drift.

[0062] In specific embodiments, if `black_host: true` and there is a binding relationship between the host and the audience, the engine will add the host punishment action in the scheduling stage; if the `max_warn_num` threshold is hit, the type:1 warning type is directly skipped and the next punishment operation is entered; if the JSON has syntax errors or missing fields, the engine returns an error state and refuses to execute, preventing system abnormalities.

[0063] In one of the embodiments, the general punishment state module includes a state enumeration definition module, a state transition chain table module, a punishment action binding module, a state scheduling engine, and a state rollback mechanism module; the state enumeration definition module is used to predefine a plurality of punishment states, including normal, warning, blacklisting, muting, banning, and waiting for review; the state transition chain table module is used to bind a state transition path for each punishment reason, and migrate to the next state after each trigger; the punishment action binding module is used to bind the corresponding operation type and parameter for each state transition node, realizing the modularization of operation behavior; the state scheduling engine is used to schedule the transition logic and update the user state in real time according to the current state of the user, the historical trigger times, and the violation frequency within the cooling period; the state rollback mechanism module is used to provide a manual intervention interface to rollback to the previous state and cancel the corresponding punishment operation in the case of misjudgment.

[0064] In one of the embodiments, the general punishment state module is also used to find the corresponding configured JSON strategy for the user violation triggering system processing flow, count the number of violations of the user in the configuration period, execute the punishment action according to the number index corresponding operation, record the expiration time and arrange the release scheduling task if the punishment has timeliness; if the punishment has linkage, the punishment is synchronized and the state is updated synchronously; after the punishment is executed, the log is recorded, the current state of the user is updated, and the subsequent strategy judgment is referenced.

[0065] In specific embodiments, according to the number index corresponding operation, the punishment action is executed, such as:

[0066] First time → warning → state updated to `warned`;

[0067] Second time → black 3 seconds → state updated to `blocked`;

[0068] Fifth time → number blocked → state updated to `banned`.

[0069] In one of the embodiments, the cooling period and the stepwise timing scheduling module are also used to obtain the cooling period and the operation list in the configured JSON strategy corresponding to the reason when the user triggers a violation event; it is judged whether the current time is in the cooling period, the number of triggers of the user for the reason in the current period is obtained; the corresponding punishment action is executed according to the number index corresponding operation configuration, and if the punishment has timeliness, a timing task is set to restore the user state, the user punishment state and the counter are updated for next use.

[0070] In specific embodiments, in the JSON configuration, `"stat_day": N` indicates that N days are a punishment counting period. The platform maintains a violation counter for each user in the reason ID dimension (such as user_id + reason_id). Within the cooling period, when the user triggers the same punishment reason multiple times, the operations are executed in turn according to the configured steps. If the cooling period is exceeded, the counter of the user for the reason is automatically cleared, and the punishment chain starts again.

[0071] The execution order of the punishment is indicated by the `"operation"` array order. The first operation is executed when triggered for the first time; the second operation is executed when triggered for the second time; if the number of configuration steps is exceeded, the "tail operation" logic is entered or no longer upgraded; if the operation defines a `duration` field, the punishment countdown is started after execution and is automatically restored.

[0072] Example step setting:

[0073] 1st time: warning (type: 1);

[0074] Second: 3 seconds of blacklisting (type: 2, duration: 0.001);

[0075] Third: 1 hour of blacklisting (type: 2, duration: 1).

[0076] In one embodiment, performing role linkage punishment actions includes, after the audience user A triggers a violation behavior in the live room B, the system first analyzes the room context, queries the ID of the host user B and establishes the master-slave role association, then reads the strategy field of whether to punish the host and the linkage punishment sequence from the configured JSON strategy of the reason, and then judges whether to execute punishment on the host based on the role relationship and the strategy, first punishing the audience and the host, and subsequently only punishing the host or upgrading the punishment according to the host violation record, and then the punishment engine executes the corresponding operation on the audience and the host, including blacklisting, muting, limiting live broadcast, etc., finally writes all the punishment behaviors into the audit log and synchronizes the state, and feeds back the strategy effect to the background.

[0077] In a specific embodiment, when the platform identifies that the audience user A has a violation behavior in the live room B, the system punishment process is triggered. The system queries the host or anchor user ID (user B) corresponding to the live room B, establishes the master-slave role association mapping (slave: audience A, master: anchor B), reads the following key fields from the reason configuration JSON: `"black_host"`: whether to execute punishment on the host; `"relation_with_host"`: define the linkage punishment sequence (such as `"first_all_then_host"`); `"customized_black_user"`: decide whether to add the audience or the host to the personalized blacklist.

[0078] Based on the role relationship and the strategy configuration, it is judged whether to execute punishment on the host, and the execution logic includes but is not limited to: first punish the audience + the host; subsequently only punish the host; judge whether to upgrade the punishment according to the host violation record.

[0079] The punishment engine executes the corresponding operation on the audience and the host respectively according to the operation configuration of each role, including but not limited to: blacklisting and muting the audience A; limiting live broadcast and marking violation for the anchor B.

[0080] All role punishment behaviors are written into the audit log, recording the role type, association relationship, punishment action and timestamp, and feeding back the strategy effect to the background visualization system.

[0081] JSON configuration example

[0082] ```json

[0083] {

[0084] "black_host": true,

[0085] "relation_with_host": "first_all_then_host",

[0086] "customized_black_user": true

[0087] }

[0088] ```

[0089] `black_host: true` means that the anchor needs to be linked when punished;

[0090] `relation_with_host: first_all_then_host` means that the first time the audience and the anchor are punished at the same time, and the anchor is punished in the future;

[0091] `customized_black_user: true` means that the user will enter the individual black list mechanism.

[0092] The following will be illustrated by examples: user A publishes illegal remarks in live room B.

[0093] First trigger: the system warns user A according to the configuration, and restricts the live function of anchor B for 6 hours;

[0094] Second trigger (in the cooling period): the system adds 12 hours of live restriction to anchor B, and automatically bans audience A because it has entered the blacklist;

[0095] Third time: anchor B is marked as a high-risk account because of multiple violations in the room, and is suspended from broadcasting.

[0096] This module maps the relationship between the illegal user and the host in real time through the session context, establishes a master-slave link, and the punishment logic is completely based on structured strategy JSON configuration, without hard coding, flexible adaptation; support first linkage, subsequent main responsibility transfer, which meets the actual audit business needs; personalized control: combined with the blacklist system to achieve more accurate audience behavior intervention; the punishment process is fully traceable, which improves the transparency of risk control and the support of audit decision.

[0097] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment systems can be implemented by a computer program instructing relevant hardware, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the processes of the above-mentioned embodiment systems can be included. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0098] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0099] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the application. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A universal review and penalty system for live streaming review platforms, characterized in that, The system includes: a reason configuration extension module, a dynamic penalty interpretation and execution engine, a general penalty status module, and a cooldown period and tiered time scheduling module; The reason configuration extension module is used to extend the modeling of reason configuration, add an ext field to the reason table, support structured JSON data, and generate configurable JSON strategies; The dynamic penalty interpretation and execution engine interprets the configurable JSON policy in a structured manner and executes the relevant penalty operations; The general penalty status module is used to find the configuration JSON policy corresponding to the reason when a user violates the rules, count the number of violations within the configuration period, index the corresponding operation based on the number of violations, and execute the role-linked penalty action. The cooling-off period and tiered time scheduling module 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. The `ext` field includes custom operation logic, cooldown period, tiered penalty list, maximum number of warnings, prompting method, and role linkage. The configurable JSON strategy includes multiple fields: `custom_operation` (required, containing penalty strategy configuration), `stat_day` (required, indicating the cooldown period days; the system counts user violations within this period), `operation` array (required, indicating sequential configuration of tiered penalty actions; each item is an operation object, including a `type` field; some operations also include a `duration` field), `max_warn_num` (optional, indicating the maximum number of "warning" operations; exceeding this limit will trigger subsequent operations), `live_send_message_type` (optional, indicating the live notification method: 1 for pop-up, 2 for private message, 3 for pop-up + private message), `customized_black_user` (optional, boolean; `true` adds the user to the personalized blacklist), and `black_host` (optional, boolean). This indicates that the host or streamer will be penalized simultaneously. The `relation_with_host` field is an optional string that defines the penalty linkage logic between the viewer and the streamer. The dynamic penalty interpretation and execution engine is also used to perform syntax parsing and structure verification on the custom_operation field in the configurable JSON policy, build a memory-level policy tree, determine the cooldown period based on the stat_day field, and read the user's historical violation count through middleware; based on the user's current trigger count, select the corresponding penalty action from the operation array by index, and check the validity of type and the completeness of required fields; encapsulate the penalty action into an operation task, call the corresponding module through the unified scheduling center to complete the specific execution, and record audit logs.

2. The system according to claim 1, characterized in that, The dynamic penalty interpretation and execution engine is also used to map the operation types in the penalty strategy configuration to add new operation types after operation decoupling.

3. The system according to claim 1, characterized in that, The dynamic penalty interpretation and execution engine is also used to accurately record the number of hits during the stat_day cooldown period using a two-level bucket counting strategy and to ensure periodic cleanup to avoid state drift.

4. The system according to claim 1, characterized in that, 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 predefines multiple penalty statuses, including normal, warning, blacklist, mute, account suspension, and pending review. The status transition linked list module binds a status transition path to each penalty reason, migrating to the next status after each trigger. The penalty action binding module binds corresponding operation types and parameters to each status transition node, modularizing operation behavior. The status scheduling engine schedules transition logic and updates the user's status in real time based on the user's current status, historical trigger counts, and violation frequency during the cooldown period. The status rollback mechanism module provides a manual intervention interface, allowing reverting to the previous status and canceling the corresponding penalty operation in case of misjudgment.

5. The system according to claim 1, characterized in that, The general penalty status module is also used to find the corresponding configurable JSON policy when a user violates the system's processing flow, count the number of violations by the user within the configuration period, index the corresponding operation based on the number of violations, execute the penalty action, record the expiration time and arrange a release task if the penalty has an expiration time, 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 judgment.

6. The system according to claim 1, characterized in that, The cooling-off period and tiered time scheduling module is also used to obtain the cooling-off period and operation list in the configurable JSON strategy for the corresponding reason when a user triggers a violation event; determine whether the current time is within the cooling-off period; and obtain the number of times the user has triggered the corresponding reason under the current period. The corresponding penalty action is executed according to the operation configuration corresponding to the number of times. If the penalty has an expiration time, a scheduled task is set to restore the user's state, update the user's penalty status and counter for the next use.

7. The system according to claim 1, characterized in that, The execution of the linked penalty actions includes the following steps: When viewer user A triggers a violation in live room B, the system first parses the room context, queries the ID of streamer user B, and establishes a master-slave role association. Then, it reads the policy fields for whether to punish the room owner and the order of linked penalties from the configurable JSON policy of the reason. Based on the role relationship and policy, it determines whether to punish the streamer. The first time, both the viewer and the streamer are punished simultaneously; subsequent times, only the streamer is punished, or the penalty is escalated according to the streamer's violation record. Then, the penalty engine performs corresponding operations on the viewer and the streamer, including blocking, muting, and restricting the live stream. Finally, all penalty actions are written to the audit log and the status is synchronized, and the policy effect is fed back to the backend.

Images