Meeting compliance detection method, system, device, storage medium and program product

Abstract

This application provides a meeting compliance detection method, system, device, storage medium, and program product. The meeting compliance detection method applied to the compliance detection end includes: acquiring meeting data and performing compliance detection on the meeting data based on preset compliance rules to identify non-compliant meetings; generating a non-compliance notification message; sending the notification message to the client of the responsible party; in the next detection cycle, re-acquiring meeting data from the meeting database and re-detecting whether non-compliant meetings or new meeting data associated with non-compliant meetings are compliant based on preset compliance rules; if still non-compliant, generating and sending a non-compliance notification message to the client of the responsible party again. This method, through periodic automatic detection, generating notification messages containing query addresses, and re-detecting and re-notifying non-compliant meetings in the next detection cycle, achieves fully automated closed-loop management of meeting data from problem discovery to follow-up rectification.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically, to a meeting compliance detection method, system, device, storage medium, and program product. Background Technology

[0002] As enterprises accelerate their digital transformation, meetings, as high-frequency collaborative activities within organizations, have generated data (including meeting resource utilization, participation efficiency, and information integrity) that has become a crucial aspect of enterprise data governance. To ensure the standardization, completeness, and quality of meeting data, the industry commonly employs automated detection methods based on database queries. For example, by configuring Structured Query Language (SQL) scripts, the data inspection platform executes queries at preset intervals, filtering out meeting records that do not meet preset rules (such as insufficient participation rates, missing meeting descriptions, or meeting timeouts), and pushing the detection results to relevant management personnel via email or other means.

[0003] However, existing technical solutions typically employ a single detection and notification mechanism. Once the information about non-compliant meetings is pushed to the responsible party, the remediation action is considered complete, lacking the ability to continuously track and automatically verify the rectification status in subsequent detection cycles. Because it cannot automatically identify rectified data and terminate alerts, nor can it automatically trigger re-notifications in cases of non-rectification, the meeting data governance process is interrupted after the detection and notification phase, failing to form an automated closed-loop management system. Summary of the Invention

[0004] The purpose of this application is to provide a meeting compliance detection method, system, device, storage medium, and program product to solve the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a meeting compliance detection method, applied to a meeting compliance detection system. The meeting compliance detection system includes a compliance detection terminal. The method includes: the compliance detection terminal obtaining meeting data from a meeting database based on a preset detection period, and performing compliance detection on the meeting data based on preset compliance rules to determine non-compliant meetings; the compliance detection terminal generating a non-compliance notification message; wherein the non-compliance notification message includes a query address for non-compliant meeting information; the compliance detection terminal sending the notification message to the client of the target responsible party; in the next detection period, the compliance detection terminal again obtaining meeting data from the meeting database, and re-detecting whether the non-compliant meeting or new meeting data associated with the non-compliant meeting is compliant based on the preset compliance rules; if it is still non-compliant, then generating and sending the non-compliance notification message to the client of the target responsible party again.

[0006] In implementing the above solution, a fully automated closed-loop management system for meeting data—from problem discovery to rectification—was achieved through periodic automatic detection, generating notification messages containing query addresses, and re-detecting and re-notifying non-compliant meetings in the next detection cycle. Furthermore, automatically acquiring and detecting meeting data based on preset detection cycles replaces manual inspections, improving the automation and timeliness of meeting compliance detection. Additionally, embedding query addresses in non-compliant notification messages allows responsible parties to directly access detailed information, eliminating manual data searching and enhancing data access convenience. Finally, re-detecting non-compliant meetings or related new meeting data in the next detection cycle and automatically triggering re-notifications for still non-compliant cases ensures automatic verification and continuous tracking of rectification status, guaranteeing the integrity of the governance process.

[0007] In one implementation of the first aspect, the compliance detection of the meeting data based on preset compliance rules to determine non-compliant meetings includes: detecting whether key information fields of the meeting data meet completeness requirements; if the key information fields are missing, the meeting is determined to be a non-compliant meeting; wherein the key information fields include at least one of meeting description information, meeting minutes, scheduled location, and organizer; and / or detecting whether the meeting execution process reflected by the meeting data meets normative requirements; if the meeting execution process does not meet the normative requirements, the meeting is determined to be a non-compliant meeting; wherein the normative requirements include at least one of meeting overtime duration limit requirements, attendance rate compliance requirements, and meeting time compliance requirements; and / or detecting whether the meeting data meets preset quality requirements; if the meeting data does not meet the preset quality requirements, the meeting is determined to be a non-compliant meeting; wherein the preset quality requirements include at least one of accuracy requirements for verifying the consistency between the meeting data and source data, consistency requirements for verifying the consistency of key information of the same meeting in different business systems, and timeliness requirements for verifying the time interval between the entry time of meeting-related documents and the end time of the meeting.

[0008] In implementing the above solution, compliance checks on meeting data were conducted from three dimensions: completeness, standardization, and quality. This achieved full coverage of meeting data governance needs and improved the comprehensiveness and accuracy of meeting compliance checks. On the other hand, detecting missing key information fields enabled timely identification of omissions in the entry of basic information such as meeting descriptions and minutes, ensuring the basic integrity of meeting data. Furthermore, by checking the compliance of meeting overtime duration, attendance rate, and meeting time, standardized control over the meeting execution process was achieved, promoting the efficient use of meeting resources and compliant implementation.

[0009] In one implementation of the first aspect, generating a non-compliance notification message includes: obtaining the number of non-compliant meetings; if the number of non-compliant meetings is greater than a preset number threshold, extracting the meeting identifier and corresponding non-compliance dimension information of the non-compliant meetings; and generating a non-compliance notification message based on the meeting identifier, the non-compliance dimension information, and the query address.

[0010] In implementing the above solution, non-compliant meetings are filtered by setting a preset threshold, and notifications are only triggered when the number exceeds the threshold, avoiding interference from invalid or infrequent notifications and improving the accuracy and effectiveness of the notification mechanism. On the other hand, the meeting identifiers and corresponding non-compliant dimension information of non-compliant meetings are extracted, so that the notification messages carry specific problem location information, making it easier for the responsible parties to quickly identify problematic meetings and their violation types. Furthermore, notification messages are generated by assembling multiple dimensions based on meeting identifiers, non-compliant dimension information, and query addresses, enriching the information hierarchy of the notification content and allowing the responsible parties to directly obtain problem location and details viewing paths based on a single notification message.

[0011] In one implementation of the first aspect, sending the notification message to the client of the target responsible person includes: determining the target responsible person by querying preset responsible person configuration data based on the attribute information of the non-compliant meeting; wherein the attribute information includes at least one of meeting organizer information, department identifier, and meeting type; the responsible person configuration data stores a mapping relationship between attribute information and responsible person identifier; and sending the notification message to the client corresponding to the target responsible person.

[0012] In implementing the above solution, by automatically querying and identifying the responsible party based on the attribute information of non-compliant meetings and sending targeted notification messages, accurate matching between the responsible party and meeting data is achieved, improving the automation and accuracy of notification recipient identification in the meeting compliance detection method. On the other hand, by querying and identifying the responsible party based on at least one of the attribute information of the meeting organizer, department identifier, or meeting type, a connection path between non-compliant meetings and corresponding management personnel is established, ensuring that notification messages can be delivered to the personnel responsible for the governance of the corresponding meeting data. Furthermore, by utilizing the pre-defined mapping relationship between the data storage attribute information and the responsible party identifier of the responsible party, the mapping configuration can be flexibly adjusted according to changes in organizational structure or business rules, improving the adaptability and configurability of the meeting compliance detection method in the responsible party identification stage.

[0013] In one implementation of the first aspect, the preset compliance rules are encapsulated and stored in a database in the form of a configurable query script. The query script includes a dataset query statement for defining non-compliance judgment conditions. The compliance detection of the meeting data based on the preset compliance rules includes: calling the query script to execute a query on the meeting database, and determining the result returned by the query as the non-compliant meeting.

[0014] In implementing the above solution, by encapsulating the preset compliance rules in the form of configurable query scripts and storing them in the database, the compliance detection logic and program code are decoupled. This allows for dynamic changes to the detection rules by adjusting the query scripts in the database without modifying the program code, thus improving the flexibility and maintainability of the meeting compliance detection method. On the other hand, by using dataset query statements to define non-compliance judgment conditions and directly calling execution, business rule judgments are transformed into database query operations, improving the execution efficiency and judgment accuracy of compliance detection. Furthermore, storing the query scripts centrally in the database facilitates unified version management and auditing of compliance rules, enhancing the security and traceability of rule management in the meeting compliance detection method.

[0015] In one implementation of the first aspect, generating the non-compliance notification message includes: extracting the meeting identifier and corresponding non-compliance dimension information of the non-compliant meeting; assembling the meeting identifier, the non-compliance dimension information, and the query address based on a preset message card template to generate a non-compliance notification message; wherein, the message card template is used to generate message cards that support interactive operations; the interactive operations include jumping to the corresponding report display page in response to a trigger operation on the query address.

[0016] In the implementation of the above solution, by generating non-compliant notification messages that support interactive operations based on message card templates, the structured encapsulation and rich media presentation capabilities of the notification content are realized, optimizing the intuitiveness and ease of operation of information transmission. On the other hand, by using preset message card templates to standardize the assembly of meeting identifiers, non-compliant dimension information and query addresses, the consistency of notification message formats and generation efficiency are ensured, facilitating the standardized implementation of subsequent interactive logic. Furthermore, message cards support direct jump to the corresponding report display page in response to trigger operations on the query address, eliminating the manual copying of links or switching of systems in traditional notifications, and shortening the response path from problem discovery to detailed viewing.

[0017] In one implementation of the first aspect, generating the non-compliance notification message includes: extracting the meeting identifier and corresponding non-compliance dimension information of the non-compliant meeting; calling a preset interface of the message server, and passing the meeting identifier, the query address, the non-compliance dimension information and the receiving identifier of the target responsible person to the preset interface, so as to instruct the message server to generate a corresponding message card based on a preset message card template.

[0018] In the implementation of the above solution, by calling the preset interface of the message server and passing in the meeting identifier, query address, non-compliance dimension information, and receiving identifier, the meeting compliance detection process and message generation service are decoupled. This enables the meeting compliance detection method to generate notification messages based on standardized interface calls, improving the modularity and scalability of the method. On the other hand, by passing in the receiving identifier of the target responsible person to the preset interface, the message server provides accurate addressing information for targeted delivery of notification messages, ensuring that non-compliant meeting notifications are accurately delivered to the corresponding target responsible person's client. Furthermore, by instructing the message server to generate message cards based on preset message card templates, the message format rendering logic is transferred from the compliance detection end to a dedicated message server, ensuring the standardization of message generation and the consistency of message format.

[0019] In one implementation of the first aspect, the meeting compliance detection system further includes a target responsible person client, and the method further includes: the target responsible person client receiving the non-compliance notification message; in response to a trigger operation for the query address, the target responsible person client sending a data query request to the report generation end and receiving the query result corresponding to the query address returned by the report generation end; the target responsible person client displaying the query result; wherein, the query result includes the report display data of the non-compliant meeting.

[0020] In the implementation of the above solution, the client of the responsible party responds to the trigger operation of the query address by sending a data query request to the report generation end and receiving and displaying the returned query results. This achieves automated connection from notification push to detail viewing, and improves the processing flow of the meeting compliance detection method in the data viewing stage. On the other hand, by directly requesting the query results corresponding to the query address from the report generation end, the operation of manually entering search conditions or filtering meeting data item by item in the independent reporting system is avoided, which improves the convenience and response speed of data viewing. Furthermore, by displaying query results that include non-compliant meeting report display data, the responsible party can directly obtain the meeting details that have been filtered and focused on according to the non-compliance dimension, reducing the time cost of manual investigation and location in the raw data.

[0021] In one implementation of the first aspect, the meeting compliance detection system further includes a report generation terminal, and the method further includes: the report generation terminal receiving a data query request sent by the target responsible person's client; wherein the data query request carries the query address; the report generation terminal executing a dataset query statement corresponding to the query address to obtain detailed information of the non-compliant meeting from the meeting database; the report generation terminal generating report display data based on the detailed information and returning the report display data to the target responsible person's client.

[0022] In the implementation of the above solution, the report generation end executes a dataset query statement corresponding to the query address to obtain detailed information about non-compliant meetings, and generates report display data based on this information and returns it to the client of the responsible party. This achieves the separation of query logic and report rendering, enabling the method to dynamically respond to different query requirements and generate corresponding visual data based on a unified interface, improving the flexibility of the report generation process and the relevance of data presentation. On the other hand, the execution of the dataset query statement corresponding to the query address obtains detailed information from the meeting database, and the use of pre-built query scripts enables the reuse and centralized management of query logic, avoiding the maintenance costs caused by repeatedly writing query conditions. Furthermore, the report display data is generated based on the obtained detailed information instead of returning the original detailed data, so that the returned data has already undergone visualization preprocessing, reducing the data format conversion burden on the client of the responsible party and improving the standardization of data display.

[0023] Secondly, embodiments of this application provide a meeting compliance detection method, the method comprising: The compliance detection process is executed as follows: Meeting data is retrieved from the meeting database based on a preset detection cycle, and compliance checks are performed on the meeting data based on preset compliance rules to identify non-compliant meetings; a non-compliance notification message is generated, wherein the non-compliance notification message includes a query address for non-compliant meeting information; the notification message is sent to the client of the target responsible party; in the next detection cycle, meeting data is retrieved from the meeting database again, and the non-compliant meetings or new meeting data associated with the non-compliant meetings are re-checked for compliance based on the preset compliance rules. If they are still non-compliant, the non-compliance notification message is generated and sent to the client of the target responsible party again. The following actions are performed by the client of the person in charge: receiving the non-compliance notification message; responding to the triggered operation for the query address, sending a data query request to the report generation end, and receiving the query results returned by the report generation end corresponding to the query address; displaying the query results; wherein, the query results include the report display data of the non-compliant meeting; The report generation end performs the following steps: receiving a data query request sent by the client of the target responsible person; wherein the data query request carries the query address; executing a dataset query statement corresponding to the query address to obtain detailed information about the non-compliant meeting from the meeting database; generating report display data based on the detailed information, and returning the report display data to the client of the target responsible person.

[0024] Thirdly, embodiments of this application provide a meeting compliance detection system, including: a compliance detection terminal, a target responsible person client, and a report generation terminal, wherein the target responsible person client and the report generation terminal are respectively communicatively connected to the compliance detection terminal, wherein: The compliance detection terminal is used to retrieve meeting data from the meeting database based on a preset detection cycle, and perform compliance detection on the meeting data based on preset compliance rules to identify non-compliant meetings; generate a non-compliance notification message; wherein the non-compliance notification message includes a query address for non-compliant meeting information; send the notification message to the client of the target responsible person; in the next detection cycle, retrieve meeting data from the meeting database again, and re-detect whether the non-compliant meeting or new meeting data associated with the non-compliant meeting is compliant based on the preset compliance rules; if it is still non-compliant, generate and send the non-compliance notification message to the client of the target responsible person again. The target responsible person's client is used to receive the non-compliance notification message; in response to a trigger operation for the query address, send a data query request to the report generation end, and receive the query results returned by the report generation end corresponding to the query address; and display the query results; wherein, the query results include the report display data of the non-compliant meeting; The report generation terminal is used to receive a data query request sent by the client of the target responsible person; wherein the data query request carries the query address; executes the dataset query statement corresponding to the query address to obtain the detailed information of the non-compliant meeting from the meeting database; generates report display data based on the detailed information, and returns the report display data to the client of the target responsible person.

[0025] Fourthly, embodiments of this application provide an electronic device, including: a processor, a memory, and a communication bus, wherein the processor and the memory communicate with each other through the communication bus; the memory stores computer program instructions that can be executed by the processor, and the computer program instructions are read and executed by the processor to perform the method provided in the first aspect or any possible implementation of the first aspect.

[0026] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the method provided in the first aspect or any possible implementation thereof.

[0027] In a sixth aspect, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method provided by the first aspect or any possible implementation of the first aspect.

[0028] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims and drawings. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a schematic diagram of the architecture of the meeting compliance detection system provided in the embodiments of this application; Figure 2 A flowchart illustrating a meeting compliance detection method applied to a compliance detection terminal, as provided in an embodiment of this application; Figure 3 A schematic diagram of a card message generated in an application scenario provided in this application embodiment; Figure 4 A flowchart illustrating the meeting compliance detection method applied to the client of the target responsible party, as provided in this application embodiment; Figure 5 A flowchart illustrating the meeting compliance detection method applied to the report generation end, as provided in this application embodiment; Figure 6 A schematic diagram of the interaction process of each terminal in the meeting compliance detection system provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0032] Currently, enterprises widely adopt script-based scheduled task-based basic data monitoring solutions as the main technical means for meeting data governance. This solution typically uses Python or Shell scripts to execute structured query language queries at preset intervals to filter meeting records that do not meet preset threshold conditions (such as attendance rates below a certain percentage). Then, the detection results, which include a list of problematic meetings, are pushed to the designated responsible person via email through a simple email transmission protocol. After receiving the email, the responsible person needs to manually log in to a separate visualization reporting platform (such as the EEBI system), manually enter the meeting identifier to search for detailed data, and confirm the processing status by manually marking or re-executing the check after rectification. Open source tools such as Apache Griffin also provide similar basic data inspection and email notification functions.

[0033] However, the aforementioned existing technical solutions have objective shortcomings in terms of notification delivery, data viewing, and process tracking. In the notification stage, email, as an asynchronous communication method, is easily lost in the daily information flow and lacks an instant reminder mechanism, resulting in insufficient delivery rate and timely response to critical governance notifications. In the data viewing stage, responsible personnel need to manually switch between different information systems and perform individual retrieval operations in the reporting system based on meeting identifiers provided in emails, resulting in fragmented data acquisition paths and high operational costs. In the governance tracking stage, existing solutions lack automated recording and feedback mechanisms for notification delivery status, responsible personnel's viewing and confirmation behavior, and subsequent rectification progress, making it difficult to grasp the governance status in real time and leading to insufficient transparency in the governance process.

[0034] In view of this, this application provides a meeting compliance detection method. This method achieves fully automated closed-loop management of meeting data from problem discovery to rectification by periodically and automatically detecting, generating notification messages containing query addresses, and re-detecting and re-notifying non-compliant meetings in the next detection cycle. On the other hand, it automatically acquires and detects meeting data based on a preset detection cycle, replacing manual inspection methods and improving the automation and timeliness of meeting compliance detection. Furthermore, by embedding query addresses in non-compliant notification messages, the responsible parties can directly access detailed information based on the address, eliminating the manual data search operation and improving the convenience of data viewing. Moreover, by re-detecting non-compliant meetings or related new meeting data in the next detection cycle and automatically triggering re-notification for cases that are still non-compliant, it achieves automatic verification and continuous tracking of rectification status, ensuring the integrity of the governance process.

[0035] Before introducing the meeting compliance detection method provided in the embodiments of this application, the meeting compliance detection system involved in the above method will be introduced first. For example... Figure 1As shown in the illustration, this application provides a meeting compliance detection system. The system includes: a compliance detection terminal 100, a target responsible party client 200, a report generation terminal 300, and a data storage terminal 400. The target responsible party client 200, the report generation terminal 300, and the data storage terminal 400 are all communicatively connected to the compliance detection terminal 100. The target responsible party client 200 and the report generation terminal 300 are also communicatively connected to the data storage terminal 400.

[0036] The aforementioned compliance detection terminal 100 serves as the core scheduling terminal of the meeting compliance detection system. Its main functions include automated inspection and closed-loop governance of meeting data. Based on a preset detection cycle, the compliance detection terminal 100 periodically retrieves meeting data from the data storage terminal 400 and performs compliance checks on the retrieved meeting data according to preset compliance rules to identify non-compliant meetings. Upon detecting a non-compliant meeting, it generates a non-compliance notification message containing the query address for the non-compliant meeting information and sends the notification message to the client 200 of the target responsible party. Simultaneously, the compliance detection terminal 100 retrieves meeting data again in the next detection cycle, re-executes compliance checks on the aforementioned non-compliant meetings or new meeting data associated with them, and triggers the generation and sending of notification messages again if non-compliance is still confirmed, thereby achieving automated closed-loop tracking of meeting data governance.

[0037] The aforementioned target responsibility client 200 is an interactive terminal deployed on the target responsibility side of the meeting compliance detection system. It is used to receive and process the meeting compliance detection results pushed by the compliance detection terminal 100. The target responsibility client 200 receives non-compliance notification messages from the compliance detection terminal, responds to the triggered operation for the query address in the notification message, sends a data query request carrying the query address to the report generation terminal 300, and receives the query results corresponding to the query address returned by the report generation terminal 300. It then visualizes the query results containing the non-compliant meeting report display data, realizing the terminal-side data processing flow from notification reception to detailed viewing.

[0038] The main functions of the aforementioned report generation terminal 300 include data visualization rendering. The report generation terminal 300 receives a data query request carrying a query address from the target responsible party's client 200, executes the dataset query statement corresponding to that query address to obtain detailed information about non-compliant meetings from the meeting database, generates report display data based on this detailed information, and finally returns the report display data to the target responsible party's client, realizing dynamic querying and visualization of non-compliant meeting data. The aforementioned report generation terminal 300 can be implemented using the EEBI platform, or alternatively using other business intelligence or reporting platforms that support dynamic filtering and display of specific data records through Uniform Resource Locator (URI) parameters (such as Tableau, Power BI, QuickSight, FineReport, etc.). All of these platforms possess the technical capability to receive data viewing requests carrying query parameters based on the Hypertext Transfer Protocol (HTTP), parse the filtering conditions encoded in the URI (such as meeting identifier, time range, department code), and dynamically render a visual report view focusing on a specific subset of data based on a pre-set data model or dataset query statement, thereby providing the target responsible party with a data detail viewing service equivalent to that of the EEBI platform.

[0039] The aforementioned data storage terminal 400 is a persistent storage terminal used in the meeting compliance detection system to store meeting business data. It establishes a communication connection with the compliance detection terminal 100 and the report generation terminal 300. The data storage terminal 400 stores the meeting database, persistently storing meeting data including meeting identifiers, meeting descriptions, meeting minutes, scheduled locations, organizer information, meeting timeout duration, attendance rate, and meeting status. In response to query requests initiated by the compliance detection terminal 100, the data storage terminal 400 returns corresponding meeting data to support compliance detection execution. In response to data query requests initiated by the report generation terminal 300 based on dataset query statements, it returns corresponding non-compliant meeting data to support report display data generation. Furthermore, as a persistent storage carrier for the meeting compliance detection system, the data storage terminal 400's storage scope is not limited to meeting business data but can also be extended to master data related to organizational structure. For example, a departmental database stores departmental data to persistently maintain organizational unit information such as departmental identifiers, departmental hierarchical relationships, and departmental head mappings, providing data support for automatic mapping of responsible persons and determination of notification recipients during compliance testing. A personnel master database stores personnel master data, including basic employee information (such as employee identifier, name, department, position, and contact information), reporting relationships (such as direct supervisor identifier), and account status (such as employment identifier), which are core human resource data. This data is used to establish the association path between meeting organizers and departmental responsible persons, and supports the resolution of the identifier of the target responsible person and the query of the receiving identifier, ensuring that notification messages can be accurately delivered to the corresponding responsible person's client.

[0040] It should be noted that the fields involving personal privacy in the meeting business data stored at the data storage terminal 400 (including employee identity information, organizational structure relationships, and meeting participation records, etc.) are all collected and stored based on the prior explicit authorization of the corresponding personnel or the legal processing basis established by the company's internal data governance system. The information authorization mechanism provides a data legality basis for subsequent compliance testing and processing.

[0041] Understandably, in some application scenarios, the aforementioned meeting compliance monitoring system may also include a group member client. The group member client is an interactive terminal deployed on the meeting organizer's side within the meeting compliance monitoring system. The group member client can establish a communication connection with the target responsible person's client 200. The group member client can receive rectification notices forwarded by the target responsible person based on non-compliant meeting information, display details of the corresponding non-compliance dimensions and data modification requirements, and respond to the meeting organizer's operational instructions to perform modification or supplementary operations on the meeting data to complete the meeting compliance rectification process.

[0042] Of course, after receiving a notification message about a non-compliant meeting through the target responsibility client 200, the person responsible for the task can also verbally notify the corresponding meeting organizers, instructing them to rectify the non-compliant meeting data. The organizers can then use their client or other data maintenance terminals to modify or supplement the meeting data to complete the meeting compliance rectification process.

[0043] In the aforementioned meeting compliance detection system, the compliance detection terminal 100 retrieves meeting data from the data storage terminal 400 based on a preset detection cycle and performs compliance detection on the meeting data according to preset compliance rules to identify non-compliant meetings. Subsequently, it generates a non-compliance notification message containing the query address for non-compliant meeting information and sends it to the target responsible party's client 200. In response to the trigger operation for the query address, the target responsible party's client 200 sends a data query request to the report generation terminal 300. The report generation terminal 300 executes the corresponding dataset query statement to retrieve detailed information from the data storage terminal 400 and generates a report to display the data. In the next detection cycle, the compliance detection terminal 100 retrieves meeting data again and re-detects the aforementioned non-compliant meetings or related new meeting data. If it is still non-compliant, it generates and sends a notification message again, realizing continuous tracking and closed-loop governance of the meeting data compliance status.

[0044] like Figure 2 As shown, optionally, the meeting compliance detection method applied to the aforementioned compliance detection terminal 100 may include: Step S110: Obtain meeting data from the meeting database based on a preset detection cycle, and perform compliance detection on the meeting data based on preset compliance rules to identify non-compliant meetings.

[0045] The aforementioned conference database is deployed on data storage terminal 400, serving as a persistent storage medium for conference business data and providing data query and retrieval services to compliance testing terminal 100 and report generation terminal 300. The conference database can adopt a distributed architecture design, supporting high-concurrency queries and real-time data updates, meeting the performance requirements of periodic batch queries from the compliance testing terminal and real-time detailed data queries from the report generation terminal. The conference database can employ a relational online analytical processing (OLAP) database that supports real-time query updates, such as a distributed OLAP database built on open-source StarRocks, leveraging its columnar storage and vectorized execution engine features to achieve high-frequency ad-hoc queries and batch data analysis. In certain application scenarios, a combination architecture of a traditional relational database management system or a distributed file system and columnar database can also be used.

[0046] The aforementioned meeting database stores structured meeting business data, which can include dimensions such as participant information, basic meeting information, and meeting execution information. Participant information reflects the identity and organizational affiliation of the meeting organizer, including participant name, department ID, personnel type, and direct supervisor ID. Basic meeting information reflects the static attributes and basic metadata of the meeting, including meeting name, topic, description, scheduled location, date, start time, end time, and status. Meeting execution information reflects the actual execution process and results of the meeting, including participant list, attendance rate, actual meeting duration, meeting minutes status, and whether the meeting was a formal event. This data is stored in structured record format and supports multi-dimensional retrieval based on time range, department ID, organizer ID, and status ID.

[0047] The aforementioned preset detection cycles can adopt a periodic scheduling method based on time expressions. The time pattern for task execution can be defined using Cron expressions or similar time scheduling syntax. This supports triggering the meeting data acquisition and compliance detection process at fixed time intervals (e.g., hourly, daily, weekly) or specific time periods (e.g., 11:00 AM to 10:00 PM on weekdays), enabling automated scheduled execution and unattended operation of detection tasks. The preset detection cycles can also adopt an event-driven triggering method. By listening to data change events (such as new meeting records, status updates, or field modifications) in the meeting database's change logs or message queues, the compliance detection process is triggered immediately upon detecting a specific data event, achieving real-time compliance verification of newly generated or changed meeting data. Furthermore, the preset detection cycles can also support manual triggering. Through the instant execution interface or API calls provided by the management interface, business administrators or external systems can manually initiate the detection process based on temporary audit needs or sudden governance tasks, enabling on-demand execution and flexible scheduling of detection tasks.

[0048] The aforementioned preset compliance rules are a set of judgment criteria pre-configured and stored in the meeting compliance detection terminal 100 or the associated metadata database. They are used to define compliance standards for meeting data in terms of completeness, standardization, and quality. These preset compliance rules serve as the basis for the compliance detection terminal 100 to perform meeting data screening and judgment. By comparing the actual data records in the meeting database with the threshold conditions or status requirements defined in the rules, meeting data records that deviate from compliance standards are identified and filtered out.

[0049] Optionally, step S110 above performs compliance checks on the meeting data based on preset compliance rules to determine non-compliant meetings, including: checking whether the key information fields of the meeting data meet the integrity requirements; if the key information fields are missing, the meeting is determined to be a non-compliant meeting; wherein, the key information fields include at least one of meeting description information, meeting minutes, scheduled location, and organizer; and / or, checking whether the meeting execution process reflected by the meeting data meets the normative requirements; if the meeting execution process does not meet the normative requirements, the meeting is determined to be a non-compliant meeting; wherein, the normative requirements include at least one of meeting overtime duration limit requirements, attendance rate target requirements, and meeting time compliance requirements; and / or, checking whether the meeting data meets preset quality requirements; if the meeting data does not meet the preset quality requirements, the meeting is determined to be a non-compliant meeting; wherein, the preset quality requirements include at least one of the following: accuracy requirements for verifying the consistency between meeting data and source data, consistency requirements for verifying the consistency of key information of the same meeting in different business systems, and timeliness requirements for verifying the time interval between the entry time of meeting-related documents and the end time of the meeting.

[0050] The aforementioned integrity check dimensions are primarily used to identify and mark meeting records with missing key fields during the data entry phase. By verifying the completeness of the meeting's basic metadata, it ensures that the meeting data has basic usability in terms of record structure, avoiding data governance blind spots or subsequent business process interruptions caused by missing key information. The integrity check dimensions detect the fill status of key information fields in the meeting data records. Key information fields, such as meeting description information, meeting minutes, scheduled location, and organizer fields, are checked for NULL values ​​or empty strings. When any of these key information fields is missing, the meeting record is determined to not meet the integrity requirements.

[0051] The aforementioned normative inspection dimensions are primarily used to ensure that the meeting execution process complies with preset business rules and management standards. Through quantitative evaluation of the actual meeting operation, they identify meeting behaviors that deviate from established standards, thereby promoting the efficient allocation and compliant use of meeting resources and achieving control objectives at the business process level. The normative inspection dimensions detect business execution process indicators reflected in the meeting data, such as: deviations of meeting overtime duration from preset overtime thresholds, compliance of actual attendance rates with preset compliance thresholds, and compliance of meeting start time with the specified time period. If any of the above execution indicators fails to meet the corresponding threshold requirements or time period restrictions, the meeting record is deemed to fail to meet normative requirements.

[0052] The aforementioned quality inspection dimensions are primarily used to verify the authenticity, reliability, and validity of meeting data, ensuring that data records accurately reflect objective facts. Through cross-system data consistency verification and timeliness constraint checks, data records with logical contradictions, information conflicts, or delayed entry are identified and marked, thereby guaranteeing the credibility and decision support value of meeting data assets. The quality inspection dimensions examine, for example: the consistency comparison results between meeting data and source data records to verify data accuracy; the cross-verification results of key information from the same meeting across different business systems such as calendar systems, expense reimbursement systems, and project management systems to identify data conflicts; and whether the time interval between the entry time of meeting-related documents and the meeting end time exceeds a preset delay threshold to determine data timeliness. If any of the above accuracy, consistency, or timeliness fails to meet the corresponding standard, the meeting record is deemed to have failed to meet quality requirements.

[0053] It is understandable that the specific testing indicators under the three dimensions of integrity, standardization, and quality inspection can all be customized by adjusting the parameter configuration in the preset compliance rules. For example, the integrity dimension allows configuration of the selection range of key information fields and the criteria for judging null values; the standardization dimension allows configuration of meeting timeout thresholds, attendance rate thresholds, and compliant meeting time periods; and the quality dimension allows configuration of source data consistency verification rules, cross-system key information mapping relationships, and document entry delay thresholds. This allows the testing standards to be flexibly adapted and dynamically adjusted according to the management intensity requirements of different departments or the data governance priorities of specific business scenarios. In addition to the three dimensions of integrity, standardization, and quality inspection mentioned above, the preset compliance rules also support the configuration of custom testing dimensions according to specific business scenarios or management needs. The expansion mechanism of compliance testing dimensions allows business managers to customize special testing indicators and corresponding judgment thresholds based on organizational structure characteristics, industry regulatory requirements, or internal audit standards, enabling meeting compliance testing to adapt to differentiated business scenarios.

[0054] In the above scheme, the preset compliance rules can take the form of, for example, configurable scripts. The following will describe the implementation method of compliance detection in step S110 above, in conjunction with the form of preset compliance rules: First implementation method: Pre-set compliance rules are in the form of configurable scripts; Optionally, the aforementioned preset compliance rules are encapsulated and stored in the database in the form of configurable query scripts. The query scripts include dataset query statements used to define non-compliance judgment conditions. Step S110 above performs compliance checks on meeting data based on the preset compliance rules, including: calling the query script to execute a query on the meeting database, and determining the results returned by the query as non-compliant meetings.

[0055] The aforementioned configurable query scripts refer to a set of Structured Query Language (SQL) instructions written and encapsulated in text form. This language serves as the standard query interface for relational databases, defining non-compliance criteria for meeting data through declarative data manipulation syntax. Configurable query scripts can be written using standard SQL syntax. For example, a SELECT statement can specify the meeting identifier, organizer, and date fields to be retrieved; the FROM clause can be used to join the meeting details table and the personnel information table; and the WHERE clause can be used to set filtering logic. For complex judgment logic, the script can use the WITH clause to construct a common table expression for hierarchical filtering of meeting records of specific department employees and their organizations, or use the CASE statement to calculate the meeting timeout duration and filter based on the calculation results. Configurable query scripts adopt a parameterized design, supporting dynamic updates and version control through the database management interface, enabling hot adjustments to detection thresholds and filtering logic without interrupting the detection service. During the execution phase, the compliance detection end 100 calls the script and the database execution engine performs a query on the meeting database, returning the data record set that meets the conditions defined in the script as the non-compliant meeting detection result, thereby decoupling the logical expression of business rules from the program execution flow.

[0056] Taking a specific application scenario as an example, an SQL execution script is configured for compliance checks. This script, a configurable query script based on preset compliance rules, is used to filter non-compliant meeting data from the meeting database. Its execution logic follows a hierarchical, progressive structured query design: Two subqueries are defined using a common table expression constructed with the WITH clause: Subquery b filters the target personnel range from the employee information table ods_ehr_user_1d, limiting it to active employees whose direct supervisor identifier is a specific value, whose employment status is active, and whose department identifier belongs to a preset set; Subquery a filters the meeting details view dwd_meeting_detail_all_view, limiting the meeting organizer to employees in the results returned by subquery b, while excluding records with meeting statuses of removed or canceled, verifying the consistency of the organizer's identity, and limiting the meeting date to the time range of the current date and the next day. During the main query phase, the script performs three core operations: First, it calculates the meeting timeout duration field `cstime` using the CASE conditional expression, based on the difference in seconds between the actual offline end time and the scheduled start time. A positive difference indicates an actual timeout, while a negative or zero difference indicates a zero value. Second, it de-identifies the meeting topic `event_summary` using a string concatenation function, retaining the first and last two characters and replacing the middle content with asterisks to create a privacy-protected display format. Third, it performs compliance checks using the WHERE clause, filtering out meeting records where the meeting description information is empty or an empty string (violating integrity requirements), or where the calculated timeout duration is greater than 600 seconds (violating normative requirements). Data sets that meet any of the above criteria are returned as non-compliant meeting detection results.

[0057] The second implementation method: Pre-set compliance rules are configured in a declarative manner; The aforementioned declarative configuration refers to a configuration method that uses structured markup language or configuration syntax to describe rule elements such as detection dimensions, target fields, threshold parameters, and logical operators in key-value pairs and hierarchical nested structures. The declarative configuration abstracts the compliance judgment logic from procedural query instructions, replacing the description of specific execution steps with the declaration of the expected detection state. This allows business managers to define detection standards for integrity, standardization, and quality dimensions by editing configuration files without needing to master structured query language syntax. Furthermore, the configuration data can be stored in a distributed configuration center or metadata database, supporting version control and dynamic hot updates.

[0058] When using declarative configuration, one implementation of the compliance detection in step S110 above is as follows: Load and parse the configuration file, and use the configuration parsing engine to convert the hierarchical declaration statements into an internal rule execution tree or abstract syntax tree representation. Then, map the declared field mapping relationships, threshold comparison logic, and Boolean combination conditions into underlying data query statements or in-memory data filtering operators. Subsequently, perform a traversal scan of the meeting database based on the converted execution logic, match and verify each meeting data record with the parsed rule conditions, and mark the record as a non-compliant meeting and include it in the detection result set when the record meets the declared non-compliance judgment conditions. Finally, achieve data compliance judgment based on declarative definition.

[0059] The third implementation method: Pre-set compliance rules are implemented using visual rule modeling. The aforementioned visual rule modeling refers to a configuration mode that constructs compliance judgment rules through a graphical user interface using drag-and-drop component arrangement and visual logic connection. Visual rule modeling can abstract the detection logic of integrity, standardization, and quality dimensions into reusable graphical operator nodes. Business managers can drag and drop field selection nodes, condition judgment nodes, threshold comparison nodes, and logic combination nodes through a canvas-style interactive interface and establish data flow connections. The complete rule chain from target field selection and condition judgment to result output is defined with a visual topology structure. Complex compliance rules can be configured and previewed without writing code, and the configuration results are persistently stored in a structured description language to support version management and backtracking.

[0060] When using a visual rule modeling approach, one implementation of the compliance detection in step S110 above is as follows: The graphical configuration engine parses and stores the rule topology description file, mapping node connections and node parameters to an internal execution plan. This then transforms the visually orchestrated field mappings, conditional expressions, and logical combinations into query execution statements or in-memory data processing pipelines for the meeting database. Subsequently, based on the transformed execution plan, the meeting data is traversed and calculated. For each data record, field extraction, condition judgment, and result aggregation are performed according to the processing flow defined by the visual topology. Records that meet the termination node conditions in the visual rules are marked as non-compliant meetings, and the detection results are output. This achieves automated conversion and execution from graphical rule definition to data compliance judgment.

[0061] The fourth implementation method: Pre-set compliance rules are integrated with a rule engine; The aforementioned rule engine integration refers to a configuration mode in which compliance judgment logic is externalized and dynamically managed in the form of independent rule files by embedding a professional rule engine framework (such as a forward chain inference engine based on the Rete algorithm or a backward chain inference engine based on the goal-driven approach). This mode utilizes the pattern matching, inference execution, and conflict resolution mechanisms provided by the rule engine to abstract the detection conditions of integrity, standardization, and quality dimensions into pluggable rule units. Rule conditions, actions, and priority relationships are defined through rule files (such as DRL format, decision tables, or decision tree descriptions), achieving complete decoupling between business rules and detection execution code. It supports dynamic loading, hot updates, and version rollback of rules, and can achieve complex cross-dimensional logic combinations through rule chains or rule flow orchestration.

[0062] When using a rule engine integration approach, one implementation of the compliance detection in step S110 above is as follows: Initialize the rule engine runtime environment and load the pre-compiled compliance rule library. The rule engine parses the rule files to build an internal pattern matching network (such as a Rete network) and establishes an index association between the meeting data attributes and the constraint patterns in the rule conditions. Subsequently, the compliance detection end inserts the meeting data records to be detected as fact objects into the rule engine's working memory, triggering the rule engine's inference loop. The engine automatically matches rules that meet the conditions based on the forward chain inference mechanism and executes corresponding actions (such as marking non-compliant status and recording non-compliant dimensions). When multiple rules are triggered simultaneously, arbitration is performed according to a preset conflict resolution strategy (such as priority weight, sequence number, or nearest matching principle). Finally, the rule engine returns the execution results (including the marked non-compliant meeting identifiers and violation dimension information) to the compliance detection end, completing the automated compliance judgment process based on the inference mechanism.

[0063] Fifth implementation method: Pre-set compliance rules are implemented using machine learning models; The aforementioned machine learning model refers to a configuration that uses a statistical learning model trained on historical meeting data as the basis for compliance judgment. Numerical representations of the meeting data are extracted through feature engineering and input into a pre-trained anomaly detection or classification model. Based on the data distribution patterns and correlations learned by the model, non-compliant records deviating from normal behavior are automatically identified. This approach eliminates the need for manually setting fixed thresholds or writing judgment logic, and can capture the nonlinear interactions and implicit rules between high-dimensional features. The aforementioned statistical learning model can employ Isolation Forest or One-Class SVM based on anomaly detection algorithms to identify deviation samples by constructing the distribution boundaries of normal meeting data; or it can use Gradient Boosting Decision Tree (GBDT) and Random Forest algorithms based on ensemble learning to train a binary classification model using historical labeled data to predict the compliance probability of meeting records; or it can use the Local Outlier Factor (LOF) algorithm based on density estimation to identify potential violations by measuring the local density deviation of meeting data points in the feature space.

[0064] When using a machine learning model, one implementation of the compliance detection in step S110 is as follows: Load the deployed pre-trained model and its accompanying feature converter, perform feature engineering processing on the raw meeting data obtained from the meeting database in the same manner as during the training phase, and convert it into feature vectors required for model input; then input the feature vectors into the model for inference calculation, and the model calculates and outputs prediction results based on internal parameters. These results can be anomaly probability values, classification labels, or anomaly scores that deviate from the normal pattern; map the prediction results to compliance judgment labels according to preset confidence thresholds or classification boundaries, and output the meeting records judged as non-compliant and their corresponding anomaly confidence or key feature contribution as detection results, thereby realizing automated compliance judgment based on a data-driven model.

[0065] Machine learning model forms and rule-based pre-defined compliance rules can achieve a fusion decision-making mechanism. This mechanism constructs a hybrid judgment framework, enabling the predictive output of the statistical learning model and the logical judgment of the explicit rules to coordinate at the feature layer, model layer, or decision layer. In some application scenarios, the confidence of rules and models can be quantified in real time, and their weights in the final decision can be dynamically adjusted. For example, this implementation method is: (1) Confidence quantification: The confidence level of each rule and model is numerically represented by dual-path parallel computing. The rule confidence score is generated based on historical statistical indicators. After the rule engine performs detection, it extracts the historical hit rate (the ratio of the number of rule triggers to the total number of detections) and historical accuracy (the ratio of the number of triggers that are manually verified and confirmed to be correct to the total number of triggers) within the detection cycle of the current rule chain in the past 30 days. The weighted summation formula is used to calculate the historical accuracy. Accuracy weight is set to 0.7 and historical hit rate weight is set to 0.3 to emphasize that judgment accuracy takes precedence over trigger frequency. The model confidence score is generated by superimposing the predicted probability value (range 0 to 1) output by the machine learning model with feature significance analysis. The contribution of key features to the prediction result is quantified by the SHAP value. The proportion of features with a contribution of greater than or equal to 0.2 is used as the correction coefficient. The model confidence score is calculated as: Model confidence score = predicted probability value × (0.5 + 0.5 × correction coefficient). Feature interpretability correction is incorporated into the model output probability to complete the independent quantification of dual-path confidence. (2) Dynamic weight configuration: The adaptability optimization of fusion decision-making is achieved through two stages: initial setting and real-time adjustment. The initial weight is based on the basic ratio of the meeting type. For example, the weight ratio of rules to model is set to 4:6 for multinational meetings to focus on the model's adaptability to cultural differences, and the weight ratio of rules to model is set to 7:3 for confidential meetings to focus on the rigid constraints of rule compliance. The real-time weight adjustment introduces user feedback factors, counts the user appeal rate of the test results (the ratio of appeals to notifications), and uses the exponential smoothing method (smoothing coefficient α is set to 0.8) to update the weights. The compensation coefficient is set according to the appeal rate threshold (increase by 0.1 when the appeal rate is below 5% and decrease by 0.2 when it is above 20%), so that the influence of rules and models in the final decision-making evolves dynamically according to the actual governance effect. (3) Conflict Arbitration and Early Warning: Based on the weighted voting strategy, conflict situations between the rules and the model detection results are handled. The final confidence score is calculated as the fusion of the rule confidence score × rule weight + model confidence score × model weight. 0.7 is set as the judgment threshold. When the final confidence score is greater than or equal to 0.7, it is judged as non-compliant, and otherwise it is judged as compliant. At the same time, a divergence early warning mechanism is established to monitor the absolute difference between the rule confidence score and the model confidence score as the divergence index. When the divergence is greater than or equal to 0.4, the case is automatically marked as a high-conflict case and transferred to the manual review queue. The original data, dual-path confidence scores and decision-making process are stored in the knowledge base to provide labeled samples and iterative basis for subsequent rule optimization and model retraining.

[0066] It is understandable that the aforementioned preset compliance rules support dynamic adjustment and version management based on business needs or management strategies through configuration management interfaces or version control systems. For example, rule parameters, threshold settings, and detection logic can be hot-updated and canary-released without interrupting the detection service, and each change generates an independent version identifier and retains historical version snapshots to support retrospective auditing and difference comparison. The dynamic adjustment mechanism of the preset compliance rules enables different organizational structures or business scenarios to deploy differentiated compliance strategies based on the same technical foundation. For example, different meeting timeout thresholds can be set for different departments, the scope of integrity verification for key information fields can be adjusted according to business lines, or the detection dimensions and rule combination modes can be switched according to management intensity requirements, thereby achieving flexible adaptation and refined control of meeting governance rules.

[0067] Step S120: Generate a non-compliance notification message; wherein, the non-compliance notification message includes the query address for non-compliance meeting information; Step S130: Send the notification message to the target responsible person's client 200.

[0068] The aforementioned non-compliance notification message is a structured data carrier generated by the compliance detection end 100 after completing the compliance detection of meeting data. It is used to convey information about the status of non-compliant meetings to the responsible parties. The non-compliance notification message carries key information such as the meeting identifier, description of the non-compliance dimension, and data access path. It aims to achieve targeted delivery and visualization of detection results through instant messaging channels or message push mechanisms, enabling responsible parties to promptly learn about the violations and specific attributes of meeting data within their jurisdiction. The query address for non-compliant meeting information is a network resource identifier embedded in the non-compliance notification message, used to locate and retrieve detailed data content of a specific non-compliant meeting. This address points to the details display page of the non-compliant meeting. By carrying parameterized query conditions, the reporting platform can directly render a view focusing on the non-compliant meeting and its related dimension information, thus allowing responsible parties to seamlessly jump to the details viewing interface based on a single trigger operation without performing manual retrieval.

[0069] Optionally, step S120 above may include: obtaining the number of non-compliant meetings; if the number of non-compliant meetings is greater than a preset threshold, extracting the meeting identifiers and corresponding non-compliant dimension information of the non-compliant meetings; and generating a non-compliant notification message based on the meeting identifiers, non-compliant dimension information, and query address.

[0070] The above solution uses a preset threshold mechanism to control the event triggering of non-compliant notification messages. This mechanism first obtains the total number of non-compliant meetings identified within the current detection period, then compares this number with a pre-configured preset threshold. The subsequent notification message generation process is only triggered when the number of non-compliant meetings exceeds the preset threshold; otherwise, notification generation is suppressed because the non-compliant data within the current period is considered acceptable or does not require immediate intervention. Setting an event trigger threshold mechanism aims to filter low-frequency or occasional data quality issues, preventing invalid or high-frequency notifications from interfering with the information of those responsible, and ensuring accurate delivery of notification resources. The preset threshold can be configured differently based on departmental management intensity, data governance maturity, or business importance. For example, a lower threshold can be set for core departments with high data quality requirements to achieve sensitive response (e.g., setting the preset threshold to 1), or a higher threshold can be set for departments with routine office work to tolerate a certain percentage of data entry errors. The threshold parameters support dynamic adjustment and tiered strategies, allowing the event triggering conditions to adapt to the business characteristics and governance needs of different organizational structures.

[0071] After meeting the quantity threshold, the information extraction stage begins, which mainly extracts the meeting identifiers and corresponding non-compliance dimension information of non-compliant meetings. The meeting identifier is used to uniquely identify a specific meeting record, and the non-compliance dimension information is used to explain the type of compliance violation of the meeting (such as incompleteness, normative violation, or quality defect). This information, together with the query address, constitutes the core content payload of the notification message, supporting the responsible party to quickly locate the problem, understand the nature of the violation, and implement rectification.

[0072] It is understandable that non-compliance notification messages can also employ a tiered triggering mechanism based on the severity of the violation. This mechanism sets differentiated triggering strategies based on the type of violation identified by the non-compliance dimension information and its corresponding severity level (e.g., missing key fields related to data security relative to empty descriptive information). When a non-compliant meeting of a specific severity level is detected, notification generation is forcibly triggered regardless of the number, ensuring that high-risk data quality issues receive immediate response. Non-compliance notification messages can also employ a cumulative triggering mechanism based on a time window. This mechanism statistically analyzes the frequency or trend changes of non-compliance occurrences in meetings managed by the same responsible party within a sliding time window. When the cumulative number of violations exceeds a preset frequency threshold or the violation growth rate exceeds an anomaly judgment threshold, notification generation is triggered. This is suitable for identifying persistent or worsening data governance issues. Furthermore, non-compliance notification messages can also employ an initial discovery triggering mechanism based on state change. This mechanism maintains a historical snapshot of the meeting's compliance status. When a meeting's data is detected to have changed from a compliant to a non-compliant status, notification generation is triggered. If the meeting remains non-compliant in subsequent detection cycles, it will not be triggered again, avoiding excessive notification interference for the same unresolved issue.

[0073] The query address can be generated by concatenating a pre-configured report template identifier with a meeting identifier. This method uses the pre-configured detailed report template identifier in the visualization reporting platform and the meeting identifier of a specific non-compliant meeting as path parameters or query parameters of the Uniform Resource Locator (URL) to form a complete network address pointing to the meeting details view. Alternatively, the query address can be generated using hash encoding of the dataset query statement. This method hashes or Base64-encodes the dataset query statement used to filter specific non-compliant meetings, using the encoded result as a dynamic routing parameter in the query address. The reporting platform receives this parameter, decodes it to restore the query logic, and executes it to locate and display the corresponding meeting details data. Furthermore, the query address can be generated by assembling query parameters based on fixed routing rules. This method, according to the URL routing specifications of the visualization reporting platform, encodes and assembles the basic access path with query parameter key-value pairs containing filtering conditions such as meeting identifier, time range, and department identifier to construct a complete address string that can directly access the pre-filtered data view.

[0074] The aforementioned non-compliance notification message can take one of the following forms: The first format: Non-compliance notification messages are sent via hyperlinked text messages; The aforementioned hyperlink text message refers to a non-compliant notification message encapsulated in plain text or hypertext markup language format. The hyperlink text message embeds the query address in the form of a Uniform Resource Locator (URI) string within the notification text content and presents it through clickable hyperlink anchors or directly copyable text links, enabling the responsible party to access the network address to obtain detailed data information about the non-compliant meeting by clicking or manually entering the information.

[0075] When using hyperlinked text messages, one optional implementation of step S120 above for generating non-compliance notification messages is as follows: extract the meeting identifier and corresponding non-compliance dimension information of the non-compliant meeting, and then concatenate the query address with the meeting identifier and the violation description text using string concatenation or template rendering to construct a message containing hypertext anchor tags (such as...). <a href=""查询地址”"> Meeting logo The message body should be either a plain text URL (such as the conference identifier: query address) or a plain text URL, ensuring that the network address is identifiable and accessible in the text.

[0076] Hyperlinked text messages can be sent to the target client 200 through various communication protocols and channels, including but not limited to email sending based on Simple Mail Transfer Protocol (SMTP), SMS push based on Short Message Peer to Peer (SMPP), or calling the text message sending interface through the application programming interface provided by enterprise instant messaging platforms (such as Lark, DingTalk, and WeChat Work) to achieve cross-platform message delivery.

[0077] The second format: Non-compliance notifications are sent via in-app notifications. The aforementioned in-application notification format refers to the technical form of displaying non-compliant meeting reminders in the message center, notification bar, or to-do list of applications installed on the client side of the target responsible person through the internal message push mechanism of specific enterprise applications (such as meeting management systems, data governance platforms, or enterprise internal office systems). This format requires the target responsible person to be logged into the application or to enter the system through the application startup process before they can view the notification content, thus achieving deep integration of notification display with business systems.

[0078] When using in-application notifications, one possible implementation of step S120 above for generating non-compliant notification messages is as follows: Construct a structured message body according to the interface specifications of the target application, encapsulate the meeting identifier, non-compliant dimension information, query address, and summary text of the non-compliant meeting into an object that conforms to the message format requirements of the application (such as a notification entity in JSON format), and attach metadata such as priority identifier, expiration timestamp, and business type tag, and convert it into a data payload that can be parsed by the application server through serialization operations.

[0079] In-application notifications can be sent to the target client 200 via an application programming interface call based on the Hypertext Transfer Protocol (HTTP / HTTPS). The compliance detection terminal 100 sends a request carrying the target user identifier and message content to the message push interface of the application server. The application server then delivers the notification to the target client 200 through its internal message queue or real-time communication channel (such as WebSocket long connection, server push event SSE); or it can be integrated using a software development kit (SDK) to generate and display notification entries within the application through writing to the client's local database or triggering the local notification manager.

[0080] The third form: Non-compliance notification messages are sent in the form of QR code image messages; The aforementioned QR code image message format refers to a message format in which the query address of non-compliant meeting information is converted into a two-dimensional barcode image through a specific encoding algorithm. This format utilizes the high-density information storage characteristics of QR codes to convert Uniform Resource Locator (URL) strings into graphic symbols that can be recognized by image acquisition devices. It supports the target responsible party to decode and obtain the original network address through the optical scanning component of the mobile terminal, and is suitable for scenarios that require offline display or cross-device transmission.

[0081] When using QR code image messages, one optional implementation of step S120 above for generating non-compliance notification messages is as follows: extract the meeting identifier and corresponding non-compliance dimension information of the non-compliant meeting, construct a query address string containing the meeting details, and then call a QR code generation algorithm (such as a QR code generation library using Reed-Solomon error correction coding) to encode the address into a two-dimensional matrix graphic and render it as image data in portable network graphics or Joint Image Experts Group format. Optionally, the meeting identifier or violation summary text can be overlaid in the image area to form a complete visual message content.

[0082] The QR code image message can be sent to the target client 200 through communication channels that support multimedia transmission, including but not limited to uploading image data through the image message application programming interface of the enterprise instant messaging platform and pushing it to the client's local storage by the server, or embedding it as an attachment in an email and sending it through the Simple Mail Transfer Protocol. After receiving it, the target client 200 parses the Uniform Resource Locator in the image through the image decoding engine and triggers subsequent viewing operations.

[0083] The fourth form: Non-compliance notification messages are sent in the form of work orders / task items; The aforementioned work order / task item format refers to creating structured pending task records through an enterprise process management system or work order management platform as a carrier for non-compliant meeting notifications. This format encapsulates non-compliant meeting information into work order entities with unique identifiers, establishes field mappings in the system that include meeting identifiers, non-compliant dimension descriptions, query addresses, and processing time limits, and drives status transitions (such as pending, processing, and resolved) through a workflow engine, thus incorporating notification reception and subsequent rectification tracking into a unified process management framework.

[0084] When using the work order / task item format, one optional implementation of the above step S120 to generate the non-compliance notification message is as follows: call the application programming interface or process engine service of the work order management system, instantiate the work order object and fill in the attribute fields, use the meeting identifier of the non-compliant meeting as the work order subject or associated business order number, use the non-compliance dimension information as the problem description or category tag, use the query address as the external link or attachment information, set the target responsible person as the work order handler or assigner, configure the priority level and response time limit parameters, and finally submit it to the work order database for persistence and trigger the workflow to start.

[0085] Work orders / tasks can be pushed to the target responsible person's client 200 through the internal notification mechanism of the work order management system. For example, reminders for to-do items can be pushed through in-site messages or message centers, or work order creation notification emails can be sent through email gateways. In addition, if the target responsible person's client 200 integrates the to-do item synchronization interface of the work order system, it can directly pull or receive real-time synchronized work order data and display the non-compliant processing task in the local task list.

[0086] The fifth format: Non-compliance notification messages are presented in the form of rich interactive message cards; The aforementioned rich interactive message card is a rich media message carrier defined based on a structured data format (usually JSON Schema). It can encapsulate meeting identifiers, descriptions of non-compliant dimensions, and query addresses into hierarchical visual view objects through declarative layout configuration, unlike the linear arrangement of plain text information. The rich interactive message format supports embedding interactive components (such as jump buttons or link anchors) within the message body, enabling the recipient to complete information viewing and trigger operations within a single interface, without switching applications or manually entering network addresses, thus deeply integrating notification display with data access paths.

[0087] Optionally, step S120 above may include: extracting the meeting identifier and corresponding non-compliance dimension information of the non-compliant meeting; assembling the meeting identifier, non-compliance dimension information and query address based on a preset message card template to generate a non-compliance notification message; wherein, the message card template is used to generate message cards that support interactive operations; the interactive operations include jumping to the corresponding report display page in response to a trigger operation on the query address.

[0088] The aforementioned message card templates are predefined structured data format specifications used to define the visual layout, information field arrangement, and interactive component configuration of rich interactive message cards. The message card templates are stored in markup language or structured data object format, defining the rendering position and presentation style of meeting identifiers, non-compliant dimension information, and query addresses within the card interface. They also pre-configure trigger areas to support interactive operations, ensuring that the generated message cards visually possess information hierarchy and functionally support user interaction.

[0089] During the generation process, the meeting identifiers and corresponding non-compliance dimension information of non-compliant meetings identified through compliance checks are first extracted. The meeting identifier uniquely identifies a specific meeting record, while the non-compliance dimension information describes the specific type of compliance violation. Subsequently, the extracted meeting identifiers, non-compliance dimension information, and pre-configured query addresses are injected as data parameters into the message card template. The template engine's variable substitution or data binding mechanism assembles the information fields and template structure, forming message content containing complete business data and access paths.

[0090] The query address is embedded in the message card as the core trigger element for interactive operations, and this address is presented in the card interface as a clickable element. When the person in charge of the target performs a trigger operation on the query address on the target person's client 200, the target person's client 200 can initiate a data query request to the report generation end based on the address, and respond to the request result by jumping to the corresponding report display page, realizing a seamless connection from receiving the notification to viewing the details.

[0091] The non-compliance notification message generated based on the above assembly process is presented in the form of a rich interactive message card. This card not only carries text information, but also integrates data display and operation entry into a single view through pre-set interactive logic. It allows the responsible person to directly access the detailed data of the non-compliance meeting through intuitive interface interaction without having to manually switch applications or enter search conditions.

[0092] Optionally, step S120 above may include: extracting the meeting identifier and corresponding non-compliance dimension information of the non-compliant meeting; calling the preset interface of the message server, passing the meeting identifier, query address, non-compliance dimension information and the receiving identifier of the target responsible person to the preset interface, so as to instruct the message server to generate the corresponding message card based on the preset message card template.

[0093] The default interface of the aforementioned message server is an application programming interface contract between the compliance detection terminal 100 and the message server, defined based on a standardized communication protocol (such as HTTP / HTTPS). This interface specifies the request method, data format, and authentication mechanism, enabling the compliance detection terminal 100 to delegate the message generation task to a dedicated message processing service through remote invocation, thereby decoupling the business logic from the message rendering logic.

[0094] The parameters passed during the call include the meeting identifier, query address, non-compliance dimension information, and the recipient's identifier. The meeting identifier is used to locate a specific meeting record within the message content; the query address provides the path information for viewing the data; the non-compliance dimension information describes the type of violation to support the business semantics of the message content; and the recipient identifier serves as the target address identifier for message delivery (such as a user account, device token, or session identifier), ensuring that the message is accurately delivered to the corresponding recipient's client 200. Upon receiving the interface call request, the message server executes a rendering process based on a preset message card template. It binds the passed meeting identifier, query address, and non-compliance dimension information to template variables, generates a rich interactive message card data structure conforming to a specific message protocol specification, and is responsible for subsequent message encoding, channel adaptation, and network transmission, ultimately pushing the final card data to the recipient's client 200.

[0095] The above solution transfers the responsibility of generating and rendering message cards to a dedicated message server, allowing the compliance inspection end to focus on compliance judgment and business logic processing. At the same time, it leverages the message server's expertise in template management, format conversion, and channel adaptation to improve the standardization of message generation and cross-platform compatibility. Furthermore, it achieves a loosely coupled architecture between the two ends through standardized interfaces, facilitating independent expansion and maintenance.

[0096] The aforementioned messaging service can be provided by an enterprise-level instant messaging platform, such as Lark. This platform provides standardized application programming interfaces (APIs) through its open platform (e.g., message card creation and sending interfaces), allowing the compliance monitoring terminal 100 to delegate message generation and delivery tasks to this instant messaging platform. The compliance monitoring terminal 100 calls the preset interfaces provided by the Lark open platform, passing in the meeting identifier, query address, non-compliance dimension information, and the recipient's identifier. The Lark server then uses its message card template engine to render, encode, and push the cards to the target client, thus leveraging the existing enterprise instant messaging ecosystem to generate and deliver non-compliance notification messages. The message cards generated by the Lark platform are as follows: Figure 3As shown, the card presents the meeting compliance inspection results in a structured rich media format, including a rule name field (displaying "Please go to the report to view non-compliant meetings" and the corresponding report query address), a trigger strategy identifier (displaying "Conditional rule triggered"), a trigger timestamp (displaying the specific trigger time "2025-07-15 22:00:03"), rule creator information (displaying the creator identifier "xx"), and a node ID (displaying the unique identifier "BZ1927668998846021632"). The query address is embedded as a hyperlink in the rule name field, allowing the responsible party to directly jump to the visual report to view detailed data on non-compliant meetings, achieving seamless integration of notification content and data viewing path.

[0097] Optionally, step S130 may include: determining the target responsible person from the preset responsible person configuration data based on the attribute information of the non-compliant meeting; wherein the attribute information includes at least one of the following: meeting organizer information, department identifier, and meeting type; the responsible person configuration data stores the mapping relationship between the attribute information and the responsible person identifier; and sending a notification message to the client corresponding to the target responsible person.

[0098] The attribute information of the aforementioned non-compliant meetings is business characteristic data used to establish the association path between meeting records and responsible persons. This includes at least one of the following: meeting organizer information (e.g., organizer name, employee ID), department ID (e.g., department number, business line code), and meeting type (e.g., project meeting, departmental meeting, ad-hoc meeting). This attribute information can be directly extracted from meeting data records or obtained through association queries, serving as the input key-value pairs for mapping queries. The responsible person configuration data can be a pre-established mapping table stored in the local cache of the data storage terminal or compliance detection terminal. This table stores the correspondence between attribute information and responsible person IDs (e.g., user account, employee number, device token) in key-value pairs or relational records, supporting multi-dimensional matching strategies based on single attributes or attribute combinations to ensure that the manager responsible for the governance of specific meeting data can be located in different business scenarios.

[0099] The above step S130 can use the extracted non-compliant meeting attribute information as a query key to perform exact matching or fuzzy matching operations in the responsible person configuration data, parse out the corresponding responsible person identifier, and then deliver the notification message to the client corresponding to the responsible person, thereby realizing the automatic association between the responsible person and the non-compliant meeting.

[0100] Step S140: In the next detection cycle, retrieve meeting data from the meeting database again, and re-detect whether non-compliant meetings or new meeting data associated with non-compliant meetings are compliant based on preset compliance rules. If they are still non-compliant, generate and send a non-compliance notification message to the target responsible person's client 200 again.

[0101] The above step S140 aims to achieve closed-loop tracking and governance of non-compliant meetings. The implementation of closed-loop tracking can include: (1) embedding an interactive operation button component in the rich interactive message card. This component establishes a communication link with the compliance detection end through a callback mechanism. When the responsible person clicks the button on the client, a status update request is triggered and a processing progress indicator (such as "processed" or "rectification completed") is carried, so that the system can capture the responsible person's processing intention in real time and automatically update the governance status record. (2) embedding a status update control (such as a drop-down selector or a confirmation button) in the details display page of the visualization report platform. This control establishes a data submission channel with the backend service of the report generation end, allowing the responsible person to directly select the processing status or submit rectification confirmation information on the same interface after viewing the details of the non-compliant meeting, so as to achieve seamless connection between data viewing and status feedback. (3) Push non-compliant meeting data to the enterprise process management system in the form of work orders. Create structured work order records in the work order platform through application programming interfaces, including meeting identifiers, non-compliance dimensions and processing time limits. Use the status flow mechanism built into the work order system (such as pending, processing, and resolved) to track the rectification progress, and achieve transparent tracking of the governance process through the closed-loop management of work orders. (4) Establish a dedicated feedback channel (such as a specific instant messaging group, email reply address or online form) to allow the responsible person to manually submit processing confirmation information through the channel after completing the rectification. The compliance detection end updates the governance status of the corresponding meeting records manually or semi-automatically by listening to the message flow of the channel or periodically pulling feedback data.

[0102] The above solution implements iterative compliance monitoring based on a preset detection cycle. In the next detection cycle, meeting data is re-acquired from the meeting database. The detection scope covers non-compliant meetings identified in the previous cycle, as well as newly added meeting data related to those meetings, enabling continuous issue tracking and associated risk monitoring. Based on preset compliance rules, the acquired data records are re-detected. By determining whether the meeting data remains non-compliant in the current cycle, persistent violations that have not been rectified or newly generated non-compliant data are identified. For meeting data that remains non-compliant after re-detection, a non-compliance notification message is generated and sent to the client of the responsible party, forming a closed-loop governance chain of issue discovery, notification, rediscovery, and re-notification. Conversely, if the meeting data meets compliance requirements, the notification trigger for that cycle is terminated, achieving an automatic closed-loop governance process.

[0103] like Figure 4 As shown, the meeting compliance detection method applied to the aforementioned target responsible person's client 200 may include: Step S210: Receive non-compliance notification message; Step S220: In response to the trigger operation for the query address, send a data query request to the report generation terminal and receive the query result corresponding to the query address returned by the report generation terminal 300; Step S230: Display the query results; wherein, the query results include the report display data of non-compliant meetings.

[0104] The mechanism for receiving non-compliance notification messages is based on a communication connection between the client and the message server. The responsible party's client 200 obtains notification messages generated by the compliance detection end by listening to specific communication channels (such as the message push channel of an instant messaging platform, an in-application message queue, or a system-level notification service). These messages are transmitted in structured data formats (such as JSON, XML, or binary protocols) and parsed into locally renderable message objects, ensuring complete reception of the notification content and state synchronization. The query address, as a network resource identifier embedded in the notification message, is presented in the client's user interface as a hyperlink, a clickable button, or an embedded component. When the responsible party performs a triggering operation (such as a mouse click, touch gesture, or keyboard confirmation) on the query address, the responsible party's client 200 captures this interaction event and parses the Uniform Resource Locator (URL) information in the query address, triggering the subsequent data query process.

[0105] The aforementioned data query request can be constructed according to the pre-defined interface protocol with the report generation terminal 300. The target responsible party's client 200 encapsulates the query address as a request parameter in a Hypertext Transfer Protocol request message (such as the Uniform Resource Locator path of a GET request or the request body of a POST request), and attaches the necessary authentication token and session identifier. This is then sent to the report generation terminal 300 through a network security channel to request the pre-screened meeting data corresponding to the query address. The query results are generated by the report generation terminal 300 based on the dataset query statement and returned to the target responsible party's client 200 in the form of structured report data (such as HTML pages, JSON data objects, or document streams in a specific format). The query results can be non-compliant meeting report display data rendered and processed by the report generation terminal 300, ensuring the completeness of the displayed content's visualization. The target responsible party's client 200 performs local rendering and display on the received query results, parsing the report display data through the browser kernel or native view components. The report view, containing meeting identifiers, organizer information, details of non-compliance dimensions, and related operation entry points, is presented in the user interface, allowing the target responsible party to directly view the specific violation attributes and rectification requirements of non-compliant meetings through a visual interface.

[0106] like Figure 5As shown, the meeting compliance detection method applied to the aforementioned report generation terminal 300 may include: Step S310: Receive a data query request sent by the target responsible party's client 200; wherein, the data query request carries a query address; Step S320: Execute the dataset query statement corresponding to the query address to obtain detailed information about non-compliant meetings from the meeting database; Step S330: Generate report display data based on detailed information and return the report display data to the target responsible person's client 200.

[0107] The aforementioned data query request receiving mechanism is established based on the network communication connection between the report generation terminal 300 and the target responsible party's client 200. The report generation terminal 300 receives data query requests based on the Hypertext Transfer Protocol by listening to a specific network port or Uniform Resource Locator path, parses the query address parameters and additional authentication and session information in the request message, and triggers subsequent data processing procedures after verifying the legitimacy of the request. There is a preset mapping relationship between the query address and the dataset query statement. Based on this mapping relationship, the report generation terminal 300 parses the report template identifier, filter condition parameters, or query statement hash value encoded in the query address, locates and calls the corresponding dataset query statement. This query statement is stored in the metadata database in the form of a pre-configured script, which is consistent with the query logic used by the compliance detection terminal to ensure the consistency of data filtering standards.

[0108] The execution of the dataset query statement is completed by the data query engine of the report generation terminal 300. This engine establishes a connection session with the conference database, sends the parsed query statement to the database execution engine, and the database performs filtering, aggregation, and calculation operations based on real-time data records, returning a result set containing detailed data of non-compliant conferences. This process utilizes the online analysis and processing capabilities of the database to achieve high-frequency real-time queries, ensuring the timeliness of the displayed data. The generation of the report display data is based on the detailed information returned by the query, and a visualization rendering transformation is performed. The report generation terminal 300 maps the original detailed data to a predefined report template structure, performs field formatting, desensitization processing, chart rendering, and layout arrangement operations, generating report view data suitable for client display.

[0109] To facilitate understanding of the working principle of the above-described meeting compliance detection method, this application embodiment also provides a specific application example of the method in a certain application scenario. This application scenario implements the above-described meeting compliance detection method using Lark. In this application scenario: Meeting business data (including participant names, department identifiers, meeting descriptions, start and end times, attendance rates, etc.) is continuously stored in a StarRocks distributed OLAP database deployed on the server. The data inspection platform (acting as a compliance checkpoint) periodically connects to this database every hour from 11:00 to 22:00 daily, based on a pre-defined CRON scheduled task expression, and calls pre-defined compliance rules (in the form of configurable SQL scripts) to perform queries and checks on the completeness of meeting descriptions (checking whether key information fields such as event_desc are NULL or empty strings) and the compliance of meeting timeout durations (calculating whether the difference between real_attend_cost_offline and attend_cost is greater than 600 seconds). When the number of non-compliant meetings returned by the query exceeds a pre-defined threshold, the data inspection platform... Based on the department identifier of the organizer of the non-compliant meeting, the corresponding department head is identified as the target responsible person from the preset personnel information database (main database). Then, the meeting identifier of the non-compliant meeting, the meeting topic after anonymization (keeping the first and last two characters and replacing the middle content with asterisks), and the non-compliance dimension information are extracted. The message card creation interface provided by Lark Open Platform is called, and the Lark receiving identifier of the target responsible person and the query address pointing to the EEBI reporting platform (carrying the report template identifier and filtering parameters) are passed in. The Lark server generates a rich interactive card with a link to view details based on the preset message card template and pushes it to the Lark client of the target responsible person.

[0110] After receiving the card message via the Lark client, the responsible person clicks the query link embedded in the card. The Lark client automatically launches the system browser and initiates a data query request to the EEBI reporting platform (as the report generation end 300). The EEBI platform parses the query address carried in the request, executes a dataset SQL script (stored in the MySQL metadata database) consistent with the data inspection platform's logic, performs a real-time query on the StarRocks database, obtains detailed information about the non-compliant meeting, and generates a report displaying the data (including anonymized meeting topic, participants, and overtime duration), which is then returned to the browser for visualization. After confirming the issue based on this detailed report, the responsible person uses Lark's instant messaging function to specifically notify the meeting organizer (participant) to supplement the data or make corrections. In the next inspection cycle (on the hour below), the data inspection platform will again retrieve data from the StarRocks database and perform the same compliance inspection, re-inspecting the aforementioned non-compliant meetings or new meeting data associated with them; if the meeting data still has not been rectified (still meets the non-compliance judgment conditions), the Lark card will be pushed to the target responsible person again, forming an automated closed-loop governance of inspection, notification, viewing, rectification, and re-inspection, until the meeting data meets the compliance requirements.

[0111] like Figure 6 As shown, based on the same inventive concept, this application also provides a meeting compliance detection method, which includes: Performed by compliance testing terminal 100: Step S110: Obtain meeting data from the meeting database of data storage terminal 400 based on a preset detection cycle, and perform compliance detection on the meeting data based on preset compliance rules to identify non-compliant meetings; Step S120: Generate a non-compliance notification message; wherein, the non-compliance notification message includes the query address for non-compliance meeting information; Step S130: The compliance testing terminal sends a notification message to the client of the target responsible person; Step S140: In the next detection cycle, retrieve meeting data from the meeting database again, and re-detect whether non-compliant meetings or new meeting data associated with non-compliant meetings are compliant based on preset compliance rules. If they are still non-compliant, generate and send a non-compliance notification message to the target responsible person's client 200 again.

[0112] Executed by the target responsible party's client 200: Step S210: Receive non-compliance notification message; Step S220: In response to the trigger operation for the query address, send a data query request to the report generation terminal 300 and receive the query result corresponding to the query address returned by the report generation terminal 300; Step S230: Display the query results; wherein, the query results include the report display data of non-compliant meetings.

[0113] Executed by the report generation terminal (300): Step S310: Receive a data query request sent by the target responsible party's client 200; wherein, the data query request carries a query address; Step S320: Execute the dataset query statement corresponding to the query address to obtain detailed information about non-compliant meetings from the meeting database; Step S330: Generate report display data based on detailed information and return the report display data to the target responsible person's client 200.

[0114] It is understood that the compliance detection terminal 100 in the meeting compliance detection system provided in this application embodiment can realize any one of the functions of the meeting compliance detection method applied to the compliance detection terminal 100 provided in this application embodiment, the target responsible person client 200 can realize any one of the functions of the meeting compliance detection method applied to the target responsible person client 200 provided in this application embodiment, and the report generation terminal 300 can realize any one of the functions of the meeting compliance detection method applied to the report generation terminal 300 provided in this application embodiment. The implementation principle and the resulting technical effect have been introduced in the foregoing method embodiment. For the sake of brevity, any part not mentioned in the system embodiment can be referred to the corresponding content in any of the foregoing method embodiments.

[0115] Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. (Refer to...) Figure 7 The electronic device 500 includes a processor 510, a memory 520, and a communication interface 530. These components are interconnected and communicate with each other via a communication bus 540 and / or other forms of connection mechanism (not shown).

[0116] The memory 520 includes one or more (only one is shown in the figure), which may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The processor 510 and other possible components may access the memory 520 to read and / or write data therein.

[0117] Processor 510 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The processor 510 described above can be a general-purpose processor, including a central processing unit (CPU), a microcontroller unit (MCU), a network processor (NP), or other conventional processors; it can also be a special-purpose processor, including a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0118] Communication interface 530 includes one or more (only one is shown in the figure) that can be used to communicate directly or indirectly with other devices to exchange data. For example, communication interface 530 can be an Ethernet interface; it can be a mobile communication network interface, such as an interface for 3G, 4G, or 5G networks; or it can be other types of interfaces with data transmission and reception functions.

[0119] One or more computer program instructions may be stored in the memory 520, and the processor 510 may read and run these computer program instructions to implement the meeting compliance detection method provided in the embodiments of this application and other desired functions.

[0120] Understandable. Figure 7 The structure shown is for illustrative purposes only; the electronic device 500 may also include more than [other components]. Figure 7 The more or fewer components shown, or having the same Figure 7 The different configurations shown. Figure 7 The components shown can be implemented using hardware, software, or a combination thereof. For example, electronic device 500 can be a single server (or other device with computing power), a combination of multiple servers, a cluster of a large number of servers, etc., and can be either a physical device or a virtual device.

[0121] This application also provides a computer-readable storage medium storing computer program instructions. These instructions are read and executed by a processor to perform the meeting compliance detection method provided in this application. For example, the computer-readable storage medium can be implemented as follows: Figure 7The memory 520 in the electronic device 500, or a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0122] This application also provides a computer program product, which includes computer program instructions. These computer program instructions are read and executed by a processor to perform the meeting compliance detection method provided in this application. For example, these computer program instructions can be stored in... Figure 7 The memory 520 in the electronic device 500 is located inside the memory, or it is stored in a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0123] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0124] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0126] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for detecting meeting compliance, characterized in that, Applied to a meeting compliance detection system, the meeting compliance detection system includes a compliance detection terminal, and the method includes: The compliance detection terminal retrieves meeting data from the meeting database based on a preset detection cycle, and performs compliance detection on the meeting data based on preset compliance rules to identify non-compliant meetings; The compliance detection terminal generates a non-compliance notification message; wherein, the non-compliance notification message includes a query address for non-compliant meeting information; The compliance testing terminal will send a notification message to the client of the target responsible person; In the next detection cycle, the compliance detection terminal retrieves meeting data from the meeting database again and re-detects whether the non-compliant meeting or new meeting data associated with the non-compliant meeting is compliant based on the preset compliance rules. If it is still non-compliant, the non-compliance notification message is generated and sent to the client of the target responsible person again.

2. The meeting compliance detection method according to claim 1, characterized in that, The compliance check of the meeting data based on preset compliance rules to identify non-compliant meetings includes: The system checks whether the key information fields of the meeting data meet the integrity requirements. If the key information fields are missing, the meeting is determined to be a non-compliant meeting. The key information fields include at least one of the following: meeting description information, meeting minutes, scheduled location, and organizer. And / or, detect whether the meeting execution process reflected by the meeting data meets the normative requirements. If the meeting execution process does not meet the normative requirements, then determine that the meeting is a non-compliant meeting. The normative requirements include at least one of the following: meeting overtime duration limit requirements, attendance rate requirement requirements, and meeting time compliance requirements. And / or, detect whether the meeting data meets preset quality requirements. If the meeting data does not meet the preset quality requirements, then determine that the meeting is a non-compliant meeting. The preset quality requirements include at least one of the following: accuracy requirements for verifying the consistency between the meeting data and the source data; consistency requirements for verifying the consistency of key information of the same meeting in different business systems; and timeliness requirements for verifying the time interval between the entry time of the meeting-related documents and the end time of the meeting.

3. The meeting compliance detection method according to claim 1, characterized in that, The generation of non-compliance notification messages includes: Obtain the number of the non-compliant meetings; If the number of non-compliant meetings exceeds a preset threshold, then the meeting identifier and corresponding non-compliant dimension information of the non-compliant meetings are extracted. Based on the meeting identifier, the non-compliance dimension information, and the query address, a non-compliance notification message is generated.

4. The meeting compliance detection method according to claim 1, characterized in that, Sending the notification message to the target responsible person's client includes: Based on the attribute information of the non-compliant meeting, the target responsible person is determined by querying the preset responsible person configuration data; wherein, the attribute information includes at least one of the following: meeting organizer information, department identifier, and meeting type; the responsible person configuration data stores the mapping relationship between attribute information and responsible person identifier; The notification message is sent to the client corresponding to the person in charge of the target.

5. The meeting compliance detection method according to any one of claims 1 to 4, characterized in that, The preset compliance rules are encapsulated and stored in the database in the form of configurable query scripts. The query scripts include dataset query statements for defining non-compliance judgment conditions. The compliance check on the meeting data based on the preset compliance rules includes: The query script is invoked to perform a query on the meeting database, and the results returned by the query are identified as non-compliant meetings.

6. The meeting compliance detection method according to any one of claims 1 to 4, characterized in that, The generation of non-compliance notification messages includes: Extract the meeting identifiers and corresponding non-compliance dimension information of the non-compliant meetings; Based on a preset message card template, the meeting identifier, the non-compliance dimension information, and the query address are assembled to generate a non-compliance notification message; wherein, the message card template is used to generate message cards that support interactive operations; the interactive operations include jumping to the corresponding report display page in response to a trigger operation on the query address.

7. The meeting compliance detection method according to any one of claims 1 to 4, characterized in that, The generation of non-compliance notification messages includes: Extract the meeting identifiers and corresponding non-compliance dimension information of the non-compliant meetings; Call the preset interface of the message server, and pass the meeting identifier, the query address, the non-compliance dimension information and the receiving identifier of the target responsible person to the preset interface, so as to instruct the message server to generate the corresponding message card based on the preset message card template.

8. The meeting compliance detection method according to claim 1, characterized in that, The meeting compliance monitoring system also includes a client for the responsible party, and the method further includes: The client of the person in charge receives the non-compliance notification message; In response to the triggered operation for the query address, the target responsible person's client sends a data query request to the report generation end and receives the query result corresponding to the query address returned by the report generation end; The client of the person in charge of the target displays the query results; wherein, the query results include the report display data of the non-compliant meeting.

9. The meeting compliance detection method according to claim 1, characterized in that, The meeting compliance detection system also includes a report generation module, and the method further includes: The report generation terminal receives a data query request sent by the client of the target responsible person; wherein, the data query request carries the query address; The report generation terminal executes a dataset query statement corresponding to the query address to obtain detailed information about the non-compliant meeting from the meeting database. The report generation terminal generates report display data based on the detailed information and returns the report display data to the client of the target responsible person.

10. A method for detecting meeting compliance, characterized in that, The method includes: The compliance detection process is executed as follows: Meeting data is retrieved from the meeting database based on a preset detection cycle, and compliance checks are performed on the meeting data based on preset compliance rules to identify non-compliant meetings; a non-compliance notification message is generated, wherein the non-compliance notification message includes a query address for non-compliant meeting information; the notification message is sent to the client of the target responsible party; in the next detection cycle, meeting data is retrieved from the meeting database again, and the non-compliant meeting or new meeting data associated with the non-compliant meeting is re-checked for compliance based on the preset compliance rules. If it is still non-compliant, the non-compliance notification message is generated and sent to the client of the target responsible party again. The following actions are performed by the client of the person in charge: receiving the non-compliance notification message; responding to the triggered operation for the query address, sending a data query request to the report generation end, and receiving the query results returned by the report generation end corresponding to the query address; displaying the query results; wherein, the query results include the report display data of the non-compliant meeting; The report generation end performs the following steps: receiving a data query request sent by the client of the target responsible person; wherein the data query request carries the query address; executing a dataset query statement corresponding to the query address to obtain detailed information about the non-compliant meeting from the meeting database; generating report display data based on the detailed information, and returning the report display data to the client of the target responsible person.

11. A meeting compliance detection system, characterized in that, include: The system comprises a compliance monitoring terminal, a target responsible party client, and a report generation terminal. The target responsible party client and the report generation terminal are respectively connected to the compliance monitoring terminal for communication. The compliance detection terminal is used to retrieve meeting data from the meeting database based on a preset detection cycle, and perform compliance detection on the meeting data based on preset compliance rules to identify non-compliant meetings; generate a non-compliance notification message; wherein the non-compliance notification message includes a query address for non-compliant meeting information; send the notification message to the client of the target responsible person; in the next detection cycle, retrieve meeting data from the meeting database again, and re-detect whether the non-compliant meeting or new meeting data associated with the non-compliant meeting is compliant based on the preset compliance rules; if it is still non-compliant, generate and send the non-compliance notification message to the client of the target responsible person again. The target responsible person's client is used to receive the non-compliance notification message; in response to a trigger operation for the query address, send a data query request to the report generation end, and receive the query results returned by the report generation end corresponding to the query address; and display the query results; wherein, the query results include the report display data of the non-compliant meeting; The report generation terminal is used to receive a data query request sent by the client of the target responsible person; wherein the data query request carries the query address; executes the dataset query statement corresponding to the query address to obtain the detailed information of the non-compliant meeting from the meeting database; generates report display data based on the detailed information, and returns the report display data to the client of the target responsible person.

12. An electronic device, characterized in that, include: A processor, a memory, and a communication bus, wherein the processor and the memory communicate with each other via the communication bus; The memory stores program instructions that can be executed by the processor, and the processor can execute the method as described in any one of claims 1 to 10 by calling the program instructions.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 10.

Images