A notarization execution dynamic processing method and system supporting document visual programming

Abstract

The embodiment of the present application relates to the technical field of notarization, and discloses a notarization execution dynamic processing method supporting visual programming of documents, comprising: receiving dynamic field metadata input by a visual interface; storing the dynamic field metadata in a metadata storage library, and dynamically generating a data collection form at runtime according to the dynamic field metadata; assembling the collected structured data into a unified data container; providing a visual template editing interface based on natural language documents; and generating a final document in response to a document generation request. The dynamic processing method in the embodiment of the present application can dynamically configure field metadata and generate a collection form, without modifying the library or the code, and is suitable for multiple notarization businesses; the unified data container realizes standardized management of data; and through the visual document template and control statements, the editing threshold is reduced, and finally a standardized and accurate notarization document is automatically generated by a template engine.

Description

Technical Field

[0001] This invention relates to the field of notary technology, specifically to a dynamic processing method and system for notary execution that supports visual programming of documents. Background Technology

[0002] Currently, traditional notary enforcement systems suffer from three major pain points, making it difficult to adapt to the actual needs of the notary industry, which require "differentiated needs from multiple notary offices, personalized configurations for various business scenarios, and efficient and flexible document generation": 1. Fixed fields and rigid data collection: Traditional systems rely on preset database fields to design execution forms, and can only collect fixed data during the notarization stage (such as basic creditor information and debt amount). When the creditor initiates execution and needs to supplement personalized business information (such as "overdue penalty calculation method" and "collateral type" for different loan notarizations), the database structure and front-end form code need to be modified, resulting in extremely high adaptation costs. Furthermore, non-common fields for different notarization businesses (such as financial loan notarization and power of attorney notarization) cannot be flexibly expanded, causing the system to only cover a single business scenario.

[0003] 2. Hard-coded document generation suffers from poor adaptability. The notarization and enforcement process requires the generation of various documents (enforcement certificate application, debt performance verification letter, notary inquiry record, enforcement certificate). Traditional solutions require programmers to break down document templates into fixed identifiers and generate dynamic content by matching each identifier with code. If the notary office has specific requirements for document format (such as "statement of enforcement basis clauses" or "position of notary's signature") or if clients have specific requirements for business fields (such as "adding 'loan purpose' description"), extensive modifications to the code logic are necessary, easily leading to system bugs and hindering the rapid response to the diverse needs of multiple notary offices and clients.

[0004] 3. The document editing lacks visualization capabilities and has a high technical threshold; the document logic of traditional systems (such as "displaying the details of the penalty calculation if the debt is overdue for more than 30 days" and "looping through multiple debt records") requires coding, and non-technical personnel (such as notaries and business specialists) cannot participate in document configuration; moreover, the documents are disconnected from the data collection fields, and modifying documents requires simultaneous adjustment of form field codes, resulting in a long template iteration cycle (an average of 3-5 days / time), which cannot meet the "quick adaptation and flexible adjustment" requirements of notary execution business. Summary of the Invention

[0005] To address the aforementioned shortcomings, this invention discloses a dynamic processing method for notarization execution that supports visual programming of documents, thereby improving the efficiency of notarized document generation and processing.

[0006] The first aspect of this invention discloses a dynamic processing method for notarization execution that supports document visualization programming, comprising: Receive dynamic field metadata input from the visual interface. The dynamic field metadata includes field identifier, field type, data source identifier, and display attributes. The field type includes basic type, object type, and array type. The dynamic field metadata is stored in a metadata repository, and a data collection form is dynamically generated at runtime based on the dynamic field metadata. The data collection form is used to collect structured data in notarized enforcement cases. The collected structured data is assembled into a unified data container, which stores fixed field data, dynamically extended field data, and system field data in key-value pairs. A visual template editing interface based on natural language documents is provided. The visual template editing interface includes document templates, and control statements and filters are predefined in the document templates. The control statements include loop statements and conditional judgment statements, and the filters are used to perform format conversion on the data in the unified data container. In response to a document generation request, the document template is parsed through a template engine, the control statements and filters are mapped to intermediate representations, and the intermediate representations are executed based on the data in the unified data container to generate the final document.

[0007] As an optional implementation, in the first aspect of the present invention, receiving dynamic field metadata input from a visual interface includes: In response to user actions of adding or editing fields in the visual interface, generate or modify dynamic field metadata; The dynamic field metadata is serialized into JSON format and stored in the metadata repository; without modifying the physical table structure of the database or restarting the service, the dynamic field metadata immediately takes effect in the subsequent data collection form generation process; The template engine parses the document template, including: The document template is parsed into an abstract syntax tree, wherein the node types of the abstract syntax tree include text nodes, loop nodes, conditional judgment nodes, and filter nodes; The parsed abstract syntax tree is cached in memory or a distributed cache; If subsequent requests to parse the same document template directly load the cached abstract syntax tree, the re-parsing step is skipped; When executing the abstract syntax tree, the expressions in the conditional nodes and loop nodes are executed in a restricted sandbox environment, and access to the file system, network interface or execution of arbitrary system commands is prohibited.

[0008] As an optional implementation, in the first aspect of the present invention, the dynamic processing method further includes: A pre-trained AI model configured with field prompt information, wherein the field prompt information includes multiple standard field configuration requirement features obtained after training the initial AI model using standard field configuration requirement information of multiple standard notary business types; Determine the case description information and case type identifier of the current notarization case; The case description information and the case type identifier are input into the pre-trained AI model, so that the pre-trained AI model selects standard field configuration requirement features that match the case description information from a variety of standard field configuration requirement features, and generates and outputs recommended dynamic field configurations based on the case type identifier and the selected standard field configuration requirement features. The recommended dynamic field configuration is displayed in a visual interface, allowing users to confirm or modify it before application.

[0009] As an optional implementation, in the first aspect of the present invention, the training process of the pre-trained AI model includes: Obtain standard field configuration requirements information for various standard notary business types, as well as sample case type identifiers and sample field configurations for sample notary cases. The various standard field configuration requirements information corresponds one-to-one with the various standard field configuration requirements features. Text feature extraction is performed on each type of standard field configuration requirement information to obtain the standard field configuration requirement features corresponding to each type of standard field configuration requirement information; The sample case type identifier and each standard field configuration requirement feature are input into the large language model to generate the standard field configuration corresponding to each standard field configuration requirement feature; Based on the configuration requirements of the various standard fields and their corresponding standard field configurations, as well as the sample case type identifier, the initial AI model is trained to obtain the pre-trained AI model; The process of training the initial AI model to obtain the pre-trained AI model based on the configuration requirements features of the multiple standard fields and their corresponding standard field configurations, as well as the sample case type identifier, includes: Each standard field configuration requirement feature and the corresponding sample case type identifier are input into the initial AI model to generate the initial field configuration corresponding to each standard field configuration requirement feature; For each standard field configuration requirement, determine the configuration differences between the corresponding initial field configuration and the corresponding standard field configuration; Based on the configuration differences corresponding to the configuration requirements of the various standard fields, the initial AI model is trained to obtain the pre-trained AI model.

[0010] As an optional implementation, in a first aspect of the present invention, selecting standard field configuration requirement features that match the case description information from a variety of standard field configuration requirement features includes: Determine the similarity between each standard field configuration requirement feature and the case description information; and based on the similarity, select at least one standard field configuration requirement feature with the highest similarity from the multiple standard field configuration requirement features.

[0011] When the similarity of the required features of the standard field configuration with the highest similarity is lower than a preset threshold, the manual configuration mode is triggered, and the manually configured field configuration is used as a new training sample to update the pre-trained AI model. The case description information for determining the current notarization case includes: Obtain the original description of the notarization request input by the user, wherein the original description of the notarization request carries request data; Based on the established rules and the aforementioned requirement data, data cleaning is performed to obtain standardized requirement data. The aforementioned standard requirements data are converted into the aforementioned case description information.

[0012] As an optional implementation, in the first aspect of the present invention, the dynamic processing method further includes: The historical notary case dataset is stored in the big data platform. The historical notary case dataset contains multiple historical case records. Each historical case record includes historical dynamic field configuration, historical document template identifier, historical unified data container content, and historical execution result evaluation. The historical notarization case dataset is divided into multiple data subsets, each of which is associated with one of multiple expert networks. The expert network is used to output recommended field configurations or document templates based on the input case characteristics. Receive initial information about the current notarization case, including the case type, creditor attributes, and type of debt object; From the historical notarized case dataset, obtain target historical case data that matches the initial information of the current notarized case; Based on the target historical case data, at least one candidate data subset is selected from the plurality of data subsets, wherein there are overlapping data records between the candidate data subset and the target historical case data; Invoke the expert network associated with each of at least one subset of candidate data, and generate recommended field configurations and / or recommended document templates for the current notarization case based on the target historical case data; The recommended field configurations and / or recommended document templates are displayed in a visual interface, allowing users to confirm or modify them before application.

[0013] As an optional implementation, in a first aspect of the present invention, obtaining target historical case data that matches the initial information of the current notarization case includes: Feature extraction is performed on the initial information of the current notarized case to obtain the current case feature vector; Feature extraction is performed on each historical case record in the historical notarized case dataset to obtain the corresponding historical case feature vector; Calculate the similarity between the current case feature vector and the feature vector of each historical case; Select the historical case records with the highest similarity as the target historical case data; The process of dividing the historical notarized case dataset into multiple data subsets includes: Clustering is performed on all historical case records in the aforementioned historical notarized case dataset to obtain multiple cluster centers; Each historical case record is assigned to the data subset corresponding to the cluster center that is most similar to its characteristics; The number of the multiple data subsets is equal to the number of the multiple cluster centers, and each data subset is associated with an expert network.

[0014] As an optional implementation, in a first aspect of the present invention, the step of invoking the expert network associated with at least one subset of candidate data to generate recommended field configurations and / or recommended document templates for the current notarization case based on the target historical case data includes: For each candidate data subset, the overlapping data records between the target historical case data and the candidate data subset are input into the expert network associated with the candidate data subset for calculation, and the recommendation result output by the expert network is obtained. Determine the proportion of the number of data records overlapping between the target historical case data and each candidate data subset to the total number of records in the target historical case data; The recommendation results output by the expert networks associated with at least one subset of candidate data are weighted and merged according to a certain ratio to generate the final recommendation field configuration and / or recommendation document template.

[0015] The method further includes: when the number of overlapping data records between the target historical case data and any candidate data subset is less than a preset threshold, excluding the candidate data subset from the weighted merging.

[0016] A second aspect of this invention discloses a notary execution dynamic processing system that supports document visualization programming, comprising: Receiving module: Used to receive dynamic field metadata input from the visual interface. The dynamic field metadata includes field identifier, field type, data source identifier, and display attributes. The field type includes basic type, object type, and array type. Storage module: used to store the dynamic field metadata in a metadata repository, and dynamically generate a data collection form at runtime based on the dynamic field metadata, wherein the data collection form is used to collect structured data in notarized enforcement cases; Assembly module: Used to assemble the collected structured data into a unified data container, which stores fixed field data, dynamically extended field data and system field data in key-value pair format; Visualization module: This module provides a visual template editing interface for natural language documents. The visual template editing interface includes document templates, and control statements and filters are predefined in the document templates. The control statements include loop statements and conditional statements, and the filters are used to perform format conversion on the data in the unified data container. Generation module: In response to a document generation request, it parses the document template through a template engine, maps the control statements and filters into intermediate representations, and executes the intermediate representations based on the data in the unified data container to generate the final document.

[0017] A third aspect of the present invention discloses an electronic device, comprising: a memory storing executable program code; a processor coupled to the memory; the processor calling the executable program code stored in the memory to execute the notarization execution dynamic processing method supporting document visualization programming disclosed in the first aspect of the present invention.

[0018] A fourth aspect of the present invention discloses a computer-readable storage medium storing a computer program, wherein the computer program causes a computer to execute the notarization execution dynamic processing method supporting document visualization programming disclosed in the first aspect of the present invention.

[0019] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: The dynamic processing method in this embodiment of the invention can dynamically configure field metadata and generate collection forms without modifying the database or code, and is suitable for various notary services; a unified data container enables standardized data management; and through visual document templates and control statements, the editing threshold is reduced, and finally, the template engine automatically generates standardized and accurate notary documents. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the notarization execution dynamic processing method supporting document visualization programming disclosed in an embodiment of the present invention; Figure 2 This is a schematic diagram of the visual input process disclosed in the embodiments of the present invention; Figure 3 This is a schematic diagram of the template parsing process disclosed in an embodiment of the present invention; Figure 4 This is a schematic diagram of the dynamic field recommendation process disclosed in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a notary execution dynamic processing system that supports document visualization programming, provided by an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] It should be noted that the terms "first," "second," "third," "fourth," etc., in the specification and claims of this invention are used to distinguish different objects, not to describe a specific order. The terms "comprising" and "having," and any variations thereof, in the embodiments of this invention are intended to cover non-exclusive inclusion. Exemplarily, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0024] Example 1 Please see Figure 1 , Figure 1 This is a flowchart illustrating the dynamic processing method for notarization execution that supports document visualization programming, as disclosed in an embodiment of the present invention. The execution entity of the method described in this embodiment is an execution entity composed of software and / or hardware. This execution entity can receive relevant information via wired or / or wireless means and can send certain instructions. It may also have certain processing and storage functions. This execution entity can control multiple devices, such as remote physical servers or cloud servers and related software, or local hosts or servers and related software that perform related operations on devices located in a certain location. In some scenarios, it can also control multiple storage devices, which may be placed in the same location as the device or in different locations. Figure 1 As shown, the notarization execution dynamic processing method based on document visualization programming includes the following steps: S101: Receive dynamic field metadata input from the visual interface. The dynamic field metadata includes field identifier, field type, data source identifier, and display attributes. The field type includes basic type, object type, and array type. The object type supports nested subfields. S102: Store the dynamic field metadata in a metadata repository, and dynamically generate a data collection form at runtime based on the dynamic field metadata, wherein the data collection form is used to collect structured data in notarized enforcement cases; S103: Assemble the collected structured data into a unified data container, wherein the unified data container stores fixed field data, dynamically extended field data, and system field data in key-value pairs; S104: Provide a visual template editing interface based on natural language documents. The visual template editing interface includes document templates, and control statements and filters are predefined in the document templates. The control statements include loop statements and conditional judgment statements, and the filters are used to perform format conversion on the data in the unified data container. S105: In response to the document generation request, the document template is parsed through the template engine, the control statements and filters are mapped to intermediate representations, and the intermediate representations are executed according to the data in the unified data container to generate the final document.

[0025] The solution in this invention allows for the configuration of dynamic field metadata through a visual interface, enabling the system to automatically generate corresponding data collection forms at runtime without requiring recoding for each new case or field. This achieves zero-code or low-code extension, allowing business personnel to adjust the field structure themselves when notary business rules or document formats change, significantly reducing reliance on developers and system maintenance costs.

[0026] Specifically, the collected fixed fields, dynamically extended fields, and system fields are uniformly assembled into a unified data container (key-value pair format), solving the problems of scattered and inconsistent data formats in traditional notarization systems. The unified container provides a single data source for subsequent document generation, data verification, and statistical analysis, avoiding inconsistencies or data loss during multiple stages of data flow.

[0027] By introducing control statements and filters into the template, the problem of static document templates being unable to handle complex business logic (such as calculating inheritance shares for multiple individuals, displaying lists of multiple properties, and automatically adjusting titles based on gender / age) is solved. This allows the system to automatically complete paragraph formatting, list rendering, and format conversion based on the collected structured data, without requiring manual intervention for layout adjustments.

[0028] The system employs a template engine to parse intermediate representations, transforming visually editable natural language templates into executable logic. Upon request, the system quickly and in batches populates data from a unified data container into the correct locations, avoiding errors in names, certificate numbers, and amounts caused by manual copying and pasting, while significantly shortening the cycle from acceptance to certificate issuance. Because the entire process is dynamic and based on strict field metadata definitions, the system can completely record: who collected what data, when, and according to what logic that data generated which part of the final document. This provides a clear data lineage for notarized archives, facilitating post-event supervision and verification, ensuring that the document content strictly corresponds to the original collected data, and meeting the requirements of rigorous notarization procedures.

[0029] The solution of this embodiment of the invention also includes a template lifecycle management step: Document templates are stored according to a hierarchical inheritance model, which includes at least a platform layer, a notary office layer, a case type layer, and a case layer. Lower-level templates only store the differences between themselves and their direct upper-level templates. At runtime, a merging algorithm is used to merge the configurations of each layer into a complete template. In response to template modification requests, the template version number is automatically incremented, and the version change history is recorded. The template applicability scope can be configured according to any combination of notary office identifier, case type identifier, or case identifier.

[0030] Specifically, the visual template editing interface includes: a syntax toolbar for providing clickable template fragments of the control statements and filters; a real-time preview window for loading anonymized or simulated data of the current case and dynamically rendering the preview document effect while editing the document template; and an error annotation mechanism for highlighting the error location and providing an error description in the editing interface when a syntax error in the control statement or a referenced field is detected that does not exist in the unified data container.

[0031] More preferably, such as Figure 2 As shown, the dynamic field metadata received from the visual interface includes: S1011: Responding to user actions of adding or editing fields in the visual interface, generate or modify dynamic field metadata; S1012: Serialize the dynamic field metadata into JSON format and store it in the metadata repository; without modifying the physical table structure of the database and without restarting the service, make the dynamic field metadata immediately effective for the subsequent data collection form generation process; In practical implementation, real-time hot loading of business form structures was achieved by serializing metadata into JSON storage and declaring that the physical database table structure would not be modified or the service restarted. During peak notary business periods (such as the concentrated processing period for inheritance notarization), when the business administrator adds a new field (e.g., adding contact information for will witnesses) to the front-end visual interface, the back-end service does not need to be compiled, packaged, or deployed with downtime; the form collection interface takes effect immediately. This ensures the high availability and continuity of notary services and eliminates the business interruption window caused by system updates.

[0032] By using JSON serialization to store metadata instead of directly modifying the physical table structure, the risk of table locking and database maintenance burden caused by modifying the table structure are avoided. Furthermore, historical metadata version snapshots are naturally created. Even if future business logic changes lead to the deletion or modification of fields, the system can still accurately reconstruct the form style and data meaning at that point in time by reading the JSON metadata, meeting the requirements for long-term preservation of notarized documents and consistency of evidence during judicial verification.

[0033] like Figure 3 As shown, the template engine parses the document template, including: S1051: Parse the document template into an abstract syntax tree, wherein the node types of the abstract syntax tree include text nodes, loop nodes, conditional judgment nodes, and filter nodes; S1052: Cache the parsed abstract syntax tree in memory or a distributed cache; S1053: If subsequent requests to parse the same document template directly load the cached abstract syntax tree, the re-parsing step is skipped; S1054: When executing the abstract syntax tree, the expressions in the conditional judgment nodes and loop nodes are executed in a restricted sandbox environment, and access to the file system, network interface or execution of arbitrary system commands is prohibited.

[0034] In practical implementation, by parsing the document template into an abstract syntax tree and implementing in-memory / distributed caching, the overhead of repeatedly performing lexical and syntactic analysis each time a document is generated is avoided. In scenarios where notary offices need to generate hundreds of notarized documents in batches (such as batch notarization with enforcement function), this mechanism ensures that the generation of each subsequent document only requires executing the cached syntax tree, greatly reducing CPU computing resource consumption, shortening the generation response time from seconds to milliseconds, and improving the overall certificate issuance efficiency.

[0035] By restricting expression execution within a confined sandbox environment and explicitly prohibiting access to the file system, network interfaces, and system commands, document template editing is completely isolated from the underlying operating system environment. This effectively prevents the following security risks: if a notary's account is hijacked, attackers cannot compromise server data or steal sensitive information by embedding malicious expressions in the template. This is a crucial layer of security for notary systems that handle citizens' private information. In distributed deployment scenarios (such as multiple notary offices sharing a single backend service), a distributed cache for storing the abstract syntax tree is introduced, ensuring that all service nodes can immediately obtain unified execution logic after template updates. This avoids business incidents caused by asynchronous template files between nodes, resulting in different document styles generated by different offices.

[0036] More preferably, such as Figure 4 As shown, the dynamic processing method further includes: S100a: A pre-trained AI model configured with field prompt information, wherein the field prompt information includes multiple standard field configuration requirement features obtained after training the initial AI model using standard field configuration requirement information of multiple standard notary business types; S100a: Determine the case description information and case type identifier of the current notarization case; S100a: Input the case description information and the case type identifier into the pre-trained AI model, so that the pre-trained AI model selects standard field configuration requirement features that match the case description information from a variety of standard field configuration requirement features, so as to generate and output recommended dynamic field configuration based on the case type identifier and the selected standard field configuration requirement features; S100a: Display the recommended dynamic field configuration in a visual interface and allow users to confirm or modify it before application.

[0037] The pre-trained model in this invention internalizes the field configuration features of various standard notarization services (such as different field combination rules for inheritance, agency, will, and enforcement notarization). When frontline reception staff (who may not be senior notaries) input a simple case description (e.g., parents passing away and leaving a house to their only child), the system can automatically infer and recommend the complete set of fields required for inheritance notarization (death certificate of the deceased, kinship table, property certificate information, etc.). This allows new or support staff to quickly get started with complex business processing, significantly reducing reliance on professional legal knowledge and training costs.

[0038] By combining case type identifiers and descriptive information feature matching, the system-generated recommended configurations are no longer general templates, but rather precise sets of fields tailored to specific case circumstances. For example, for intestate succession and testamentary succession, the model intelligently decides whether to recommend fields related to will verification status and other legal heirs' waivers. This avoids users being distracted by a large number of irrelevant fields, reduces the amount of invalid information entered and subsequent modifications, and improves the accuracy and efficiency of data collection.

[0039] The standard field configuration requirements obtained through training essentially transform the tacit knowledge of senior notaries into computable and reusable AI model parameters. Even if senior notaries retire or leave, new employees can still obtain a field verification checklist equivalent to that of senior experts through AI recommendations, ensuring the stable inheritance of the notary office's core business capabilities.

[0040] In its implementation, the process specifically emphasizes allowing users to confirm or modify the application. This ensures that the AI ​​plays a supporting role in decision-making, while the final decision-making power remains with the notary. This technological effect is reflected in two aspects: preventing the AI ​​from overlooking key legal fields due to misjudgments in a very few marginal cases (such as the applicable law in cross-border inheritance). The AI's recommendations serve as initial suggestions, and the notary's review and confirmation process constitutes a second manual review of the case requirements, meeting the legal requirements for the rigor of notarization procedures.

[0041] By leveraging natural language processing capabilities to analyze case descriptions, the system addresses non-standard scenarios that traditional dropdown menus cannot cover. For example, if a client describes needing a certificate of unmarried status and a birth certificate for marriage abroad, a traditional system would require accessing two separate modules. The AI ​​model, however, can identify multiple implicit notarization needs from the description and provide a comprehensive list of combined field configurations for both unmarried status and birth certificates, thus improving the overall experience across different business types.

[0042] User modifications to the recommendation configuration (e.g., the model recommends field A, and the user manually deletes field A and adds field B) constitute high-quality feedback data. This data can be used for subsequent model fine-tuning and incremental learning, allowing the recommendation accuracy to continuously improve with increased usage. The system becomes smarter and more aligned with the notary office's localized business practices over time.

[0043] More preferably, the training process of the pre-trained AI model includes: Obtain standard field configuration requirements information for various standard notary business types, as well as sample case type identifiers and sample field configurations for sample notary cases. The various standard field configuration requirements information corresponds one-to-one with the various standard field configuration requirements features. Text feature extraction is performed on each type of standard field configuration requirement information to obtain the standard field configuration requirement features corresponding to each type of standard field configuration requirement information; The sample case type identifier and each standard field configuration requirement feature are input into the large language model to generate the standard field configuration corresponding to each standard field configuration requirement feature; Based on the configuration requirements of the various standard fields and their corresponding standard field configurations, as well as the sample case type identifier, the initial AI model is trained to obtain the pre-trained AI model; The process of training the initial AI model to obtain the pre-trained AI model based on the configuration requirements features of the multiple standard fields and their corresponding standard field configurations, as well as the sample case type identifier, includes: Each standard field configuration requirement feature and the corresponding sample case type identifier are input into the initial AI model to generate the initial field configuration corresponding to each standard field configuration requirement feature; For each standard field configuration requirement, determine the configuration differences between the corresponding initial field configuration and the corresponding standard field configuration; Based on the configuration differences corresponding to the configuration requirements of the various standard fields, the initial AI model is trained to obtain the pre-trained AI model.

[0044] This invention transforms standard field configuration requirement information (such as a list of materials required for inheritance notarization) into standard field configuration requirement features (vectorized representation). The system converts unstructured legal provisions and experiential texts into computable semantic vectors. This enables AI to make recommendations based on the similarity of legal concepts rather than literal similarity.

[0045] During training, the input includes not only case type identifiers (such as power of attorney) but also feature vectors. This makes the initial AI model learn a mapping relationship of: [case type identifier + semantic features] to [field configuration]. When processing notarization of power of attorney for the sale of real estate in another location, the model identifies the spatial features of the description and automatically recommends special field configurations that include the trustee's right to sub-delegate and authorization for verification in another location, which may not be included in the general template. Backward training is performed using configuration differences (Loss), rather than forcibly memorizing one-to-one correspondences. This means that the model learns the probability distribution and combination rules of field configurations. When encountering unprecedented combinations of case descriptions (such as guardianship consent and property guarantee certificates for minor children traveling abroad), the model does not fail because it cannot find a perfectly matching hard-coded rule. Instead, it can dynamically combine the features of guardianship notarization and property certificate features based on feature similarity, demonstrating strong generalization ability and robustness.

[0046] Specifically, the training architecture separates case type identifiers from requirement features as input. The technical advantage of this decoupling mechanism is that the model quickly learns to distinguish the basic framework of major categories such as inheritance, delegation, and marriage in the early stages of training. Within the established framework of these major categories, the model focuses on adjusting the changes in detailed fields caused by feature differences (such as distinguishing the presence or absence of a will in the inheritance category). This improves convergence speed and results in stronger consistency in the generated configuration logic compared to directly mixing all text inputs for training.

[0047] Because the features are extracted from clearly defined standard notarization service types of text, notaries can trace the source of the features when reviewing AI recommendations. For example, if the AI ​​recommends the equity valuation report field, the system can show that this is based on the activation of standard features in the feature library for equity inheritance notarization. This training mechanism makes the AI ​​decision-making process transparent and auditable to legal professionals, meeting the high requirements of judicial support systems for algorithmic fairness and transparency.

[0048] When a notary office launches a new type of specialized business (such as a novel data asset custody notarization service), it only needs to write a standard field configuration requirement document for that business and extract its features. The model can then quickly generate a usable initial configuration draft based on existing category identifiers and similar features (such as the feature association between custody and eviction), without having to wait for a large number of actual case samples to be collected for full retraining. This significantly shortens the cold start cycle for launching new businesses.

[0049] More preferably, the step of selecting standard field configuration requirement features that match the case description information from a variety of standard field configuration requirement features includes: Determine the similarity between each standard field configuration requirement feature and the case description information; and based on the similarity, select at least one standard field configuration requirement feature with the highest similarity from the multiple standard field configuration requirement features.

[0050] When the similarity of the required features of the standard field configuration with the highest similarity is lower than a preset threshold, the manual configuration mode is triggered, and the manually configured field configuration is used as a new training sample to update the pre-trained AI model. The case description information for determining the current notarization case includes: Obtain the original description of the notarization request input by the user, wherein the original description of the notarization request carries request data; Based on the established rules and the aforementioned requirement data, data cleaning is performed to obtain standardized requirement data. The aforementioned standard requirements data are converted into the aforementioned case description information.

[0051] In implementation, feature selection is performed by calculating similarity. The system moves beyond simple keyword matching to precise recall based on semantic spatial distance. For example, if a party describes the passing of an elderly family member and how to transfer the house to their child, the semantic vector will show high similarity to the inheritance notarization feature, rather than the literal matching feature for gift notarization. Selecting at least one feature with the highest similarity allows the system to provide combined configuration solutions for complex cases (such as simultaneously recommending inheritance and property division features). A preset threshold is set as the decision boundary. When the AI ​​lacks confidence in the best-matching feature (e.g., the user input is extremely colloquial, logically contradictory, or falls outside the scope of notarization), the system automatically triggers a manual configuration mode instead of forcibly recommending an incorrect configuration. This is crucial in the field of notarization, a legal service with zero tolerance for errors. Cleaning and transforming demand data can compress lengthy natural language statements into concise, privacy-free case description vectors. The original description might contain specific names and monetary amounts, while the transformed case description retains only legal factual features (such as inheritance by multiple children, real estate, and the absence of a will). This reduces the risk of sensitive information exposure when calling large models for inference or logging. The token sequence input to the model is shorter, resulting in faster inference and lower computational resource consumption. Calculating similarity based on cleaned and standardized demand data is significantly more accurate than directly calculating similarity from the original speech-to-text. For example, if a party says, "I want to check if my notarization from last month is ready," the cleaned data extracts the core intent as "notarization progress query," preventing the model from incorrectly matching features of a birth notarization from last month to recommend form configurations. This ensures accuracy in the feature matching stage.

[0052] Specifically, the demand data includes demand sub-data corresponding to at least one notarization demand sub-item; The process of cleaning data based on the set rules and the required data to obtain standardized required data includes: Extract the corresponding requirement sub-features from each requirement sub-data, wherein the requirement sub-features are used to indicate the requirement standardization of the corresponding requirement data, and the requirement standardization includes clarity, completeness and testability; From the requirement sub-features corresponding to each of all requirement sub-data, the requirement sub-features that conform to the set rules are selected, wherein the set rules indicate the requirement normative requirements that match the requirement normative; The required sub-data corresponding to each of the required sub-features that conform to the set rules are used to form the standardized required data.

[0053] More preferably, the dynamic processing method further includes: The historical notary case dataset is stored in the big data platform. The historical notary case dataset contains multiple historical case records. Each historical case record includes historical dynamic field configuration, historical document template identifier, historical unified data container content, and historical execution result evaluation. The historical notarization case dataset is divided into multiple data subsets, each of which is associated with one of multiple expert networks. The expert network is used to output recommended field configurations or document templates based on the input case characteristics. Receive initial information about the current notarization case, including the case type, creditor attributes, and type of debt object; From the historical notarized case dataset, obtain target historical case data that matches the initial information of the current notarized case; Based on the target historical case data, at least one candidate data subset is selected from the plurality of data subsets, wherein there are overlapping data records between the candidate data subset and the target historical case data; Invoke the expert network associated with each of at least one subset of candidate data, and generate recommended field configurations and / or recommended document templates for the current notarization case based on the target historical case data; The recommended field configurations and / or recommended document templates are displayed in a visual interface, allowing users to confirm or modify them before application.

[0054] Storing historical unified data container content and execution result evaluations in a big data platform involves more than just storing field configurations; it stores complete input-process-output-feedback closed-loop data. This means the system records not only which tables were used, but also, under specific case circumstances, the final evaluation of the generated documents. This provides subsequent recommendations with weighted criteria based on actual case-handling quality, rather than simply relying on semantic similarity.

[0055] In practice, the dataset is divided into subsets that are associated with different expert networks. Each expert network is actually a micro-model for a specific business domain (e.g., one expert network specializes in financial lending and notarization, while another specializes in marriage, family, and inheritance notarization).

[0056] General-purpose large models may perform poorly when handling all business scenarios, while expert networks, focusing only on specific subsets of data, exhibit extremely high sensitivity and accuracy to domain-specific rules, regional judicial practices, and the special requirements of specific courts. The routing mechanism allows for computation in a given case to be performed by only one or two related lightweight expert networks, without activating all parameters, thus reducing inference latency and computational cost.

[0057] Matching is performed using initial information across three dimensions: case type, creditor attributes, and type of debt. The technical advantage of this multi-dimensional tagging system is that: Precisely pinpoint subset boundaries. For example, in the case of loan contract notarization, the expert network and recommendation field configurations triggered are completely different depending on whether the creditor is a bank (financial institution) or an individual (private lending) (the former requires a compliance review field, while the latter requires a funding source explanation field).

[0058] Narrowing the search space effectively prevents financial notarization cases from being misrouted to the marriage notarization expert network, thus improving the professional relevance of the recommendation results. The selection of candidate data subsets is based on records that overlap with the target data. This is not merely simple classification, but rather utilizes the concept of collaborative filtering.

[0059] Cross-domain recommendations are possible because some cases, while categorized as type A, frequently overlap with certain configurations in a subset of type B cases during historical execution (e.g., historical data shows that fields from a property valuation expert network are often required when handling equity inheritance notarization). This mechanism allows the system to automatically discover and recommend relevant fields across business domains, something a single linear classification model struggles to achieve. The selection of candidate data subsets is based on records that overlap with the target data. This goes beyond simple classification; it leverages the principles of collaborative filtering.

[0060] Cross-domain recommendations are possible because some cases, while categorized as type A, often overlap with certain configurations in a subset of type B during historical execution (e.g., historical data shows that fields from a property valuation expert network are frequently required when handling equity inheritance notarization). This mechanism allows the system to automatically discover and recommend relevant fields across business domains, something difficult to achieve with a single linear classification model. The expert network outputs recommended field configurations (front-end data collection form) and recommended document templates (back-end generation logic). This connects the data collection and document creation processes.

[0061] Recommended field configurations and document templates are generated in tandem. For example, if a configuration containing a debt extension agreement field is recommended, a document template containing extension clause logic will also be recommended. This avoids the system gap issue where the front-end collects data, but the back-end lacks the corresponding template logic to display that data. Historical data includes evaluations of historical execution results (such as the notary's modification rate of the generated documents and the number of times the parties submitted supplementary materials). When training and calling the expert network, the system can automatically favor historical configurations with high evaluations and few modifications.

[0062] To suppress low-quality paths, if a configuration recommended by an expert network historically frequently leads to significant modifications by notaries, its routing weight will be reduced. Best practices are reinforced, ensuring that the system's recommended configurations increasingly align with the notary office's internally recognized best operating procedures, achieving self-evolutionary optimization of the business process.

[0063] Consistent with the aforementioned mechanism, the final result is displayed and allowed for user confirmation or modification. This ensures that the automated process driven by big data and AI remains strictly under the final review and discretion of the notary. Even if the expert network recommends the historically most frequently optimal solution, the notary still has the right to manually intervene and adjust based on the specific legal risks of the case (such as sensitive party identities or defects in the ownership of the subject matter), complying with the requirements of judicial assistance work.

[0064] The plurality of expert networks includes two lightweight expert networks and one heavyweight expert network, wherein the computational resources required to run the at least two lightweight expert networks simultaneously are less than the computational resources required to run the heavyweight expert network. The invocation of the expert network associated with each of the at least one subset of candidate data includes: Invoke the lightweight expert network associated with the at least one subset of candidate data; If the confidence level of the recommendation result output by the lightweight expert network is lower than the confidence level threshold, then the heavyweight expert network is further invoked to recalculate the target historical case data, and the output of the heavyweight expert network is used as the final recommendation result.

[0065] Each historical case record is pre-labeled with an execution effect tag, which includes at least one of the following: document generation efficiency, field completeness, and number of user modifications. Associating each subset of data with one of multiple expert networks includes: For each data subset, all historical case records in the data subset are input into each expert network for computation to obtain the predicted execution effect output by each expert network; the similarity between the actual execution effect label of the data subset and the predicted execution effect output by each expert network is determined; and the data subset is associated with the expert network with the highest similarity.

[0066] More preferably, the step of acquiring target historical case data that matches the initial information of the current notarization case includes: Feature extraction is performed on the initial information of the current notarized case to obtain the current case feature vector; Feature extraction is performed on each historical case record in the historical notarized case dataset to obtain the corresponding historical case feature vector; Calculate the similarity between the current case feature vector and the feature vector of each historical case; Select the historical case records with the highest similarity as the target historical case data; The process of dividing the historical notarized case dataset into multiple data subsets includes: Clustering is performed on all historical case records in the aforementioned historical notarized case dataset to obtain multiple cluster centers; Each historical case record is assigned to the data subset corresponding to the cluster center that is most similar to its characteristics; The number of the multiple data subsets is equal to the number of the multiple cluster centers, and each data subset is associated with an expert network.

[0067] By extracting features from initial information and historical case records, unstructured text of legal documents (such as case descriptions and party characteristics) is mapped into computable mathematical vectors. This goes beyond keyword matching; for example, if the current case's feature is default on micro-enterprise operating loans, it can accurately match cases in the historical vector space that represent financing risks for small and medium-sized enterprises, even if the words "micro-enterprise" never appear in the literal descriptions of those historical cases. This achieves retrieval based on the essence of legal facts, rather than on literal overlap.

[0068] Specifically, a set number of records with the highest similarity are selected as target data. This step technically constructs a dynamic, virtual training set tailored to the current case. Based on this personalized fine-tuning, subsequent expert network recommendations are not based on massive amounts of general data, but rather on a small number of high-quality historical cases highly similar to the current case. This makes the recommendations highly case-specific and context-adaptive.

[0069] Instead of manually pre-defined categories, the system uses clustering algorithms to partition data subsets. It may automatically cluster data into categories not yet clearly defined by humans, such as complex notarization involving the disposal of real estate in different locations and the protection of the rights of the elderly. These cluster centers represent the inherent distribution patterns of the business data. As new business emerges (such as virtual property inheritance and data compliance notarization), the cluster centers will automatically shift or be added, without requiring manual modification of the classification codes by technical personnel. This allows the system to adapt to the evolution of legal practice.

[0070] The process consists of two steps: the first step (retrieval) coarsely filters out the top N similar records from the full dataset; the second step (expert network) performs fine-grained calculations only based on a small subset to which the filtered records belong. Compared to having each expert network calculate for the current case (which has high time complexity), the system only needs to call 1-2 expert networks associated with the subset overlapping with the target records. This can reduce inference latency by an order of magnitude when the historical data volume reaches millions.

[0071] Each cluster center corresponds to an independent expert network. Since clustering is based on the factual characteristics of the cases, this means that: the expert network for subset 1 (financial lending) focuses only on learning the interest rate calculation field, the logic of extension clauses, and the enforcement clauses. The expert network for subset 2 (family inheritance) focuses only on learning the kinship graph, the formal requirements of wills, and the mandatory share rule. Parameter isolation: Training or fine-tuning the expert network for subset 1 will not affect the knowledge already learned by the expert network for subset 2, effectively preventing the catastrophic forgetting problem common in training general models.

[0072] Because the target data is selected based on explicit historical record IDs, the recommended source is traceable.

[0073] When a notary inquires why the system recommended this uncommon field, the system can clearly answer: because in two highly similar historical cases, numbered GZ2023-0182 and GZ2024-1156, the notary configured this field, and both cases received excellent ratings. This recommendation logic based on real precedents, compared to the black-box explanations that AI models deem probable, has stronger persuasiveness and compliance in judicial assistance scenarios. Even when sufficient current case description text is lacking, vector retrieval based solely on three high-dimensional sparse features—case type, creditor attributes, and debt type—combined with cluster center mapping, can still quickly identify a roughly correct subset of the business domain, with a benchmark configuration template provided by a network of experts in that domain. This ensures that the system can provide initial suggestions with some reference value even before the user has entered detailed case information.

[0074] More preferably, the step of invoking the expert network associated with at least one subset of candidate data to generate recommended field configurations and / or recommended document templates for the current notarization case based on the target historical case data includes: For each candidate data subset, the overlapping data records between the target historical case data and the candidate data subset are input into the expert network associated with the candidate data subset for calculation, and the recommendation result output by the expert network is obtained. Determine the proportion of the number of data records overlapping between the target historical case data and each candidate data subset to the total number of records in the target historical case data; The recommendation results output by the expert networks associated with at least one subset of candidate data are weighted and merged according to a certain ratio to generate the final recommendation field configuration and / or recommendation document template.

[0075] The method further includes: when the number of overlapping data records between the target historical case data and any candidate data subset is less than a preset threshold, excluding the candidate data subset from the weighted merging.

[0076] The data is weighted and merged based on the percentage of overlapping records. This is not a simple arithmetic average or vote, but rather introduces the statistical concept of confidence level.

[0077] If 80% of the records in the target historical case data fall within a subset of the financial lending expert network, it indicates that the current case highly overlaps with the network's business area, making the network's opinions highly valuable. If only 5% of the records fall within the marriage and family law expert network, it suggests that only some marginal facts are relevant, and their recommendations will only slightly influence the outcome as supplementary references. This ensures a smooth transition in the final recommended configuration, rather than drastic jumps at business boundaries.

[0078] Setting a preset threshold and excluding low-overlapping expert networks plays a crucial role in noise reduction and pollution prevention. For example, a network specializing in equity inheritance might hastily recommend a field simply because the historical data contains very little information on property valuation. When the overlap ratio is below the threshold, the system determines that the expert network lacks authority in the case and silences it. Excluding expert networks with minimal contributions reduces the amount of floating-point operations during weighted calculations, saving considerable CPU cycles in large-scale concurrent recommendations.

[0079] The expert network only processes the overlapping data records, not all the data in that subset. The expert network's focus is strictly limited to historical fragments directly related to the current case. For example, a financial expert network only sees historical case configurations with similar loan amounts and default scenarios, without being influenced by configurations of other large-scale financing cases within the subset. For expert networks using large language models, the length of the input tokens is reduced, allowing the model to focus more on processing highly relevant detailed logic.

[0080] Through weighted merging, the final recommended configuration automatically incorporates advantages from multiple fields. Case scenario: Handling a notarized case involving the division of company shares in a divorce. 60% of the target data falls within the divorce property division expert network (providing: divorce certificate, agreement, child custody fields). 30% of the target data falls within the equity transfer expert network (providing: shareholder meeting resolution, pre-emptive right waiver statement, valuation report fields). Merged result: The system-generated form has a large and complete core section (divorce agreement), while the supplementary section (equity procedures) is accurate and professional. This avoids the problem of neglecting certain aspects by relying on a single expert network.

[0081] Because the final result is derived using a clearly weighted average, notaries can see not only the recommended outcome but also the decision-making process on the review interface (e.g., this recommendation is 60% based on financial lending practices and 30% on rules governing the handling of security interests). This transparent algorithmic logic ensures that the system's decision-making process can withstand judicial review. If a party objects to the content of the notarized document, the notary office can provide evidence demonstrating that the configuration is based on statistically optimal solutions derived from big data, rather than arbitrary selections.

[0082] By using proportional weighting rather than hard routing, the system can handle complex notarization cases spanning multiple domains. With the increasing complexity of socio-economic life, new notarization needs have emerged, encompassing the establishment of residency rights, reverse mortgages, and testamentary trusts. Traditional rule engines struggle to cover these needs. This solution, however, automatically combines the most relevant field fragments from the expert networks of the three domains through the natural distribution ratio of overlapping records, generating a completely new form configuration specifically for this complex case with zero code and zero configuration.

[0083] Because of the introduction of dynamic scheduling based on overlap ratio, when a notary office launches a new expert network (such as an expert network specifically for handling cryptocurrency inheritance), there is no need to modify the original code logic. The data subset corresponding to the new expert network initially has an extremely low overlap ratio (even below the threshold), and it remains in a silent observation state. As data on this type of new case accumulates, the overlap ratio gradually increases, and the weight of the new expert network automatically increases, smoothly taking over the recommendation leadership for this type of business. This ensures the stability of the system during upgrades and iterations.

[0084] Specifically, the dynamic processing method further includes: For pre-trained AI models, the first confidence level is determined based on the similarity between the matched standard field configuration demand features and the case description information. For expert networks, the second confidence level is determined based on the proportion of overlapping data between the target historical case data and the current case data. The first and second confidence levels are displayed in the visualization interface as progress bars or percentages.

[0085] After assembling the collected structured data into a unified data container, the sensitive data fields in the unified data container are encrypted and converted to generate an encrypted data container for subsequent processing. This enables the encryption of key information.

[0086] The dynamic processing method in this embodiment of the invention can dynamically configure field metadata and generate collection forms without modifying the database or code, and is suitable for various notary services; a unified data container enables standardized data management; and through visual document templates and control statements, the editing threshold is reduced, and finally, the template engine automatically generates standardized and accurate notary documents.

[0087] Example 2 Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of the notary execution dynamic processing system supporting document visualization programming disclosed in an embodiment of the present invention. Figure 5 As shown, the notary execution dynamic processing system that supports document visualization programming may include: Receiving module 21: Used to receive dynamic field metadata input from the visual interface. The dynamic field metadata includes field identifier, field type, data source identifier, and display attributes. The field type includes basic type, object type, and array type. The object type supports nested subfields. Storage module 22: used to store the dynamic field metadata in a metadata repository, and dynamically generate a data collection form at runtime based on the dynamic field metadata, wherein the data collection form is used to collect structured data in notarized enforcement cases; Assembly module 23: used to assemble the collected structured data into a unified data container, wherein the unified data container stores fixed field data, dynamically extended field data and system field data in key-value pair form; Visualization module 24: provides a visual template editing interface for natural language documents. The visual template editing interface includes document templates, and control statements and filters are predefined in the document templates. The control statements include loop statements and conditional statements, and the filters are used to perform format conversion on the data in the unified data container. Generation module 25: In response to a document generation request, it parses the document template through a template engine, maps the control statements and filters to intermediate representations, and executes the intermediate representations based on the data in the unified data container to generate the final document.

[0088] The dynamic processing method in this embodiment of the invention can dynamically configure field metadata and generate collection forms without modifying the database or code, and is suitable for various notary services; a unified data container enables standardized data management; and through visual document templates and control statements, the editing threshold is reduced, and finally, the template engine automatically generates standardized and accurate notary documents.

[0089] Example 3 Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention. The electronic device can be a computer, a server, etc. Of course, in certain cases, it can also be a mobile phone, tablet computer, monitoring terminal, or other smart device, as well as an image acquisition device with processing capabilities. Figure 6 As shown, the electronic device may include: Memory 510 storing executable program code; Processor 520 coupled to memory 510; The processor 520 calls the executable program code stored in the memory 510 to execute some or all of the steps in the notarization execution dynamic processing method supporting document visualization programming in Embodiment 1.

[0090] This invention discloses a computer-readable storage medium storing a computer program that enables a computer to perform some or all of the steps in the notarization execution dynamic processing method supporting document visualization programming in Embodiment 1.

[0091] This invention also discloses a computer program product, wherein when the computer program product is run on a computer, the computer executes some or all of the steps in the notarization execution dynamic processing method supporting document visualization programming in Embodiment 1.

[0092] This invention also discloses an application publishing platform, which is used to publish computer program products. When the computer program products are run on a computer, the computer executes some or all of the steps in the notarization execution dynamic processing method supporting document visualization programming in Embodiment 1.

[0093] In various embodiments of the present invention, it should be understood that the sequence number of each process does not necessarily imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

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

[0095] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0096] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-accessible memory. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several requests to cause a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute some or all of the steps of the methods described in the various embodiments of the present invention.

[0097] In the embodiments provided by this invention, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0098] Those skilled in the art will understand that some or all of the steps in the various methods of the embodiments described can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0099] The foregoing has provided a detailed description of the notarization execution dynamic processing method, system, electronic device, and storage medium supporting document visualization programming disclosed in the embodiments of the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A dynamic processing method for notarization execution that supports visual programming of documents, characterized in that, include: Receive dynamic field metadata input from the visual interface. The dynamic field metadata includes field identifier, field type, data source identifier, and display attributes. The field type includes basic type, object type, and array type. The dynamic field metadata is stored in a metadata repository, and a data collection form is dynamically generated at runtime based on the dynamic field metadata. The data collection form is used to collect structured data in notarized enforcement cases. The collected structured data is assembled into a unified data container, which stores fixed field data, dynamically extended field data, and system field data in key-value pairs. A visual template editing interface based on natural language documents is provided. The visual template editing interface includes document templates, and control statements and filters are predefined in the document templates. The control statements include loop statements and conditional judgment statements, and the filters are used to perform format conversion on the data in the unified data container. In response to a document generation request, the document template is parsed through a template engine, the control statements and filters are mapped to intermediate representations, and the intermediate representations are executed based on the data in the unified data container to generate the final document.

2. The notarization execution dynamic processing method supporting document visualization programming as described in claim 1, characterized in that, The dynamic field metadata received from the visual interface includes: In response to user actions of adding or editing fields in the visual interface, generate or modify dynamic field metadata; The dynamic field metadata is serialized into JSON format and stored in the metadata repository; without modifying the physical table structure of the database or restarting the service, the dynamic field metadata immediately takes effect in the subsequent data collection form generation process; The template engine parses the document template, including: The document template is parsed into an abstract syntax tree, wherein the node types of the abstract syntax tree include text nodes, loop nodes, conditional judgment nodes, and filter nodes; The parsed abstract syntax tree is cached in memory or a distributed cache; If subsequent requests to parse the same document template directly load the cached abstract syntax tree, the re-parsing step is skipped; When executing the abstract syntax tree, the expressions in the conditional nodes and loop nodes are executed in a restricted sandbox environment, and access to the file system, network interface or execution of arbitrary system commands is prohibited.

3. The notarization execution dynamic processing method supporting document visualization programming as described in claim 1, characterized in that, The dynamic processing method further includes: A pre-trained AI model configured with field prompt information, wherein the field prompt information includes multiple standard field configuration requirement features obtained after training the initial AI model using standard field configuration requirement information of multiple standard notary business types; Determine the case description information and case type identifier of the current notarization case; The case description information and the case type identifier are input into the pre-trained AI model, so that the pre-trained AI model selects standard field configuration requirement features that match the case description information from a variety of standard field configuration requirement features, and generates and outputs recommended dynamic field configurations based on the case type identifier and the selected standard field configuration requirement features. The recommended dynamic field configuration is displayed in a visual interface, allowing users to confirm or modify it before application.

4. The notarization execution dynamic processing method supporting document visualization programming as described in claim 3, characterized in that, The training process of the pre-trained AI model includes: Obtain standard field configuration requirements information for various standard notary business types, as well as sample case type identifiers and sample field configurations for sample notary cases. The various standard field configuration requirements information corresponds one-to-one with the various standard field configuration requirements features. Text feature extraction is performed on each type of standard field configuration requirement information to obtain the standard field configuration requirement features corresponding to each type of standard field configuration requirement information; The sample case type identifier and each standard field configuration requirement feature are input into the large language model to generate the standard field configuration corresponding to each standard field configuration requirement feature; Based on the configuration requirements of the various standard fields and their corresponding standard field configurations, as well as the sample case type identifier, the initial AI model is trained to obtain the pre-trained AI model; The process of training the initial AI model to obtain the pre-trained AI model based on the configuration requirements features of the multiple standard fields and their corresponding standard field configurations, as well as the sample case type identifier, includes: Each standard field configuration requirement feature and the corresponding sample case type identifier are input into the initial AI model to generate the initial field configuration corresponding to each standard field configuration requirement feature; For each standard field configuration requirement, determine the configuration differences between the corresponding initial field configuration and the corresponding standard field configuration; Based on the configuration differences corresponding to the configuration requirements of the various standard fields, the initial AI model is trained to obtain the pre-trained AI model.

5. The notarization execution dynamic processing method supporting document visualization programming as described in claim 3, characterized in that, The step of selecting standard field configuration requirement features that match the case description information from a variety of standard field configuration requirement features includes: Determine the similarity between each standard field configuration requirement feature and the case description information; and based on the similarity, select at least one standard field configuration requirement feature with the highest similarity from the multiple standard field configuration requirement features. When the similarity of the required features of the standard field configuration with the highest similarity is lower than a preset threshold, the manual configuration mode is triggered, and the manually configured field configuration is used as a new training sample to update the pre-trained AI model. The case description information for determining the current notarization case includes: Obtain the original description of the notarization request input by the user, wherein the original description of the notarization request carries request data; Based on the established rules and the aforementioned requirement data, data cleaning is performed to obtain standardized requirement data. The aforementioned standard requirements data are converted into the aforementioned case description information.

6. The notarization execution dynamic processing method supporting document visualization programming as described in claim 1, characterized in that, The dynamic processing method further includes: The historical notary case dataset is stored in the big data platform. The historical notary case dataset contains multiple historical case records. Each historical case record includes historical dynamic field configuration, historical document template identifier, historical unified data container content, and historical execution result evaluation. The historical notarization case dataset is divided into multiple data subsets, each of which is associated with one of multiple expert networks. The expert network is used to output recommended field configurations or document templates based on the input case characteristics. Receive initial information about the current notarization case, including the case type, creditor attributes, and type of debt object; From the historical notarized case dataset, obtain target historical case data that matches the initial information of the current notarized case; Based on the target historical case data, at least one candidate data subset is selected from the plurality of data subsets, wherein there are overlapping data records between the candidate data subset and the target historical case data; Invoke the expert network associated with each of at least one subset of candidate data, and generate recommended field configurations and / or recommended document templates for the current notarization case based on the target historical case data; The recommended field configurations and / or recommended document templates are displayed in a visual interface, allowing users to confirm or modify them before application.

7. The notarization execution dynamic processing method supporting document visualization programming as described in claim 6, characterized in that, The acquisition of target historical case data that matches the initial information of the current notarization case includes: Feature extraction is performed on the initial information of the current notarized case to obtain the current case feature vector; Feature extraction is performed on each historical case record in the historical notarized case dataset to obtain the corresponding historical case feature vector; Calculate the similarity between the current case feature vector and the feature vector of each historical case; Select the historical case records with the highest similarity as the target historical case data; The process of dividing the historical notarized case dataset into multiple data subsets includes: Clustering is performed on all historical case records in the aforementioned historical notarized case dataset to obtain multiple cluster centers; Each historical case record is assigned to the data subset corresponding to the cluster center that is most similar to its characteristics; The number of the multiple data subsets is equal to the number of the multiple cluster centers, and each data subset is associated with an expert network.

8. The notarization execution dynamic processing method supporting document visualization programming as described in claim 6, characterized in that, The step of invoking the expert networks associated with at least one subset of candidate data to generate recommended field configurations and / or recommended document templates for the current notarization case based on the target historical case data includes: For each candidate data subset, the overlapping data records between the target historical case data and the candidate data subset are input into the expert network associated with the candidate data subset for calculation, and the recommendation result output by the expert network is obtained. Determine the proportion of the number of data records overlapping between the target historical case data and each candidate data subset to the total number of records in the target historical case data; The recommendation results output by the expert networks associated with at least one subset of candidate data are weighted and merged according to a certain ratio to generate the final recommendation field configuration and / or recommendation document template. The method further includes: when the number of overlapping data records between the target historical case data and any candidate data subset is less than a preset threshold, excluding the candidate data subset from the weighted merging.

9. A notary execution dynamic processing system supporting document visualization programming, characterized in that, include: Receiving module: Used to receive dynamic field metadata input from the visual interface. The dynamic field metadata includes field identifier, field type, data source identifier, and display attributes. The field type includes basic type, object type, and array type. Storage module: used to store the dynamic field metadata in a metadata repository, and dynamically generate a data collection form at runtime based on the dynamic field metadata, wherein the data collection form is used to collect structured data in notarized enforcement cases; Assembly module: Used to assemble the collected structured data into a unified data container, which stores fixed field data, dynamically extended field data and system field data in key-value pair format; Visualization module: This module provides a visual template editing interface for natural language documents. The visual template editing interface includes document templates, and control statements and filters are predefined in the document templates. The control statements include loop statements and conditional statements, and the filters are used to perform format conversion on the data in the unified data container. Generation module: In response to a document generation request, it parses the document template through a template engine, maps the control statements and filters into intermediate representations, and executes the intermediate representations based on the data in the unified data container to generate the final document.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program causes a computer to execute the notarization execution dynamic processing method supporting document visualization programming as described in any one of claims 1 to 8.

Images