Decision generation method and device based on multi-dimensional data verification, equipment and medium

Abstract

The invention relates to the technical field of data analysis, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a decision generation method based on multi-dimensional data verification, which comprises the following steps: receiving an authentication request and completing operation authority granting, obtaining a target data set, and performing multi-dimensional verification on the target data set based on an analysis strategy set, generating a first verification result, performing multi-source consistency verification through an authenticity verification service interface, generating a second verification result, generating a candidate decision scheme set based on data features of the first verification result and the second verification result, and generating a decision file containing an analysis conclusion according to the candidate decision scheme set. And feeding back the generation state of the decision file. According to the method, a scheme generation and feedback mechanism driven by the data verification result is constructed, so that joint verification of compliance and authenticity of the target data set is realized, and the interpretability of the result and the transparency of data processing are guaranteed while the decision-making efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data analysis, and in particular, to a decision-making generation method, device, equipment, and storage medium based on multi-dimensional data verification. Background Art

[0002] In the context of the increasingly fierce competition in the current corporate operation and employment environment, enterprises are paying more and more attention to data-driven management capabilities and employee protection mechanisms. Especially in processing employee information, business data compliance verification, and external data consistency verification, traditional manual processes are difficult to meet the dual requirements of efficiency and accuracy. With the expansion of the organization scale and the explosion of data volume, enterprises have put forward higher requirements for automated and intelligent data processing capabilities when performing centralized information processing and batch service configuration.

[0003] In the field of fintech business, especially in the group insurance underwriting scenario, insurance companies usually communicate with corporate customers offline through business development personnel and rely on manual collection of key fields such as the basic information, occupation category, and health status of the insured. The current underwriting process often requires repeated transmission of underwriting materials, manual verification of the compliance and authenticity of fields, and lacks the ability to batch parse and automatically verify structured data, resulting in a slow response and lagging feedback in the overall underwriting process, which seriously restricts the business acceptance efficiency of insurance companies. At the same time, due to the lack of a real-time processing progress feedback and verification status display mechanism during the underwriting process, corporate customers cannot grasp the real-time progress of the underwriting link and are also difficult to timely discover data defects and repair paths, further weakening the underwriting experience and business conversion efficiency.

[0004] In the field of medical and health business, enterprises or service institutions usually need to collect and verify information such as the health indicators, disease history, and physical examination reports of employees or customers to support the formulation of health protection configurations or service plans. However, in terms of multi-source data verification, existing technologies still mainly rely on manual processing and comparison of unstructured documents, and there are prominent problems such as a high data missing rate, inconsistent formats, and difficulty in determining authenticity. When it comes to cross-platform and cross-system data acquisition, the lack of a unified verification interface and consistency judgment standard not only leads to low data verification efficiency but also increases the decision-making delay and misjudgment risk.

[0005] In addition, in most industry practices, existing technologies generally lack a unified integration and analysis mechanism for the results of multiple verification links, are difficult to automatically integrate multi-dimensional abnormal information such as compliance status and authenticity marks, and also lack a structured decision-making model to support the generation of subsequent processing actions. The current system still relies on manual collation and static template filling during the decision-making document generation process, lacks the ability to automatically convert analysis conclusions into standardized output documents, and is also difficult to provide clear generation status feedback and traceable identifiers after the document is generated. Summary of the Invention

[0006] The main object of the present invention is to provide a decision-making generation method, device, equipment and storage medium based on multi-dimensional data verification, aiming to solve the technical problems in the prior art that there is a lack of an automated decision-making scheme generation and feedback mechanism driven by multi-dimensional verification results, resulting in a lag in the response of the data processing process and an opaque decision-making process.

[0007] To achieve the above object, the present invention provides a decision-making generation method based on multi-dimensional data verification, including:

[0008] Receiving an authentication request and completing the operation permission granting process according to the authentication request;

[0009] After completing the operation permission granting process, obtaining a target data set;

[0010] Performing multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result including a compliance status;

[0011] Performing multi-source consistency verification on the authenticity of the target data entries in the target data set through an authenticity verification service interface to generate a second verification result including an authenticity mark;

[0012] Generating a candidate decision-making scheme set based on the data characteristics of the first verification result and the second verification result;

[0013] Generating a decision-making document including an analysis conclusion according to the candidate decision-making scheme set and feeding back the generation status of the decision-making document.

[0014] Furthermore, to achieve the above object, the present invention provides a decision-making generation device based on multi-dimensional data verification, including:

[0015] An access authorization module for receiving an authentication request and completing the operation permission granting process according to the authentication request;

[0016] A data acquisition module for obtaining a target data set after completing the operation permission granting process;

[0017] A compliance verification module for performing multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result including a compliance status;

[0018] An authenticity verification module for performing multi-source consistency verification on the authenticity of the target data entries in the target data set through an authenticity verification service interface to generate a second verification result including an authenticity mark;

[0019] A candidate decision-making module for generating a candidate decision-making scheme set based on the data characteristics of the first verification result and the second verification result;

[0020] A decision document generation module, configured to generate a decision document including an analysis conclusion based on the set of candidate decision schemes, and feedback the generation status of the decision document.

[0021] Furthermore, to achieve the above object, the present invention also provides a computer device, which includes a memory, a processor, and a decision generation program based on multi-dimensional data verification stored in the memory and executable on the processor. When the decision generation program based on multi-dimensional data verification is executed by the processor, the steps of the decision generation method based on multi-dimensional data verification as described above are implemented.

[0022] Furthermore, to achieve the above object, the present invention also provides a computer-readable storage medium, on which a decision generation program based on multi-dimensional data verification is stored. When the decision generation program based on multi-dimensional data verification is executed by a processor, the steps of the decision generation method based on multi-dimensional data verification as described above are implemented.

[0023] Beneficial effects: The present invention relates to the technical field of data analysis and can be applied to business scenarios such as fintech and healthcare. A decision generation method based on multi-dimensional data verification is disclosed, including: receiving an authentication request and completing operation permission granting, obtaining a target data set after completing permission granting, performing multi-dimensional verification with an analysis strategy set to generate a first verification result including a compliance status; performing multi-source consistency verification on the authenticity of the target data entries through an authenticity verification service interface to generate a second verification result including an authenticity mark; generating a set of candidate decision schemes based on the data characteristics in the first verification result and the second verification result, further generating a decision document including an analysis conclusion, and feedbacking the generation status of the decision document. By constructing a scheme generation and feedback mechanism driven by data verification results, the present invention realizes the joint verification of the compliance and authenticity of the target data set, and generates a decision document and feedback status in a structured manner, improving decision-making efficiency while ensuring the interpretability of the results and the transparency of data processing. Description of the Drawings

[0024] The present invention will be further described below in conjunction with the drawings and embodiments. In the drawings:

[0025] Figure 1 is a schematic diagram of an application environment of the decision generation method based on multi-dimensional data verification in an embodiment of the present invention;

[0026] Figure 2 is a schematic flowchart of an embodiment of the decision generation method based on multi-dimensional data verification of the present invention;

[0027] Figure 3Schematic diagram of functional modules of a preferred embodiment of a decision-making generation device based on multi-dimensional data verification according to the present invention;

[0028] Figure 4 Schematic diagram of a structure of a computer device in an embodiment of the present invention;

[0029] Figure 5 Another schematic diagram of a structure of a computer device in an embodiment of the present invention. Detailed implementation manners

[0030] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0031] The decision-making generation method based on multi-dimensional data verification provided by the embodiments of the present invention can be applied to an application environment such as Figure 1 where the client communicates with the server through a network. The server can receive an authentication request through the client and complete the operation permission grant. After completing the permission grant, the server obtains the target data set, performs multi-dimensional verification with the analysis policy set, and generates a first verification result including a compliance status; performs multi-source consistency verification on the authenticity of the target data entry through the authenticity verification service interface, and generates a second verification result including an authenticity mark; generates a candidate decision plan set based on the data characteristics in the first verification result and the second verification result, further generates a decision file including an analysis conclusion, and feeds back the generation status of the decision file. The present invention realizes the joint verification of the compliance and authenticity of the target data set by constructing a scheme generation and feedback mechanism driven by data verification results, and generates a decision file and a feedback status in a structured manner, improving the decision-making efficiency while ensuring the interpretability of the results and the transparency of data processing. Among them, the client can be, but is not limited to, various personal computers, laptop computers, smart phones, tablet computers, and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of multiple servers. The present invention will be described in detail below through specific embodiments.

[0032] Please refer to Figure 2 , Figure 2 which is a flowchart of an embodiment of the decision-making generation method based on multi-dimensional data verification provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order.

[0033] As Figure 2 shown, the decision-making generation method based on multi-dimensional data verification proposed by the present invention includes the following steps:

[0034] S10, receiving an authentication request and completing the operation permission grant process according to the authentication request;

[0035] In this embodiment, the authentication request is a data interaction behavior initiated by the client to the server, used to indicate the identity information of the client and the scope of data access permissions expected. This request generally includes identity credentials and permission statement fields. The identity credentials can include username and password, biometric features (such as face images, fingerprint feature vectors), or encrypted digital certificates, etc. The permission statement field usually represents the data access scope requested by the user, the operation type (such as read, write, audit), and the business module or data level to which the data belongs. The structure of the authentication request can be extended according to different access devices. For example, a device identification code and a behavior feature summary can be attached in a mobile device, and a Cookie identifier and a session token can be attached in a Web terminal.

[0036] The process of granting operation permissions verifies the validity of the identity credentials in the authentication request and performs permission grading and matching by combining the content of the permission statement with the preset permission mapping relationship in the system. The identity verification process is usually implemented by calling an internal or third-party identity authentication module, which has functions such as comparing biometric feature vectors, verifying the validity of certificates, and checking whether the credentials have expired. Once the authentication module confirms that the identity credentials are true and reliable, a permission level will be generated, which reflects the scope of data operations that the current identity can perform in the system. The permission level usually exists in the form of an integer level, a role label, or a function matrix, supporting flexible mapping and fine-grained control.

[0037] After completing the identity verification, the system will generate an authorization token based on the permission statement scope and the verification result. This token is a stateful access credential, carrying fields such as identity identification information, permission level, access scope, and token validity period, used to quickly determine whether a request is legal during subsequent data access and processing. This authorization token can be implemented using JWT (JSON Web Token), OAuth token, or a custom structured access token within the enterprise. The generated token will be returned to the client through an encrypted channel and bound to the user session. At the same time, to improve the traceability of the access process, the entire process of the authentication request needs to be recorded, including the identity verification status, the declared permission scope, the permission level granted by the system, and the timestamp, and this information will be written into a dedicated authorization log database or a chained evidence storage system for subsequent auditing and anomaly tracking.

[0038] In the implementation process, the identity credentials can be flexibly switched according to the application scenario. When the system is deployed in an enterprise-level application environment, the employee work number can be used in combination with a dynamic password as the basic credential; when facing external institutions or individual users, a CA certificate and a public key infrastructure can be introduced to achieve a higher level of authentication security. When the authentication request comes from a multi-terminal system, such as a PC terminal, an APP terminal, or an embedded terminal, cross-platform authentication unity can be achieved through a unified interface protocol standard (such as OAuth2.0, SAML).

[0039] The mapping strategy of operation permission levels can also be optimized according to the risk level of the business and the user stratification strategy. For example, in the financial industry, a four-level permission control model can be adopted, including read-only, edit, approval, and super administrator. In the healthcare industry, access permissions can be marked according to the level of sensitive data, such as ordinary fields, desensitized fields, and non-exportable fields. The system can also introduce a dynamic permission adjustment mechanism when processing authorization tokens to dynamically restrict or expand permission levels based on the evaluation results of user behavior.

[0040] The authorization log database can be stored using a highly available structure, such as a distributed log database (Kafka, Pulsar) or combined with blockchain for an immutable permission track record, ensuring a clear audit basis in case of future permission disputes.

[0041] Example: In a healthcare scenario, the human resources department of a hospital logs in to the data processing platform system through a PC terminal and initiates an authentication request containing a CA digital certificate and an organization code. The system calls the authentication interface of the Ministry of Public Security to verify the digital certificate and determines the permission level of "health data viewing and report exporting" for this department according to the organization code by looking up the table. Subsequently, a JWT authorization token containing the permission level field is generated and returned to the client, and the authentication request is recorded in the hospital data chain log platform.

[0042] In a financial scenario, a group insurance account manager of an insurance company submits an authentication request through a mobile device, carrying their dynamic password, employee number, and the declared "insurance application data review" permission scope. The system calls the internal LDAP authentication module to confirm their identity. After determining that their permission declaration is legal, the "review and countersign" permission level is granted, an authorization token containing the validity period and access scope is generated, and it is recorded in the financial risk control audit database to achieve an integrated processing of permission granting and behavior tracking.

[0043] Through mechanisms such as identity credential parsing, permission declaration comparison, permission level mapping, and authorization token generation, strong verification of operation legality can be completed before user data access, restricting illegal data access operations from the source and providing a complete permission context for subsequent data verification, permission control, and behavior auditing. This approach pre-positions and structures authentication and permission control, not only enhancing data security but also improving the scalability of the system in multi-user and multi-role scenarios.

[0044] S20, after completing the operation permission granting process, obtain the target data set;

[0045] In this embodiment, after the operation permission is granted, the system has the basic ability to control the data access scope according to the user permission level. On this basis, the system opens a data upload entry to the authorized client, allowing it to submit the data content to be processed, thereby forming a target data set that can be used for subsequent verification and analysis. To ensure the standardization and consistency of the data collection process, the system first provides the client with a structured template that defines the names, types, format requirements, and whether they are required fields of all key data fields. The types of fields can include numerical values, dates, strings, enumerated values, etc., and the format constraints can cover regular expression restrictions, field lengths, value ranges, etc., while the required field identifier is used to ensure the integrity of the core data.

[0046] The client fills in and uploads the data file using the structured template, and this data file usually adopts common structured formats such as CSV, Excel, JSON, XML, etc. After receiving the data file, the system first performs format parsing and extracts each data entry contained therein. Each data entry represents a set of business data records to be verified and analyzed, such as the basic information, health information, or historical behavior records of an employee.

[0047] After the data parsing is completed, the system performs field-level integrity verification on each data entry to check whether there are missing fields or non-compliant formats. For the data entries with problems, the system marks them and summarizes and generates an error report. The error report can include the field name, error type, line number where the data is located, etc., and is used to guide the user to correct it in a timely manner. The data entries that pass the verification are stored in the target data set. Logically, the target data set is a collection of data forms restricted by the permission level, and each entry will be assigned a unique data entry identifier as the basic unit for reference in the subsequent processing process.

[0048] To support subsequent operations such as data permission control, verification feedback, and policy invocation, the system constructs a data entry index based on each data entry. This index records the mapping relationship between the data entry identifier and the current client permission level, and is used to limit the access scope and operation types of users or modules with different permission levels to this data. The data entry index is usually stored in an efficient KV database or hash map structure to support fast retrieval and permission judgment.

[0049] The system can provide multiple structured templates for different business scenarios. For example, in health data analysis, the template can include fields such as name, ID number, gender, age, past medical history, BMI, blood pressure, and blood sugar, and it is specified that age, BMI, and blood pressure are required fields. In the education industry, fields such as course grades, examination subjects, and attendance days can be defined, and grades and attendance are strongly constrained.

[0050] The data upload format can also be flexibly adapted according to the capabilities of the client system. In a large enterprise environment, the system can support batch submission of JSON data through API interfaces; while in a small and medium-sized institutional environment, the system can support a Web form interaction mode mainly based on Excel file upload.

[0051] The error reporting mechanism can be designed as an automatic pop-up prompt, batch download of exception report files, or email push as needed, to support data entry personnel in quickly locating problems based on the feedback information. For entries with parsing failures or a high density of abnormal fields, the system can be configured not to store them in the target data set temporarily to avoid subsequent analysis exceptions.

[0052] In implementation, the target data set can adopt a row-level isolation mechanism, and users with different permission levels can only access the record rows within their permission scope. The data entry index can be dynamically bound to the permission level to support immediate update of data access control after subsequent permission changes.

[0053] Example illustration: In the medical and health scenario, after receiving an authorization token, a personnel administrator of an enterprise downloads a standardized health data template through a Web platform, exports the physical examination data in the hospital health examination system, fills it into the template in batches, and then uploads it. The system automatically identifies the upload file format and parses the data entries. During the verification, it is found that some employees lack blood pressure information. The system generates an error report to prompt modification and then re-upload. Finally, the physical examination data of the employees that pass the verification is stored in the target data set, and the system automatically establishes a mapping index between the employee numbers and the operation permission levels to ensure that only authorized users can perform subsequent viewing and analysis.

[0054] In the group insurance scenario in the financial field, an insurance agency submits an Excel file containing the list of insured employees and related indicators. After the system verifies the field formats, it is found that some of the occupation codes are filled in non-standardly, and immediately a prompt is popped up and an error file is generated for modification. The data with standard formats is incorporated into the target data set, and at the same time, an index relationship between the data entry identifiers and the agency permission levels is established to ensure that different business personnel can only operate the entries within their authorized scope when accessing the data.

[0055] Through the collaborative design of structured templates, field verification, data entry indexing, and permission level mapping, the standardization of the data upload process, error visualization, and refined control of data access permissions are achieved. It can effectively reduce verification failures and manual rework costs caused by non-standard data, improve the efficiency and quality of the data preparation stage, and at the same time provide a clean, compliant, and clearly-permissioned data foundation for subsequent multi-dimensional verification and decision-making.

[0056] S30, perform multi-dimensional verification on the target data set and a preset set of analysis strategies, and generate a first verification result including the compliance status;

[0057] In this embodiment, after obtaining the target data set, in order to comprehensively judge the compliance of the data, the system performs multi-dimensional verification on the target data set and a preset set of analysis strategies. This process is carried out with each data entry as a unit and performs policy matching and result judgment based on field types in multiple dimensions. The set of analysis strategies consists of multiple sub-strategies, and each type of sub-strategy is predefined based on specific field types and compliance judgment criteria, covering types such as numerical range strategies, risk level strategies, indicator compliance strategies, and compliance judgment strategies.

[0058] The system first performs structured parsing on the key attribute fields in each data entry. The key attribute fields include numerical fields, category coding fields, and indicator parameter fields. Numerical fields can include age, salary, evaluation scores, etc., which belong to continuous variables; category coding fields include discrete type variables such as occupation codes, industry classifications, disease types, etc.; indicator parameter fields can be used to represent key indicators with compliance benchmarks such as blood pressure values in health data, blood sugar levels, or default score values in financial scoring models.

[0059] After completing the field parsing, the system sequentially calls the sub-strategy modules in the set of analysis strategies for field-level verification. Among them, the numerical range strategy determines whether a numerical field is compliant by setting upper and lower limit intervals. For example, it verifies whether the income is in the range of 5K to 30K; the risk level strategy maps the category coding field to a risk level based on a mapping table and then compares it with the allowed risk level range; the indicator compliance strategy determines whether the indicator parameter field is within the normal value range according to industry rules or domain standards. For example, a BMI between 18.5 and 24.9 is considered normal.

[0060] When any field does not meet the corresponding policy conditions, the system marks the data entry as an abnormal state and records its abnormal type attribution. Subsequently, the system counts the abnormal state distribution of all data entries in the entire target data set, including the proportion of different abnormal types (abnormal numerical fields, abnormal category coding fields, abnormal indicator parameter fields).

[0061] After the statistics are completed, the system calls the compliance judgment strategy module, reads the distribution ratios of each abnormal type, and compares them item by item with the preset compliance thresholds. The compliance status represents the comprehensive judgment result formed based on the matching result of the abnormal type distribution ratio and the preset compliance judgment strategy after the target data set has been verified by multi-dimensional analysis strategies. The determination method of the compliance status can combine factors such as the severity degree, proportion, and policy weight of abnormalities in each dimension to support flexible configuration and context-driven judgment.

[0062] For example, in some embodiments, it can be judged in the following way:

[0063] Adopt the weighted synthesis method: Assign different weights to each type of anomaly, and form an overall judgment by calculating the weighted total score and comparing it with the compliance threshold.

[0064] Set the combined condition of the anomaly ratio: Only when multiple anomalies exceed their respective thresholds simultaneously is it determined as overall non-compliance, allowing a small over-limit in a single dimension.

[0065] Adjust the judgment rules based on the business scenario: For specific business types or industries (such as the medical industry being more sensitive to health data), a more stringent or more lenient tolerance range can be set.

[0066] Introduce composite indicators or machine learning models: In some extended methods, a judgment model can also be constructed based on historical compliance data to dynamically predict the compliance status.

[0067] In another implementation method, it can be set that only when the distribution ratios of all anomaly types do not exceed the threshold, the system determines the target data set as the overall compliance status; otherwise, it is regarded as the overall non-compliance status. In the finally generated first verification result, it includes the compliance status judgment result of the target data set and the distribution ratio details of each type of anomaly.

[0068] Various policy templates can be defined in the way of rule engine configuration. The numerical range policy can represent the field name, upper limit, lower limit, and unit through a JSON rule expression. For example, the legal interval of the "salary" field is set as [5000, 30000], and if the field value exceeds the range, an anomaly flag is triggered. The risk level policy can use a dictionary-like mapping structure to manage the correspondence between the code and the level. For example, the occupation code "A01" corresponds to low risk, "C99" corresponds to high risk, and then the allowed levels are set as "low" and "medium", and the rest are judged as anomalies. The indicator compliance policy can reference industry standards or enterprise-customized rule libraries and support cross-field joint verification rules, such as "if the age is greater than 60 years old, the BMI requirement is not higher than 25".

[0069] In different implementation scenarios, the policy judgment can adopt a combination of dynamic policy configuration and static policy definition. For businesses with frequently changing rules, the rule parameters can be adjusted in real time through a graphical policy modeling interface. For items required by laws or standards, the fixed template method can be used to ensure consistency.

[0070] The compliance judgment policy also supports flexible configuration. Different enterprises can set the compliance threshold according to risk control requirements. For example, the abnormal ratio of indicator parameters is set to be compliant when it is below 3%, or it can also be configured to trigger overall non-compliance only when the abnormal ratio of numerical fields exceeds 5%. The first verification result can be structured as a JSON document, and the fields include the compliance status identifier, the name and occupancy ratio of each abnormal field, and support subsequent calls by the policy module or display to users.

[0071] By binding different field types to corresponding sub - policy modules, automated, multi - dimensional, and high - granularity compliance determination of structured data in the target dataset is achieved. The system can not only quickly identify abnormal data, but also accurately classify and statistically analyze the proportion according to the type of anomaly, providing a structured basis for subsequent risk adjustment, processing strategy optimization, and decision - making generation, significantly improving the accuracy, standardization, and business transparency of data processing.

[0072] S40. Perform multi - source consistency verification on the authenticity of the target data entries in the target dataset through the authenticity verification service interface, and generate a second verification result containing authenticity marks.

[0073] In this embodiment, the authenticity verification service interface refers to a unified service access entry that can access multi - source data outside or within the system. This interface can access heterogeneous data sources such as identity authentication services, qualification verification platforms, medical data exchange platforms, and historical data archive systems, and is used to cross - compare and confirm the validity and consistency of input fields. Before performing authenticity verification, it is necessary to extract authenticity verification identifiers from the target data entries. The authenticity verification identifier is a set of data fields used to uniquely identify and initiate verification, usually including identity codes (such as unified social credit codes, ID numbers), qualification certificate numbers (such as professional qualification certificates, medical practice codes), and timestamp parameters (such as certificate issuance time, data generation time), and its composition should have uniqueness and verifiability.

[0074] The standardized verification request structure is transmitted to multiple independent data sources through the service interface, and the interface returns verification response data. Each verification response data contains field validity status (such as "valid", "invalid", "expired", etc.) and associated data version identifiers, which are used to determine whether it is the latest and whether it matches the request time window. In actual implementation, there may be problems such as inconsistent time updates and format differences in data from different sources. Therefore, the system needs to have result normalization and field matching strategies to correctly process the response data.

[0075] The main task of consistency verification is to compare the verification response results from multiple verification service interfaces and determine whether the field validity status is consistent and whether the data versions are consistent. If the field validity status of all data sources is "valid" and the data version identifiers match, then the target data entry is marked as the authenticity confirmation status. If there is any inconsistency (such as the status of an interface is "invalid" or the version numbers are significantly different), then the data entry is marked as the authenticity conflict status, and the conflict source and field difference content are recorded. The authenticity mark is used to guide whether the data entry is allowed to enter the decision - making analysis module in the subsequent process, or whether it needs to be transferred to manual review.

[0076] The authenticity mark and the conflict distribution ratio are components of the second verification result. Among them, the authenticity mark is the judgment label for each data entry, and the conflict distribution ratio is the proportion statistics of the authenticity conflict status entries in the entire target dataset, usually further classified by field type or source interface dimension to support the weight calculation and policy matching in the subsequent generation scheme.

[0077] In a certain implementation, a unified verification call gateway can be used as the encapsulation proxy for the authenticity verification service interface. After receiving a request containing a verification identifier, the call gateway initiates call requests to multiple interfaces in parallel according to the preset routing rules, supporting the unified processing of the interface return structure and the delay tolerance mechanism. The data returned by the interface is normalized and then stored in the internal verification cache structure. The consistency judgment module adopts a dual-verification mechanism. First, it judges whether the validity status fields returned by all verification interfaces are the same, and then it verifies whether the timestamp of the version identifier is within the tolerable range. For data entries in the conflict state, the system can also append metadata such as call logs, interface numbers, and return field snapshots to form a structured difference record. In some deployment architectures, to prevent verification interruptions caused by verification interface jitter or network outages, a distributed cache mechanism can be introduced, preferentially using the near-real-time verification cache results, and at the same time performing asynchronous consistency verification in the background and automatically updating the mark status. The number of verification failure retries and the retry interval can also be set to ensure that occasional interface exceptions do not affect the verification reliability.

[0078] Example illustration: In the field of medical and health, an enterprise customer uploads an employee's physical examination report containing the ID number, the occupational health certificate number issued by a medical institution, and the detection time. The authenticity verification service interface is respectively connected to the national health record service platform, the industry occupational health database, and the medical institution real-name authentication platform. There are situations where the health certificates of some employees have expired and the medical institutions are not on record in the field status returned by the interface. The system marks the corresponding entries as the authenticity conflict state and records the conflict source and field differences in the second verification result for subsequent manual review.

[0079] In the financial field, an enterprise uploads employee insurance information, which includes the employee's ID number, professional qualification code, and the generation time of salary data. Through cross-verification by connecting to the Ministry of Public Security real-name authentication platform and the industry credit investigation interface, the verification service interface finds that some employees have invalid ID cards or inconsistent professional qualification numbers. The system marks them as authenticity conflicts and calculates the conflict ratio for weighted calculation of the exception probability in the subsequent candidate scheme generation.

[0080] By designing a multi-source consistency verification mechanism, the problems of verification deviation and misjudgment caused by relying on a single data source are avoided. The structured definition of the authenticity verification identifier improves the standardization of interface requests and supports data traceability across platforms and time. The normalization of verification responses and the conflict marking rules enhance the ability to handle abnormal data, and the analysis of the conflict distribution ratio can provide a basis for high-confidence data screening for subsequent decision-making modules. Overall, the authenticity guarantee ability before data flows into the decision-making chain is improved, laying a foundation for the automation and trustworthiness of the entire process.

[0081] S50, generating a set of candidate decision-making schemes based on the data characteristics of the first verification result and the second verification result;

[0082] In this embodiment, the generation of the set of candidate decision-making schemes depends on two core source data, namely the data characteristics included in the first verification result and the second verification result. Among them, the first verification result includes the compliance status and the distribution ratio of abnormal types. These data characteristics are used to reflect the rule compliance of various data entries in the target dataset. The distribution ratio of abnormal types can be structurally divided into the proportion of numerical field abnormalities, the proportion of category code field abnormalities, and the proportion of index parameter field abnormalities. The second verification result includes the authenticity mark and the authenticity conflict distribution ratio, which are used to describe the data consistency level of the target data entry after multi-source consistency verification. The authenticity conflict distribution ratio is used to quantify the relative proportion of failed entries in multi-source verification.

[0083] The generation process of the decision-making scheme first takes the compliance status as the discrimination basis. The compliance status may include different levels such as overall compliance, partial abnormality, or overall non-compliance. According to this status, it is judged whether the current data is within the range that needs intervention, and it is decided whether to enter the scheme construction process subsequently. The distribution ratio of abnormal types and the authenticity conflict distribution ratio are used as auxiliary information to further measure the types and degrees of problems existing in the dataset. The extraction order of these information follows the sequence in which the verification results are formed to ensure the context consistency of the decision-making scheme.

[0084] The formation of the set of candidate decision-making schemes does not depend on external preset templates or rule libraries. Instead, driven by the current data characteristics, several response paths with execution characteristics are directly generated within the system. Each candidate scheme is a combination including a processing action and a priority setting. Among them, the processing action is a data processing instruction designed for the current data characteristics, such as field filling, abnormal record deletion, conflict record marking, etc. These actions come from the existing processing ability set within the system. The priority setting is the basis for sorting the processing actions and is used to guide sequential execution, concurrent execution, or trade-off execution in the execution process.

[0085] The data operation permission level, as a control variable determined through authentication requests in the previous stage, will affect the structure of candidate solutions in this stage. Specifically, a caller with a higher permission level can generate processing actions involving high-impact operations, such as directly modifying fields, deleting records, etc.; while a lower permission level can only generate lightweight processing paths such as exception marking and review suggestions. This permission forms a restriction and constraint mechanism with the currently generated candidate solutions to ensure that the solutions generated under different roles meet the operation compliance requirements.

[0086] Finally, the system constructs multiple candidate processing paths based on the combined features of the first verification result and the second verification result, and uniformly encapsulates them to form a set of candidate decision-making solutions. Each solution in the set has a clearly structured set of processing actions and a priority setting, while retaining its source data features as traceable identifiers, preparing for subsequent execution or presentation.

[0087] In one implementation, the system first receives the field data in the first verification result and the second verification result, extracts the compliance status identifier and the two types of abnormal distribution ratio data from them, and constructs a data feature vector containing six basic dimensions. These dimensions include: overall compliance level, numerical abnormal ratio, category code abnormal ratio, indicator parameter abnormal ratio, authenticity confirmation ratio, and authenticity conflict ratio.

[0088] The system judges the current data status according to the overall compliance level and sets the preset processing intensity level according to the ratio. For example, when any one of multiple dimensions exceeds the threshold, it is set to "require strong processing", otherwise it is set to "suggest review". On this basis, the system dynamically combines the existing sets of processing actions, including structure verification actions, field repair actions, and annotation actions, etc., and assembles them into candidate processing paths. The priority setting is normalized by the abnormal ratio value. For example, when the abnormal ratio of numerical fields is 60%, the processing actions of this type will be promoted to a high priority.

[0089] At the same time, the system reads the operation permission level of the current user, and filters the operation types that meet the level restrictions from the data permission control structure. For example, when the permission level is low, direct deletion operations are blocked, and only annotation and reminder operation instructions are retained. Through this combination logic, three to five significantly different processing paths are generated, each path with its own generation conditions and restriction ranges, and finally a set of candidate decision-making solutions is formed.

[0090] By jointly extracting data features from the first verification result and the second verification result and using them to generate a set of candidate decision-making schemes, the automatic decision-making ability for data abnormal structures can be realized without relying on an external rule engine. The generation strategy is dynamically adjusted using the quantification results of the abnormal type distribution and the authenticity conflict distribution, so that the generated schemes not only have pertinence and difference, but also can adapt to the operation requirements under different permission levels.

[0091] S60. Generate a decision-making document containing an analysis conclusion according to the set of candidate decision-making schemes, and feedback the generation status of the decision-making document.

[0092] In this embodiment, the set of candidate decision-making schemes is a structured aggregate containing multiple decision-making paths. Each candidate scheme already includes a combination of differential processing actions, a weight priority sequence, and a corresponding scheme analysis identifier. On this basis, the core goal of generating a decision-making document is to standardize and encapsulate the information of these structured candidate schemes and output them as decision-making support documents that can be used by users or downstream systems.

[0093] The generation process of the decision-making document first traverses the set of candidate decision-making schemes, extracts the processing action information, weight priority sorting structure, and analysis identification data in each candidate scheme. The combination of processing actions represents the operation path recommended by the scheme under the current data conditions. The priority sequence determines the execution order or processing priority of each processing action in the process. The scheme analysis identifier serves as the filing identifier for the risk characteristics, impact assessment, or execution suggestions of the scheme.

[0094] To ensure that the output document has general readability and clear structure, the system calls a predefined decision-making document template. The template contains a field structure for describing the processing logic, a parameter section for the execution order, and an auxiliary area for filling in user remarks or review suggestions. The selection process of the template is limited by the data operation permission level bound in the candidate scheme. Different permission levels correspond to content structures with different granularities. For example, the high-permission template allows the display of system call parameters for executable actions, while the low-permission template only displays review suggestions and result summaries.

[0095] After the template of the decision-making document is filled, it enters the analysis conclusion generation stage. The system maps the scheme analysis identifier and the priority structure to the conclusion section of the template and generates the analysis conclusion part in a structured text manner. These conclusions usually include the predicted compliance improvement probability under the current candidate scheme, the processing intensity level for abnormal items, and a summary of the avoidance strategy for authenticity issues. The generation process of the analysis conclusion content is based on the foregoing verification results and weight calculation, rather than manual entry, so as to maintain the objectivity and repeatability of the results.

[0096] When the template is filled, the system generates an intermediate decision file and performs trusted authentication on it. The authentication includes digital signature generation, generation of timestamp records, and embedding of operation permission levels to ensure a complete data security link when the file is accessed or called later. After the authentication is completed, the final decision file is generated.

[0097] The generation status monitoring mechanism of the decision file is presented in the form of a status identifier, which real-time marks the stage status of the file generation process, including initialization, filling, authentication, completion, or failure. If the generation process is successful, it is marked as "generated", and metadata information such as the version number, generation time, and operation permission level of the file is recorded. If the generation fails, for example, due to template loading failure, permission verification exception, etc., the status identifier is marked as failed, and an error code and failure description are appended.

[0098] Finally, the system encapsulates the status identifier, trusted authentication identifier, file access path, etc. into a file generation feedback message, pushes it to the client, and can trigger a page-level notification action to prompt the user that the current file is accessible or needs to be retried for generation.

[0099] In one implementation, the system traverses all the solutions in the candidate decision solution set, and extracts data for each solution in the order of first processing action combination, then priority structure, and then analysis identifier. With the differential processing action as the main trunk, a structure diagram is formed by combining the priority tags of each action, which is used to guide the presentation of the execution structure of subsequent files. The system calls the standard templates stored in the configuration module, such as JSON or XML format structure templates, and maps the above-extracted content to the corresponding fields in the templates. Among them, if the permission level of the current operating user is level three (medium permission), the template structure only contains the action description and processing suggestion fields. If it is level one (high permission), the operation execution parameters and interface call path fields are also added to the template. After the template is filled, the system uses the built-in signature module to encrypt and sign the file, generates a timestamp field at the same time, and obtains the permission level in the current operation session from the permission module for embedding. The signature combines the generation of SHA-256 hash digest and symmetric encryption to ensure that the document generation process and results have not been tampered with. The identification of the file generation status is maintained by the task management module in the internal state transition. When the file is generated and authenticated successfully, the status is updated to "generated", and the file version (such as V1.2.3) and access path are recorded synchronously. If it fails at any stage, such as missing fields, template loading failure, signature exception, etc., the system updates the status identification to "failed", and attaches codes such as ERR_TPL_LOAD_FAIL to the error report. The finally encapsulated feedback message is pushed to the front-end caller through the service interface, and the message structure includes the generation status identification, authentication identification, access path, and fault information fields. If the trigger method is an active operation, a feedback prompt will pop up on the front-end page synchronously; if it is an automatic execution strategy, the feedback message is written into the system log and archived.

[0100] By structuring the candidate decision solution set into a decision file with analysis conclusions and completing status synchronization through a unified feedback message mechanism, it not only improves the user's visual perception ability of the decision-making process, but also realizes the standardization, versioning, and permission binding control of decision-making outputs. By binding the data operation permission level to limit the template granularity, it ensures the operation boundaries of different roles, avoids the risk of operation overstepping authority, and at the same time combines a trusted authentication mechanism to provide integrity protection for decision files, significantly improving the transparency, compliance, and traceability of the decision-making system.

[0101] The present invention relates to the technical field of data analysis and can be applied to business scenarios such as fintech and healthcare. It discloses a decision-making generation method based on multi-dimensional data verification, including: receiving an authentication request and completing operation permission granting, obtaining a target data set after permission granting, performing multi-dimensional verification with an analysis strategy set, and generating a first verification result including a compliance status; performing multi-source consistency verification on the authenticity of the target data entry through an authenticity verification service interface, and generating a second verification result including an authenticity mark; generating a candidate decision-making solution set based on the data characteristics in the first verification result and the second verification result, further generating a decision-making document including an analysis conclusion, and feeding back the generation status of the decision-making document. By constructing a solution generation and feedback mechanism driven by data verification results, the present invention realizes the joint verification of the compliance and authenticity of the target data set, and generates a decision-making document and feedback status in a structured manner, improving decision-making efficiency while ensuring the interpretability of the results and the transparency of data processing.

[0102] In one embodiment, the above step S10 includes:

[0103] S101, receiving an authentication request sent by a client, and parsing the identity credential type and permission declaration scope in the authentication request;

[0104] S102, verifying the validity of the identity credential, and generating a verification result including a validity identifier;

[0105] S103, querying a preset permission mapping table according to the permission declaration scope, and associating the verified identity credential with the corresponding data operation permission level;

[0106] S104, if the validity identifier is in a valid state, generating an authorization token including the data operation permission level and returning it to the client;

[0107] S105, if the validity identifier is in an invalid state, terminating the process and returning a verification failure notice to the client;

[0108] S106, recording the verification process, permission declaration scope, and permission granting result of the authentication request in an authorization log database.

[0109] In this embodiment, when the client initiates an authentication request, the system first receives the request and extracts two basic parameters from the request: the type of identity credential and the scope of permission declaration. The type of identity credential can be user login information, device fingerprint, digital certificate, token serial number, or biometric feature data, etc., which have different applicability in multi-device authentication scenarios. The scope of permission declaration is usually used to indicate the type of data or the granularity of operations that the client expects to access, such as "read-only access", "structured write", or "audit level management", etc. This field forms the basis for subsequent permission matching and policy retrieval.

[0110] After extracting the parameters, the system enters the identity credential verification stage. In this stage, validity verification is performed based on the connected identity authentication service interface. This interface can be docked with the real-name authentication system of the public security network, the CA certificate system, the OAuth service, or the face recognition / fingerprint recognition engine, etc., and supports verifying the access subject through biometric features or encrypted credentials. After the verification is completed, the system generates a verification result and represents whether the verification is passed in the form of a validity identifier. This identifier is usually a boolean value or a status code, such as "verified", "unverified", "code_401".

[0111] On the premise that the verification is passed, the system checks against the preset permission mapping table according to the declared permission scope. This mapping table corresponds the identity level, authentication method, and data operation permission level. For example, the administrator identity is paired with full read / write permissions, and the audit identity is restricted to read-only operations. After the matching is completed, the system binds the verified identity in the current request to the corresponding data operation permission level and encapsulates it into an authorization token. This authorization token not only contains the permission level, but may also embed additional information such as the validity period, the client device ID, and the request context summary, etc., to support the traceability and risk control of the subsequent authorization process.

[0112] When the verification fails, the system stops further processing, but actively generates a verification failure notification message and immediately feedbacks it to the client to avoid unnecessary resource occupation and interference with subsequent processes. At the same time, the entire authentication and permission granting process is structured and recorded in the authorization log database. This database contains content such as the verification time, the called interface, the request IP, the declared permission, and the actually granted permission, etc., and supports operation and maintenance auditing, accountability, statistical analysis, and abnormal behavior backtracking.

[0113] In practical applications, the parsing process of identity credentials can be completed at the API gateway layer, and parameter verification and structured extraction are performed using the JSONSchema or protocol buffer protocol format. In terms of interface calls, a RESTful-based CA verification interface or a token verification service accessing OAuth2.0 can be called, or an asynchronous message mechanism integrated with the Ministry of Public Security's ID card verification service can also be used.

[0114] For the implementation of the permission mapping table, a configuration-based rule engine or a database-driven permission dictionary structure can be adopted. The configuration-based one is more suitable for scenarios with high-frequency policy changes, while the database-driven one has stronger adaptability in a multi-tenant environment. The generation of authorization tokens can be encapsulated in the standard format of JWT (JSON Web Token), including the permission level, timestamp, and signature digest for stateless verification between the front and back ends. For the log database part, a distributed audit storage mechanism can be adopted, combined with ELK (Elasticsearch, Logstash, Kibana) to achieve structured recording, fuzzy search, and real-time alerting.

[0115] In this embodiment, by constructing an integrated permission authentication mechanism including identity credential parsing, validity verification, permission mapping, and token generation, the authenticity of the client identity and the operation permissions are accurately bound, ensuring that subsequent data access behaviors are controlled, traceable, and auditable. The authentication efficiency and security of the system are improved, the authentication costs required for manual intervention are reduced, and data abuse or business risks caused by improper authorization can be effectively avoided.

[0116] In one embodiment, the above step S20 includes:

[0117] S201, providing a structured template with predefined fields for the client to download;

[0118] S202, receiving the data file uploaded by the client, parsing the structured data entries in the data file, and extracting the field content corresponding to the predefined fields in each data entry;

[0119] S203, traversing each data entry, verifying the integrity of the corresponding field content, and marking the data entries with missing required fields or format violations;

[0120] S204, storing the data entries that pass the verification into the target data set, and generating an error report for the data entries marked with missing required fields or format violations and returning it to the client;

[0121] S205, establishing a data entry index in the target data set that contains the mapping relationship between the data entry identifier and the data operation permission level.

[0122] In this embodiment, after the operation authority is granted, the system enters the data collection and structured entry stage. The first task is to provide the client with a structured template for unifying the data submission format. A structured template refers to a data file structure model with clearly defined field names, field types, field length limits, format rules, and required field identifiers, usually in formats such as Excel, CSV, JSON Schema, or Protocol Buffer. The fields in the template include all data items that the enterprise or user needs to submit, such as employee number, date of birth, occupation code, health index value, etc. Each field is accompanied by input constraints and instructions to ensure that the client completes basic verification during the reporting stage.

[0123] The data file uploaded by the client is processed by the system's parsing module, which includes file format identification, character encoding conversion, field mapping, and content extraction. The system extracts each structured data entry and matches the field order and format defined in the template, ensuring that the field content is consistent with the predefined template. Each data entry is a uniquely identifiable unit of data within the user's uploaded record, typically comprising a complete record consisting of multiple fields, such as a combination of an employee's personal and health information.

[0124] After parsing, the system verifies the integrity and compliance of each field. Integrity verification checks if required fields are empty, while compliance verification checks if field values conform to data type requirements (e.g., birth date in YYYY-MM-DD format, health indicators in numeric intervals, and occupation codes in specified classification standards). If a data entry is missing a required field or has an incorrect format, the system will mark the entry as unqualified and collect information about any abnormal fields.

[0125] For data entries that pass verification, the system formally writes them to the target dataset. The target dataset is a storage area for structured data, typically a relational database table or a key-value distributed storage structure. To support subsequent efficient access and permission control, the system simultaneously builds an index for each data entry. The index structure contains a mapping between the data entry identifier (such as a serial number, primary key, or hash value) and the previously generated operation permission level.

[0126] The permission level is used here as the basis for data isolation and process control. It is used to dynamically determine whether a certain type of user or module has the ability to access, modify, and analyze the data entry in subsequent stages such as policy verification, authenticity verification, and candidate solution generation, thereby forming a fine-grained data governance mechanism based on permissions.

[0127] The template can be in the Excel or CSV file format, accompanied by field names, field types, and data descriptions; or it can dynamically generate a fill-in form through front-end page rendering and generate a JSON Schema at the back-end for verification. The client upload process can integrate a drag-and-drop file upload component, combined with MIME type checking and pre-parsed format verification, to ensure that the uploaded file meets the platform standards. Field parsing can be implemented based on the field mapping module at the back-end, comparing the uploaded content with the field dictionary table to complete unified parsing; data verification can implement a multi-type verification mechanism through regular expressions, custom parsers, validator function libraries, etc. Unqualified data items can record the detailed field names, error types, and original values in the log module, and automatically generate a PDF or HTML view form as an error report and return it to the client. The design of the index structure can be implemented based on the hash index in the NoSQL storage system or the primary key index of the traditional database. At the same time, the permission level field can be used as an input parameter for the access control middleware to dynamically determine whether to allow this piece of data to enter the policy calculation or candidate solution generation logic. It is recommended that all index and permission association structures be stored in a dedicated permission mapping table to avoid mixing sensitive control logic in the main table.

[0128] In this embodiment, through the standardized template and the structured field constraint mechanism, the consistency and integrity of data submission are guaranteed; through the automatic verification of data field content, error marking, and feedback report, the automation level of data quality control is improved; through the data entry index and permission level binding mechanism, dynamic and fine control of data access behavior in the subsequent process is realized, avoiding unauthorized operations and process interference, and overall improving the efficiency and security of the system in the data collection and permission adaptation stages.

[0129] In one embodiment, the above step S30 includes:

[0130] S301, parsing the key attribute fields of each data entry in the target dataset, where the key attribute fields include numeric fields, category coding fields, and index parameter fields;

[0131] S302, calling the numeric range policy in the preset analysis policy set to determine whether the numeric field of the data entry is within the allowable threshold interval defined by the numeric range policy;

[0132] S303, calling the risk level policy in the preset analysis policy set, querying the risk level mapping table defined by the risk level policy according to the category coding field of the data entry, and determining whether the risk level of the data entry is within the allowable risk level range;

[0133] S304, calling the index compliance policy in the preset analysis policy set to detect whether the index parameter field of the data entry is within the normal value range defined by the index compliance policy;

[0134] S305, if any of the numerical field, category coding field, or indicator parameter field of the data entry does not meet the allowed conditions of the corresponding policy, mark the data entry as an abnormal state;

[0135] S306, count the total number of data entries in the abnormal state in the target dataset and the distribution ratio of abnormal types;

[0136] S307, call the compliance determination policy in the preset analysis policy set, and compare the abnormal type distribution ratio with the compliance threshold defined by the compliance determination policy;

[0137] S308, if the distribution ratio of all abnormal types does not exceed the corresponding threshold, determine the compliance status as overall compliance, otherwise determine the compliance status as overall non-compliance;

[0138] S309, generate a first verification result including the compliance status and the abnormal type distribution ratio.

[0139] In this embodiment, the target dataset, as a data set that has completed structured extraction and passed the permission review, contains multiple data entries. Each data entry consists of multiple fields, and the key attribute fields refer to the field types that have a core impact on compliance judgment in the business decision-making process, mainly including three categories: numerical fields, category coding fields, and indicator parameter fields. Numerical fields usually represent variables with numerical range significance, such as age, income, risk factor scores, etc.; category coding fields are discrete classification values, usually from industry standards or system internal codes, such as occupation categories, enterprise types, area codes, etc.; indicator parameter fields are complex indicators that need to be constrained or judged for compliance in combination with the business background, such as blood pressure levels, carbon emissions, or credit rating segmentation values.

[0140] Before starting the verification, the system parses each data entry in turn, extracts the above three types of fields, and constructs a mapping table structure as the input for policy execution. Then, the verification sub-policies in the analysis policy set are executed in turn.

[0141] The numerical range policy specifically sets a compliance judgment interval for numerical fields, and this interval can be predefined based on empirical rules, regulatory red lines, statistical quantiles, etc. The system compares each field value with the upper and lower limits of the threshold by looking up the table, and if it exceeds the range, it marks it as numerically abnormal.

[0142] The risk level strategy targets the category code field and uses a risk level mapping table to define the risk level intervals and acceptable level ranges for different categories. This mapping table can be sourced from an industry association, an internal risk assessment rule base, or the output of a data-driven model. The system queries the mapping table based on the field code to obtain the risk level. It then determines whether the level is acceptable within the preset policy range. If it exceeds the risk level, it is considered a risk anomaly.

[0143] Indicator compliance policies apply to indicator parameter fields. Their core purpose is to verify whether field values meet specific indicator specifications or business rationality boundaries. Compliance judgment criteria may include specification-defined intervals, multi-dimensional factor compound rules, and even the introduction of domain knowledge graphs for joint judgment.

[0144] The above three types of policies are executed in parallel. If a field does not meet the permitted conditions of its policy, the data entry is marked as abnormal. After all data entries are processed, the system counts the number of abnormal entries in the overall target dataset and calculates the distribution ratio of the three types of abnormalities by field type: the abnormal proportion of numeric fields, the abnormal proportion of category code fields, and the abnormal proportion of indicator parameter fields.

[0145] The compliance determination strategy determines overall compliance based on the statistically derived distribution ratios of anomaly types. The system extracts compliance threshold configurations from a pre-set policy set, which define the maximum tolerable ratio for each anomaly type (e.g., numerical anomaly ≤ 3%, coding anomaly ≤ 2%, and indicator anomaly ≤ 1%). The system then compares the anomaly distribution of the current data item by item to see if it exceeds the threshold. If all three ratios fall within the threshold, the system marks the compliance status as overall compliance; otherwise, it marks the system as overall non-compliance.

[0146] Finally, the system writes the compliance status and the distribution ratio of the abnormal type into the result structure to generate the first verification result, which is used to drive subsequent data authenticity verification and decision-making logic.

[0147] This implementation implements high-precision compliance verification of key fields in structured data, performing multi-dimensional assessments across three dimensions: numerical rationality, coding risk level, and indicator compliance. Furthermore, by comparing anomaly distribution statistics with compliance thresholds, it upgrades single-point verification to group behavior analysis, enhancing the ability to control the overall quality and risk profile of large-scale datasets. The generation of compliance status provides a clearly structured basis for subsequent decision-making, improving the automation and reliability of the policy generation process.

[0148] In one embodiment, the above step S40 includes:

[0149] S401, extracting the authenticity verification identifier of the target data entry;

[0150] S402, call at least two independent authenticity verification service interfaces, and send a standardized request message of the authenticity verification identifier to each authenticity verification service interface;

[0151] S403, receive the verification response data returned by each authenticity verification service interface, where the verification response data includes the validity status of the authenticity verification identifier and the associated data version identifier;

[0152] S404, compare the verification response data of different authenticity verification service interfaces, and detect whether the validity status of the authenticity verification identifier is consistent and whether the data version identifiers match;

[0153] S405, if the validity statuses returned by all authenticity verification service interfaces are consistent and the data version identifiers match, mark the target data entry as the authenticity confirmed status; otherwise, mark the target data entry as the authenticity conflict status, and record the identifier of the authenticity verification service interface with the conflict and the differences in the verification response data;

[0154] S406, count the distribution ratio of the target data entries in the target data set with the authenticity conflict status, and generate a second verification result including the authenticity mark and the authenticity conflict distribution ratio.

[0155] In this embodiment, during the process of verifying the authenticity of the target data set, to ensure that the verification result has sufficient accuracy and reliability, it is necessary to perform standardized extraction and comparison on the representative identity fields in each data entry. The authenticity verification identifier is a core field set extracted from the target data entry for cross-system and cross-source identity or data authenticity comparison. This identifier usually includes an identity code, a qualification certificate number, and a timestamp parameter. The identity code is used to uniquely identify the entity subject to which the data belongs, such as a personal identity number, an institutional registration number, etc.; the qualification certificate number can correspond to a medical practice qualification certificate, an academic certificate number, or a professionally recognized qualification code in the industry; the timestamp parameter is used to mark the generation or update time of the data to ensure that version synchronization issues can be identified during the verification process.

[0156] In the authenticity verification stage, the system needs to call two or more independent authenticity verification service interfaces. Each interface corresponds to an independent authoritative data source, such as a national identity information platform, an industry association certification platform, or a commercial data service provider, etc. The system constructs a standardized request message in a unified format according to the structure of the verification identifier, unifies the field order, format type, and encoding specification, and sends the message to each independent interface to complete the verification request.

[0157] The response data returned by the verification service interface contains two core fields: validity status and data version identifier. The validity status is used to determine whether the data is officially registered in the data source, whether it is in an active state, or whether it has been revoked or cancelled. The data version identifier represents the latest version number, generation batch, or update time of the data item in the data source, and supports version alignment and consistency confirmation across interfaces.

[0158] The system will compare the return results of all verification service interfaces, and separately detect whether the validity statuses are consistent and whether the data version identifiers match. If the verification results of all interfaces are completely consistent in terms of validity status, and the version identifiers are the same or meet the predefined version tolerance rules, then the data entry will be marked as the authenticity confirmed status. If there are contradictions in the return results between interfaces (such as one interface indicating valid and another indicating invalid), or there are version conflicts (such as a large deviation in the data update time), then the entry will be marked as the authenticity conflict status. For the conflict status, the system will also record the interface identifiers that caused the conflict and the respective data difference information returned, providing a basis for subsequent manual review, appeal handling, or data completion.

[0159] After all data entries are verified, the system will count the proportion of entries in the current target dataset with the authenticity conflict status, including the total number and the proportion of conflict entries, and package the results together with the authenticity mark of each piece of data to generate the second verification result. The second verification result serves as the final basis for judging data authenticity and can be used in subsequent decision-making plan generation and strategy adaptation processes.

[0160] The extraction method of the identity code can be automatically recognized through the primary key field defined in the data preprocessing template, or it can be extracted from the text in standard format through regular expressions. The qualification certificate number can be configured with the certificate type and number field name during structured data upload, and obtained through field name mapping. The timestamp parameter can be the upload time, data collection time, or the creation timestamp recorded in the source system, stored in the unified UTC format, and supporting millisecond-level precision.

[0161] The construction of the standardized request message can adopt the JSON structure, where each type of field uses a unified field name and standard encoding, such as "identityCode", "certificateId", "timestamp", and the integrity and legality are verified through a parameter verification tool before sending. The verification service interface call method supports HTTP, gRPC, or message middleware methods, and the response content returned by the interface needs to go through field extraction, encoding conversion, and standard structure mapping processing.

[0162] The definition of the validity status can include various status enumerations such as "valid", "invalid", "expired", "cancelled", etc. The data version identifier can be represented by a hash value composed of the data ID, version number, timestamp, etc. given by the original system. The response comparison module uses hash comparison, status merging strategies or priority fusion mechanisms to ensure comprehensive judgment in cases of version offset and inconsistent status. The recording mechanism for abnormal status can encapsulate conflict interface IDs, response codes, status values, etc. into difference objects and persist them to the abnormal tracking database. The statistical method for the distribution ratio of authenticity conflicts can generate a fine-grained report according to data batches, upload times, data source dimensions, etc. for subsequent analysis.

[0163] Example illustration: In the financial service scenario, the employee information submitted by an enterprise customer includes the ID number, enterprise qualification number, and data collection time. The system calls the national government affairs data platform to verify the validity of the ID card, and at the same time calls the industrial and commercial registration data interface to verify the validity of the enterprise qualification number. If the two interfaces return the same result, it is marked as the authenticity confirmation status. If the industrial and commercial interface returns that the enterprise has been cancelled or the information is lagged, it is marked as an authenticity conflict, and the interface response information is recorded for sales or risk control personnel to verify.

[0164] In the field of medical and health, the medical staff information uploaded by institutions includes the practice certificate number, registered ID card, and employment registration time. The system respectively calls the national health commission certification platform and the medical insurance system for verification to check whether it is an in-service registered person and whether there is a problem of repeated registration across regions. If the information is the same, it is an authenticity confirmation. If the certificate number does not exist in one interface, it is recorded as a conflict status and feedback to the hospital personnel system for supplementary reporting.

[0165] This embodiment effectively avoids the misjudgment problem caused by relying on a single interface verification by constructing a data authenticity verification process based on a multi-source comparison mechanism. By abstractly using the combined use of identity identification codes, qualification numbers, and timestamps, the ability to confirm the consistency of data from different sources is enhanced, further ensuring the technical requirements of true data sources, unified versions, and accurate timeliness. The annotation of the authenticity confirmation status provides a reliable input basis for subsequent decision-making, and the authenticity conflict ratio provides a quantitative indicator for the overall data quality assessment and process health monitoring, enhancing the interpretability and risk resistance ability of decision-making.

[0166] In one embodiment, the above step S50 includes:

[0167] S501, extract the compliance status identifier and the abnormal type distribution ratio in the first verification result, and extract the authenticity marking identifier and the authenticity conflict distribution ratio in the second verification result;

[0168] S502. Query the preset decision strategy library according to the compliance status identifier, and match the basic decision template corresponding to the compliance status identifier.

[0169] S503. Determine the composite exception probability weight value of each exception type and authenticity conflict according to the exception type distribution ratio and authenticity conflict distribution ratio. The composite exception probability weight value is used to adjust the expected execution priority parameter of the basic decision template.

[0170] S504. Generate multiple candidate decision schemes based on the basic decision template, composite exception probability weight value and data operation permission level.

[0171] S505. Perform exception probability analysis on each candidate decision scheme, determine the expected compliance improvement rate and data integrity loss rate after the execution of each candidate decision scheme, and generate a scheme analysis identifier.

[0172] S506. Associatively store the candidate decision scheme and the scheme analysis identifier to form a candidate decision scheme set.

[0173] In this embodiment, in order to achieve data-driven automated decision generation, it is necessary to use the verification results formed in the previous stage as structured input to drive subsequent policy scheduling and candidate scheme generation. Among them, the first verification result and the second verification result respectively carry the determination information of the compliance status and the authenticity status, constituting a dual dimension of the decision logic input. In the first verification result, the compliance status identifier refers to a structured field used to mark the overall compliance evaluation result of the target data set, and its form can be "overall compliance", "overall non-compliance" or a more refined level expression, such as "low-risk compliance", "high-risk non-compliance". This identifier, combined with the exception type distribution ratio, that is, the proportion values for three types of exceptions for numerical fields, category coding fields, and index parameter fields, constitutes a complete data feature set for compliance evaluation.

[0174] The second verification result contains an authenticity marking identifier, which is used to indicate whether the target data entry passes the authenticity consistency confirmation in multi-source verification. The corresponding authenticity conflict distribution ratio is used to describe the proportion of entries with authenticity conflict status in the entire target data set. The combined use of these two dimensions can reflect the composite structure of data compliance risk and authenticity risk.

[0175] The preset decision strategy library can be retrieved according to the compliance status identifier. This strategy library is a set of policy templates for different compliance statuses. Each template defines a set of basic processing action instructions and corresponding priority weights. The processing action instruction set can include operations such as automatic data entry, manual review, field masking, policy replacement, and process interruption. The priority parameter is used to determine the execution order and policy adaptation strength.

[0176] Furthermore, the system constructs a multi-dimensional fusion risk quantification index, namely the composite anomaly probability weight value, based on the anomaly type distribution ratio and the authenticity conflict distribution ratio. This weight value expresses the current data anomaly impact intensity through methods such as statistical normalization and weighted aggregation, and is used to dynamically adjust the priority settings of each action instruction in the basic decision template, so as to achieve customized adaptation to the current data characteristics.

[0177] On this basis, combined with the data operation permission level of the current user or system entity, multiple candidate decision-making schemes are generated. The data operation permission level restricts the types of actions allowed in the candidate schemes (for example, some users can only perform prompt feedback and do not have the permission to modify data). Each candidate scheme is a combination of differential processing actions, and a corresponding weight priority sequence is defined, that is, the execution order and priority consideration degree of different actions in the decision-making chain.

[0178] To ensure the executability of the scheme and the controllability of the effect, the system needs to perform an anomaly probability analysis on each candidate scheme to evaluate the possible changes in the data state after its execution. This analysis process calculates the expected compliance ratio (compliance improvement rate) and the introduced data processing loss (data integrity loss rate) after the execution of the scheme, and generates a scheme analysis identifier accordingly for subsequent screening and recording.

[0179] Finally, the system associates all candidate decision-making schemes with the corresponding analysis identifiers to construct a structured set of candidate decision-making schemes for subsequent file generation or manual confirmation module to call and use.

[0180] The extraction of the compliance status identifier can be directly read based on the structured fields in the first verification result, or generated by the system rule engine according to the anomaly ratio. The decision-making strategy library is usually maintained in the form of key-value mapping or rule engine. Different template sets are mapped under different compliance statuses, and the templates include default actions and their initial weights.

[0181] The composite anomaly probability weight value can be calculated in the following way: multiply the proportion of each type of anomaly by the risk factor defined in the strategy library, and then sum the results after weighting. For example, if the proportion of numerical anomalies is 20% and the weight is 0.5, and the proportion of authenticity conflicts is 10% and the weight is 0.8, then the composite anomaly probability weight value is 0.2×0.5 + 0.1×0.8 = 0.18.

[0182] The generation logic of candidate decision-making solutions can be implemented by means of rule template expansion and combined traversal. The system filters out inapplicable actions according to the permission level, and then dynamically adjusts the action sequence and execution logic based on the combination rules defined in the template. Immediately after each solution is generated, it enters the evaluation module, where abnormal probability analysis is performed based on the historical sample library or simulation engine, and two metrics are calculated: the compliance improvement rate and the data integrity loss rate. The system can set thresholds to automatically eliminate unqualified solutions.

[0183] The solution analysis identifier adopts a unique coding structure, which is composed of fields such as compliance status, weight value range, and solution serial number, and can be used for backtracking retrieval and version control.

[0184] Example illustration: In the medical and health scenario, a medical institution uploaded a batch of physical examination data, which included abnormal index parameter fields and identity verification failures. The first verification result determined that the compliance status was "high-risk non-compliance", and the authenticity conflict ratio in the second verification result reached 15%. The system matched a "require manual review + automatic completion" type template in the decision-making strategy library, calculated a high-weight correction value based on the abnormal proportion, and generated multiple candidate solutions including action combinations such as "field masking + review reminder + data freezing". Each solution is marked with the expected compliance improvement and information loss rate after execution for the administrator of the medical insurance platform to select and execute.

[0185] In the financial scenario, there are abnormal occupational categories and certificate verification failures in the insurance application data submitted by an enterprise for multiple employees. By analyzing the first and second verification results generated, the system extracts the characteristics of "partial compliance" and "low authenticity conflict rate", matches the "automatic prompt + partial approval" template from the decision-making library, and finally generates several differential processing solutions, such as "allow supplementary recording + limit the insurance scope", "submit to the superior for review + suspend underwriting", etc., and evaluates their impact on the overall business efficiency and data integrity to assist the insurance company in making responsive underwriting decisions.

[0186] In this embodiment, through the structured extraction and fusion calculation of multi-dimensional verification results, a logical mechanism for turning from static verification to dynamic strategy generation is constructed, significantly improving the personalization and refinement level of decision-making. By introducing a composite abnormal probability weight value to dynamically adjust the template priority, the candidate solutions can adapt to the data processing requirements under different abnormal modes; the abnormal probability analysis mechanism ensures that each solution implementation has a clear expected effect and risk judgment, avoiding the blindness and information asymmetry problems in decision-making execution.

[0187] In one embodiment, the above step S60 includes:

[0188] S601, Traverse each candidate decision-making scheme in the candidate decision-making scheme set, and extract the differential processing action combination, weight priority sequence, and corresponding scheme analysis identifier in the candidate decision-making scheme;

[0189] S602, Call the preset decision file template generator to generate a standardized file format template based on the differential processing action combination and data operation permission level;

[0190] S603, Write the scheme analysis identifier and the corresponding weight priority sequence into the analysis conclusion partition of the file format template to generate an intermediate decision file containing a formatted analysis conclusion;

[0191] S604, Perform digital signature and timestamp authentication on the intermediate decision file to generate a final decision file with a trusted authentication identifier, and record the metadata information of the final decision file;

[0192] S605, Monitor the generation progress of the final decision file. When the final decision file is generated, mark the generation status identifier of the final decision file as the generated status;

[0193] S606, Package the generation status identifier, trusted authentication identifier, and access path parameters of the final decision file into a file generation feedback message, and push the file generation feedback message to the client and trigger a page notification operation.

[0194] In this embodiment, the candidate decision-making scheme set is a structured data set generated in the previous stage, usually containing multiple candidate decision-making schemes. Each candidate scheme is accompanied by a differential processing action combination, a weight priority sequence, and a scheme analysis identifier. The differential processing action combination reflects the operation path combination taken by the scheme under specific data characteristics, such as field masking, audit redirection, permission downgrading, etc.; the weight priority sequence defines the execution order and execution intensity priority of each processing action; the scheme analysis identifier is used to mark the effect evaluation conclusion after the abnormal probability analysis of the scheme, and is an important meta-field for scheme identification and traceability.

[0195] Before generating a decision file containing an analysis conclusion, the system needs to traverse the entire candidate scheme set, perform an extraction operation on each scheme, and obtain its core decision-making features as the initial constituent units of the decision file content. Subsequently, a file structure template is generated through a decision file template generator. The decision file template generator can be a pre-compiled template engine, a rule-driven format converter, or a file description script generator with permission awareness capabilities. This template not only constructs decision-making action fields based on the differential processing action combination, but also uses the data operation permission level as a constraint factor to determine whether certain visible or executable fields are included in the template.

[0196] The generated file format template shall include logical execution sequence parameters for describing the execution flow control relationship of decision-making actions; it shall also include an area for user-editable comments, allowing manual comments, explanations, or confirmation opinions to be introduced in subsequent approval processes. This structure ensures that the decision-making document has both the ability to execute automatically and room for manual intervention.

[0197] Next, the system writes the scenario analysis identifier and weight priority sequence of the scenario into the analysis conclusion section in the template to form an intermediate decision-making document containing structured analysis output. The intermediate decision-making document itself does not have legal binding force, but its content structure is complete and available for the system and users to preview and verify.

[0198] To ensure the traceability and authenticity of the decision-making document, the system performs digital signature and timestamp authentication on this intermediate document. The digital signature is used to bind the file source and content integrity, and the timestamp authentication is used to mark its generation time and validity period. The generated final decision-making document will be accompanied by a trusted authentication identifier, which can be implemented based on various mechanisms such as the PKI system, notarized cloud platform, and trusted execution environment. The system will also record the metadata information of this file, including the generation timestamp, file version number, and data operation permission level, for subsequent access control, auditing, and version management.

[0199] The generation progress of the decision-making document is monitored and controlled by the file generation service. If the file generation process is completed, the signature is successful, and the authentication is completed, the system sets the status identifier to the generated status; in case of signature failure, interface exception, or data conflict, etc., the status is marked as failed, and the specific fault reason code is recorded.

[0200] Finally, this status identifier, trusted authentication identifier, and file access path will be encapsulated into a file generation feedback message and pushed to the client. After receiving the feedback, the client will trigger a page-level notification operation to prompt the user about the file generation result and allow viewing, downloading, or tracking subsequent processing.

[0201] The differential processing action combination can be encoded in JSON structure, and after being parsed by the system, it can correspond one by one to the fields in the decision file template. The weight priority sequence is written into the file control block through dynamic parameters, such as the priority parameter domain in XML or YAML format. The implementation of the template generator can be based on a configuration-driven method. For example, the field paragraphs in the template can be enabled or disabled according to the data operation permission level. For the situation where some users have low permissions, the advanced data operation fields can be omitted, and only the review instructions and feedback channel fields are retained. The generation process of the intermediate decision file can be carried out using a temporary path cached in the local service to ensure that it cannot be accessed externally before authentication. The digital signature can be implemented based on the institutional private key or a third-party signature platform, and the timestamp authentication can call the national timestamp service or the industry timestamp alliance interface. Once the final decision file is authenticated, its metadata is written into the file index table, including the file unique identifier, the owner user, the permission level, and the life cycle parameters. The file generation status identifier is maintained in the form of a state machine, including four states: initialization, in progress, success, and failure, and is linked with the file service system. The push feedback message adopts an asynchronous callback mechanism, and the result is fed back to the client interface through WebSocket or the push service component to ensure the response timeliness.

[0202] In this embodiment, by constructing a complete mechanism from the structured extraction of candidate decision schemes to the generation and status feedback of decision files, the originally discrete policy suggestions are transformed into decision files with format specifications and authentication attributes. By introducing permission constraints and user editing capabilities through the template generator, a flexible integration between machine decision-making and human supervision is achieved. The digital signature and trusted authentication mechanism ensure the legal source and content integrity of the decision file, and the generation status identifier and fault feedback mechanism improve the transparency and robustness of the entire process.

[0203] In one embodiment, a decision generation device based on multi-dimensional data verification is provided, and the decision generation device based on multi-dimensional data verification corresponds one by one to the decision generation method based on multi-dimensional data verification in the above embodiment. Refer to Figure 3 , Figure 3 FIG. is a schematic diagram of the functional modules of a preferred embodiment of the decision generation device based on multi-dimensional data verification of the present invention. An access authorization module 10, a data acquisition module 20, a compliance verification module 30, an authenticity verification module 40, a candidate decision module 50, and a decision file generation module 60. The detailed description of each functional module is as follows:

[0204] The access authorization module 10 is configured to receive an authentication request and complete the operation permission granting process according to the authentication request;

[0205] The data acquisition module 20 is configured to obtain a target data set after the operation permission granting process is completed;

[0206] A compliance verification module 30, configured to perform multi-dimensional verification on the target data set with a preset set of analysis strategies, and generate a first verification result including a compliance status;

[0207] An authenticity verification module 40, configured to perform multi-source consistency verification on the authenticity of target data entries in the target data set through an authenticity verification service interface, and generate a second verification result including an authenticity flag;

[0208] A candidate decision-making module 50, configured to generate a set of candidate decision-making schemes based on the data characteristics of the first verification result and the second verification result;

[0209] A decision document generation module 60, configured to generate a decision document including an analysis conclusion according to the set of candidate decision-making schemes, and feedback the generation status of the decision document.

[0210] In one embodiment, the access authorization module 10 is specifically configured to:

[0211] Receive an authentication request sent by a client, and parse the identity credential type and permission declaration scope in the authentication request;

[0212] Verify the validity of the identity credential, and generate a verification result including a validity identifier;

[0213] Query a preset permission mapping table according to the permission declaration scope, and associate the verified identity credential with the corresponding data operation permission level;

[0214] If the validity identifier is in a valid state, generate an authorization token including the data operation permission level and return it to the client;

[0215] If the validity identifier is in an invalid state, terminate the process and return a verification failure notice to the client;

[0216] Record the verification process, permission declaration scope, and permission granting result of the authentication request in the authorization log database.

[0217] In one embodiment, the data acquisition module 20 is specifically configured to:

[0218] Provide a structured template with predefined fields for the client to download;

[0219] Receive a data file uploaded by the client, parse the structured data entries in the data file, and extract the field content corresponding to the predefined fields in each data entry;

[0220] Traverse each data entry, verify the integrity of the corresponding field content, and mark the data entries with missing required fields or format violations;

[0221] Store the data entries that pass the verification into the target data set, and generate an error report for the data entries marked with missing required fields or format violations and return it to the client;

[0222] Establish a data entry index in the target data set that contains the mapping relationship between the data entry identifier and the data operation permission level.

[0223] In one embodiment, the compliance verification module 30 is specifically configured to:

[0224] Parse the key attribute fields of each data entry in the target data set, where the key attribute fields include numeric fields, category code fields, and index parameter fields;

[0225] Call the numeric range policy in the preset analysis policy set to determine whether the numeric field of the data entry is within the allowable threshold interval defined by the numeric range policy;

[0226] Call the risk level policy in the preset analysis policy set, query the risk level mapping table defined by the risk level policy according to the category code field of the data entry, and determine whether the risk level of the data entry is within the allowable risk level range;

[0227] Call the index compliance policy in the preset analysis policy set to detect whether the index parameter field of the data entry is within the normal value range defined by the index compliance policy;

[0228] If any of the numeric field, category code field, or index parameter field of the data entry does not meet the allowable conditions of the corresponding policy, mark the data entry as an abnormal state;

[0229] Count the total number of data entries in the abnormal state in the target data set and the distribution ratio of abnormal types;

[0230] Call the compliance determination policy in the preset analysis policy set to compare the distribution ratio of the abnormal types with the compliance threshold defined by the compliance determination policy;

[0231] If the distribution ratio of all abnormal types does not exceed the corresponding threshold, determine that the compliance status is overall compliant, otherwise determine that the compliance status is overall non-compliant;

[0232] Generate a first verification result that includes the compliance status and the distribution ratio of abnormal types.

[0233] In one embodiment, the authenticity verification module 40 is specifically configured to:

[0234] Extract the authenticity verification identifier of the target data entry;

[0235] Invoke at least two independent authenticity verification service interfaces and send a standardized request message of the authenticity verification identifier to each authenticity verification service interface;

[0236] Receive the verification response data returned by each authenticity verification service interface, where the verification response data includes the validity status of the authenticity verification identifier and the associated data version identifier;

[0237] Compare the verification response data of different authenticity verification service interfaces to detect whether the validity status of the authenticity verification identifier is consistent and whether the data version identifiers match;

[0238] If the validity statuses returned by all authenticity verification service interfaces are consistent and the data version identifiers match, mark the target data entry as the authenticity confirmed status; otherwise, mark the target data entry as the authenticity conflict status, and record the identifier of the conflicting authenticity verification service interface and the differences in the verification response data;

[0239] Statistically analyze the distribution ratio of the target data entries in the target dataset with the authenticity conflict status, and generate a second verification result including the authenticity mark and the authenticity conflict distribution ratio.

[0240] In one embodiment, the candidate decision-making module 50 is specifically configured to:

[0241] Extract the compliance status identifier and the abnormal type distribution ratio in the first verification result, and extract the authenticity mark identifier and the authenticity conflict distribution ratio in the second verification result;

[0242] Query the preset decision strategy library according to the compliance status identifier, and match the basic decision template corresponding to the compliance status identifier;

[0243] Determine the composite abnormal probability weight value of each abnormal type and authenticity conflict according to the abnormal type distribution ratio and the authenticity conflict distribution ratio, where the composite abnormal probability weight value is used to adjust the expected execution priority parameter of the basic decision template;

[0244] Generate multiple candidate decision-making schemes based on the basic decision template, the composite abnormal probability weight value, and the data operation permission level;

[0245] Perform abnormal probability analysis on each candidate decision-making scheme, determine the expected compliance improvement rate and the data integrity loss rate after the execution of each candidate decision-making scheme, and generate a scheme analysis identifier;

[0246] Associate and store the candidate decision-making scheme with the scheme analysis identifier to form a candidate decision-making scheme set.

[0247] In one embodiment, the decision file generation module 60 is specifically configured to:

[0248] Traverse each candidate decision-making scheme in the set of candidate decision-making schemes, and extract the differential processing action combination, weight priority sequence, and corresponding scheme analysis identifier in the candidate decision-making scheme;

[0249] Call a preset decision file template generator to generate a standardized file format template based on the differential processing action combination and data operation permission level;

[0250] Write the scheme analysis identifier and the corresponding weight priority sequence into the analysis conclusion partition of the file format template to generate an intermediate decision file containing a formatted analysis conclusion;

[0251] Perform digital signature and timestamp authentication on the intermediate decision file to generate a final decision file with a trusted authentication identifier, and record the metadata information of the final decision file;

[0252] Monitor the generation progress of the final decision file. When the final decision file is generated, mark the generation status identifier of the final decision file as the generated status;

[0253] Encapsulate the generation status identifier, trusted authentication identifier, and access path parameters of the final decision file into a file generation feedback message, and push the file generation feedback message to the client and trigger a page notification operation.

[0254] In one embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 4 shown. The computer device includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the server side of a decision generation method based on multi-dimensional data verification.

[0255] In one embodiment, a computer device is provided. The computer device can be a client, and its internal structure diagram can be as Figure 5As shown. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a decision-making generation method based on multi-dimensional data verification

[0256] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are implemented:

[0257] Receive an authentication request and complete the operation permission granting process according to the authentication request;

[0258] After completing the operation permission granting process, obtain the target data set;

[0259] Perform multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result including a compliance status;

[0260] Perform multi-source consistency verification on the authenticity of the target data entries in the target data set through an authenticity verification service interface to generate a second verification result including an authenticity mark;

[0261] Generate a set of candidate decision-making solutions based on the data characteristics of the first verification result and the second verification result;

[0262] Generate a decision-making document including an analysis conclusion based on the set of candidate decision-making solutions and feedback the generation status of the decision-making document.

[0263] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the following steps are implemented:

[0264] Receive an authentication request and complete the operation permission granting process according to the authentication request;

[0265] After completing the operation permission granting process, obtain the target data set;

[0266] Perform multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result including a compliance status;

[0267] Perform multi-source consistency verification on the authenticity of the target data entries in the target dataset through the authenticity verification service interface, and generate a second verification result including authenticity marks;

[0268] Generate a set of candidate decision-making schemes based on the data characteristics of the first verification result and the second verification result;

[0269] Generate a decision-making document including an analysis conclusion according to the set of candidate decision-making schemes, and feedback the generation status of the decision-making document.

[0270] It should be noted that for the functions or steps that can be realized by the above computer-readable storage medium or computer device, reference can be made to the relevant descriptions on the server side and the user side in the foregoing method embodiments. To avoid repetition, they will not be described in detail here.

[0271] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above method embodiments. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided in the present application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0272] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0273] It should be noted that in the embodiments of this application, if there are software tools or components that are not of our company, they are only used for illustrative introduction and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A decision-making generation method based on multi-dimensional data verification, characterized in that It includes the following steps: Receive an authentication request and complete the operation permission granting process according to the authentication request; After completing the operation permission granting process, obtain the target data set; Perform multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result including a compliance status; Perform multi-source consistency verification on the authenticity of target data entries in the target data set through an authenticity verification service interface to generate a second verification result including an authenticity mark; Generate a candidate decision plan set based on the data characteristics of the first verification result and the second verification result; Generate a decision file including an analysis conclusion according to the candidate decision plan set and feedback the generation status of the decision file.

2. The decision-making generation method based on multi-dimensional data verification according to claim 1, wherein Receive an authentication request and complete the operation permission granting process according to the authentication request, including: Receive the authentication request sent by the client, and parse the identity credential type and permission declaration scope in the authentication request; Verify the validity of the identity credential to generate a verification result including a validity identifier; Query a preset permission mapping table according to the permission declaration scope, and associate the verified identity credential with the corresponding data operation permission level; If the validity identifier is in a valid state, generate an authorization token including the data operation permission level and return it to the client; If the validity identifier is in an invalid state, terminate the process and return a verification failure notice to the client; Record the verification process, permission declaration scope, and permission granting result of the authentication request in the authorization log database.

3. The decision-making generation method based on multi-dimensional data verification according to claim 1, wherein After completing the operation permission granting process, obtain the target data set, including: Provide a structured template with predefined fields for the client to download; Receive the data file uploaded by the client, parse the structured data entries in the data file, and extract the field content corresponding to the predefined fields in each data entry; Traverse each data entry, verify the integrity of the corresponding field content, and mark the data entries with missing required fields or format violations; Store the verified data entries in the target data set, and generate an error report for the data entries marked with missing required fields or format violations and return it to the client; Establish a data entry index in the target data set that maps data entry identifiers to data operation permission levels.

4. The decision-making generation method based on multi-dimensional data verification according to claim 1, wherein Perform multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result including a compliance status, including: Parse the key attribute fields of each data entry in the target data set, where the key attribute fields include numeric fields, category code fields, and index parameter fields; Call the numeric range strategy in the preset set of analysis strategies to determine whether the numeric field of the data entry is within the allowable threshold range defined by the numeric range strategy; Call the risk level strategy in the preset set of analysis strategies, query the risk level mapping table defined by the risk level strategy according to the category code field of the data entry, and determine whether the risk level of the data entry is within the allowable risk level range; Invoke the metric compliance policy in the preset set of analysis policies to detect whether the metric parameter field of the data entry is within the normal value range defined by the metric compliance policy; If any of the numeric field, category code field, or metric parameter field of the data entry does not meet the allowed conditions of the corresponding policy, mark the data entry as in an abnormal state; Count the total number of data entries in the abnormal state in the target dataset and the distribution ratio of abnormal types; Invoke the compliance determination policy in the preset set of analysis policies to compare the distribution ratio of the abnormal types with the compliance threshold defined by the compliance determination policy; If the distribution ratios of all abnormal types do not exceed the corresponding thresholds, determine the compliance status as overall compliance, otherwise determine the compliance status as overall non-compliance; Generate a first verification result including the compliance status and the distribution ratio of abnormal types; 5. The decision-making generation method based on multi-dimensional data verification according to claim 1, characterized in that Perform multi-source consistency verification on the authenticity of the target data entries in the target dataset through the authenticity verification service interface, and generate a second verification result including authenticity marks, including: Extract the authenticity verification identifier of the target data entry; Invoke at least two independent authenticity verification service interfaces, and send a standardized request message of the authenticity verification identifier to each authenticity verification service interface; Receive the verification response data returned by each authenticity verification service interface, where the verification response data includes the validity status of the authenticity verification identifier and the associated data version identifier; Compare the verification response data of different authenticity verification service interfaces to detect whether the validity status of the authenticity verification identifier is consistent and whether the data version identifiers match; If the validity statuses returned by all authenticity verification service interfaces are consistent and the data version identifiers match, mark the target data entry as in an authenticity confirmed state, otherwise mark the target data entry as in an authenticity conflict state, and record the identifier of the authenticity verification service interface with the conflict and the differences in the verification response data; Count the distribution ratio of the target data entries in the authenticity conflict state in the target dataset, and generate a second verification result including authenticity marks and the distribution ratio of authenticity conflicts; 6. The decision-making generation method based on multi-dimensional data verification according to claim 1, characterized in that Generate a set of candidate decision plans based on the data characteristics of the first verification result and the second verification result, including: Extract the compliance status identifier and the distribution ratio of abnormal types from the first verification result, and extract the authenticity mark identifier and the distribution ratio of authenticity conflicts from the second verification result; Query the preset decision policy library according to the compliance status identifier, and match the basic decision template corresponding to the compliance status identifier; Determine the composite abnormal probability weight value of each abnormal type and authenticity conflict according to the distribution ratio of abnormal types and the distribution ratio of authenticity conflicts, and the composite abnormal probability weight value is used to adjust the expected execution priority parameter of the basic decision template; Generate multiple candidate decision plans based on the basic decision template, the composite abnormal probability weight value, and the data operation permission level; Perform abnormal probability analysis on each candidate decision plan to determine the expected compliance improvement rate and the data integrity loss rate after the execution of each candidate decision plan, and generate a plan analysis identifier; Associate and store the candidate decision-making solutions with the solution analysis identifiers to form a set of candidate decision-making solutions.

7. The decision-making generation method based on multi-dimensional data verification according to claim 1, wherein Generate a decision-making document containing analysis conclusions based on the set of candidate decision-making solutions, and feedback the generation status of the decision-making document, including: Traverse each candidate decision-making solution in the set of candidate decision-making solutions, and extract the differential processing action combinations, weight priority sequences, and corresponding solution analysis identifiers in the candidate decision-making solutions; Call a preset decision-making document template generator to generate a standardized file format template based on the differential processing action combinations and data operation permission levels; Write the solution analysis identifiers and the corresponding weight priority sequences into the analysis conclusion partition of the file format template to generate an intermediate decision-making document containing formatted analysis conclusions; Perform digital signature and timestamp authentication on the intermediate decision-making document to generate a final decision-making document with a trusted authentication identifier, and record the metadata information of the final decision-making document; Monitor the generation progress of the final decision-making document. When the final decision-making document is generated, mark the generation status identifier of the final decision-making document as the generated status; Package the generation status identifier, trusted authentication identifier, and access path parameters of the final decision-making document into a file generation feedback message, and push the file generation feedback message to the client and trigger a page notification operation.

8. A decision-making generation device based on multi-dimensional data verification, characterized in that, The decision-making generation device based on multi-dimensional data verification includes: An access authorization module for receiving an authentication request and completing the operation permission granting process according to the authentication request; A data acquisition module for acquiring a target data set after completing the operation permission granting process; A compliance verification module for performing multi-dimensional verification on the target data set and a preset set of analysis strategies to generate a first verification result containing a compliance status; An authenticity verification module for performing multi-source consistency verification on the authenticity of target data entries in the target data set through an authenticity verification service interface to generate a second verification result containing an authenticity mark; A candidate decision-making module for generating a set of candidate decision-making solutions based on the data characteristics of the first verification result and the second verification result; A decision-making document generation module for generating a decision-making document containing analysis conclusions based on the set of candidate decision-making solutions and feedbacking the generation status of the decision-making document.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a decision-making generation program based on multi-dimensional data verification stored on the memory and executable on the processor. When the decision-making generation program based on multi-dimensional data verification is executed by the processor, it implements the steps of the decision-making generation method based on multi-dimensional data verification as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A decision-making generation program based on multi-dimensional data verification is stored on the storage medium. When the decision-making generation program based on multi-dimensional data verification is executed by the processor, it implements the steps of the decision-making generation method based on multi-dimensional data verification as described in any one of claims 1-7.

Images