A method and system for multi-source material arrangement and format closed-loop verification based on official document syntax tree

Abstract

The application relates to a multi-source material arrangement and format closed-loop verification method and system based on a document syntax tree, which comprises receiving a document type, multi-source materials and task constraints; identifying the document type and analyzing a suitable rule package; constructing a document syntax tree containing paragraph slots and execution constraints; analyzing the multi-source materials into fact-level or policy basis-level evidence units; performing evidence deduplication, timeliness checking, conflict grouping and authority level calculation; calculating the matching scores of the evidence units and the paragraph slots and performing access; constructing a generation context for each slot and limiting the evidence range of the generation model; outputting a DOCX document with a structured style; analyzing the DOCX to form an effective layout object; generating verification questions according to the rule package; performing transactional repair on the deterministic questions, and outputting a document, an evidence mapping table, a verification report and a repair record. The application improves the determinacy, traceability and recoverability of the document processing process.

Description

Technical Field

[0001] This invention belongs to the fields of computer document processing, natural language processing, and office automation technology. Specifically, it relates to a closed-loop processing method that converts official document specifications into machine-executable official document syntax trees, converts multi-source materials into traceable evidence units and matches them with paragraph slots in the syntax tree, generates official document content under the control of a rule engine, and performs detection, hierarchical repair, and re-inspection on the valid format of DOCX documents. Background Technology

[0002] When government agencies, enterprises, public institutions, and industry organizations create formal documents such as notices, requests for instructions, reports, letters, and minutes, they typically need to simultaneously meet the requirements of document type structure, writing relationships, fixed elements, factual basis, language style, and format specifications. The information used in the main body of the document may come from policy documents, institutional documents, meeting minutes, historical documents, business data, attachments, and user supplementary explanations. Different sources may differ in terms of authority level, version, effective date, granularity of expression, and scope of application.

[0003] Existing static template tools mainly provide fixed headings and paragraph frames, which can constrain some appearances, but they are difficult to express conditional nodes, required nodes, node order, evidence requirements, document type inheritance, and unit template coverage relationships. When templates are updated, existing rules usually need to be manually modified item by item, and it is difficult to indicate which version of the rules was ultimately adopted.

[0004] Existing search-enhanced generation or large language model generation solutions can generate text based on source materials, but these models typically receive entire batches of materials directly, lacking mechanisms for fact-level evidence inclusion, slot-level evidence scope, and conflict handling. When different documents contain duplicate, expired, or contradictory information, the model may splice them together haphazardly, omit key evidence, or generate statements whose original locations cannot be traced. Official document specifications are not converted into executable structures; the required elements, order, and conditional relationships of document types can only be understood manually. Multi-source materials lack fact-level standardization and source location records, making it impossible to reliably trace text statements back to original evidence. There is a lack of version inheritance, overriding, and conflict handling among national standards, document type rules, unit templates, and task constraints.

[0005] Existing format checking tools often rely on surface text, fixed templates, or results displayed in a single editor for post-processing checks. They may not be able to parse the inheritance relationships between direct formatting, paragraph styles, basic styles, and document defaults in DOCX files, and they struggle to uniformly represent content structure errors, attachment citation errors, and page layout errors as calculable problem objects. There is a lack of comprehensive matching and admission mechanisms between source material and paragraph slots, allowing irrelevant, repetitive, or low-authority material to be included in key paragraphs. The boundaries between rule engines and generation models are unclear, and generation models may exceed constraints related to document type structure, evidence scope, or prohibited expressions. Format validation fails to parse valid OOXML formats, easily misjudging style inheritance results as missing formats or omitting direct formatting anomalies.

[0006] Existing automated repair solutions typically replace fonts, paragraphs, or numbering directly, lacking risk assessment, pre-repair state snapshots, impact scope analysis, post-repair re-parsing, and rollback upon failure. When a repair changes paragraph order or numbering relationships, it may further disrupt attachment citations, cross-references, or signature placement. Automated repair lacks risk assessment, transaction logging, review, and rollback; repair actions may introduce new structural or citation errors. Output usually only contains the main text, lacking evidence mapping tables, rule hit records, validation reports, and repair trails, making auditing difficult. Summary of the Invention

[0007] This invention addresses the shortcomings of existing technologies by proposing a method and system for multi-source material arrangement and format closed-loop verification based on official document syntax trees. It solves the following problems: how to convert heterogeneous official document specifications and unit templates into official document syntax trees with version, inheritance, slots, and execution constraints in a computer system; how to parse multi-source materials into fact-level evidence units with source location, timeliness, and authority attributes, and accordingly complete slot-level admission and matching; how to restrict the generation engine to use only currently admitted evidence in the current slot; and how to parse valid formats from generated DOCX documents, form problem objects, and form a closed loop through risk classification, transaction repair, re-verification, and failure rollback, thereby improving the determinism, traceability, and recoverability of the document processing process.

[0008] The technical solution adopted in the invention: A method for multi-source material arrangement and format closed-loop verification based on official document syntax trees, the process of which includes: Obtain official document task information and multi-source materials, determine the applicable official document rule set based on the official document task information, and construct an official document syntax tree based on the official document rule set. The official document syntax tree includes multiple nodes corresponding to the components of the official document, and each node is configured with paragraph slots and corresponding structural constraints, evidence constraints and layout constraints. The multi-source material is analyzed to generate multiple evidence units. Each evidence unit includes at least factual content and source location. Based on the matching relationship between the evidence units and paragraph slots, the evidence units that meet the evidence constraints are admitted into the corresponding paragraph slots to form a slot evidence mapping. Slot generation context is constructed based on the node constraints and admission evidence units corresponding to each paragraph slot. Slot content is generated using the content generation engine according to the document syntax tree. The content generation engine is restricted to using only the admission evidence units of the current paragraph slot. A DOCX document is generated based on the slot content and the corresponding layout constraints. The OOXML body part, style part, numbering part and section settings of the DOCX document are parsed. The effective layout of the document elements is determined according to the inheritance and overriding relationships of various format attributes. Based on the official document syntax tree, the official document rule set, the slot evidence mapping and the effective layout, a verification question containing the question location and risk level is generated. For verification issues that meet the conditions for automatic repair, a snapshot before repair is created and repair is performed. The repaired DOCX document is then re-parsed and verified for valid formatting. If the original verification issue disappears and no higher-risk verification issue arises, the repair result is retained; otherwise, a rollback is performed based on the snapshot before repair. For verification issues that do not meet the conditions for automatic repair, manual confirmation is required. If there are no unresolved verification issues, output the verified DOCX document, slot evidence mapping, and repair record; otherwise, output the document awaiting manual processing and the unresolved issues.

[0009] The method for multi-source material arrangement and format closed-loop verification based on official document syntax trees includes the following steps in its implementation process: S101, receiving and standardizing official documents; It receives document type, recipient, subject matter, multi-source materials, unit identifier and task constraints, generates task_id, unifies character encoding, time and file identifier, and outputs document task context (DocumentTaskContext). S102 identifies the document type and writing relationship, and parses the applicable rule package, its version, and priority; Based on the explicit document type, recipient, subject, and common structure, determine whether it is a notice, request for instructions, report, letter, or minutes, identify the upward, downward, or parallel relationship, perform document type determination, and output the document type decision (DocumentTypeDecision). S103, parse and merge rule packets; Based on the input document type, unit identifier, task date, task constraints, and rule base, the validity period of rules is filtered. First, mandatory rules that cannot be overridden are verified. Then, for each rule attribute, the first defined value is selected in the order of task constraints, unit overriding, document type rules, and system default rules to generate a set of resolved rule sets and rule conflicts. S104. Based on the resolved rule set and task constraints, construct an executable document syntax tree (DocumentSyntaxTree) containing paragraph slots and execution constraints. This includes generating nodes such as title, addressee, introduction, matters, requirements, attachments, signature, and date, and binding order, cardinality, conditions, evidence, and format constraints. S105, analyzes multi-source materials into fact-level or policy-based evidence units; Based on policies, regulations, minutes, historical documents, business data, and attachments, analyze the document structure, paragraphs, tables, versions, dates, and source locations, segment the candidate content into factual or evidence fragments, and output the candidate material unit. S106, Generate fact-level evidence units; Based on the candidate material unit, extract the fact subject, predicate, fact value, topic, evidence type, authority level, validity period and scope of application, and generate a content hash to generate a set of evidence units. S107, perform evidence deduplication, timeliness check, conflict grouping and authority level calculation; Based on the evidence unit set, group by content hash and fact triplet, detect expired and conflicting evidence, determine the main evidence, supporting evidence and evidence prohibited from automatic adoption, and output the evidence set marked with validity, duplicate group and conflict group; S108, Calculate the matching score between the evidence unit and the paragraph slot and perform admission; S109, construct a generation context for each slot and limit the scope of evidence for the generation model; S110, execute the generation of constrained content; The rule template or large language model is called sequentially according to the syntax tree to generate content, and the fact coverage, prohibited expressions, length and citation integrity are verified; the set of slot content is output and the verification record is generated. S111, Combine slot contents and generate a DOCX document with a structured style. Based on the syntax tree, slot content, layout rules, and evidence mapping, paragraphs are grouped in node order, styles, numbering, attachments, signatures, and dates are bound, written into a DOCX package, and a draft document and an evidence mapping table are output. S112, parses DOCX direct formatting, style inheritance, numbering, and page setup to form a valid layout object; S113, Based on the syntax tree and rule package, generate validation issues and determine the risk level to fix them; S114: Perform transactional repair and re-verification on the identified verification issues, outputting a set of RepairTransaction, a set of HumanDecisions, and the re-verification results; and transfer content-related issues to manual confirmation. S115, Output delivery package, including official documents, evidence mapping table, verification report and repair record.

[0010] A system for multi-source material arrangement and format closed-loop verification based on official document syntax trees, which implements the aforementioned multi-source material arrangement and format closed-loop verification method, adopts a layered architecture of "rule parsing—evidence processing—slot generation—document parsing—verification and repair." It includes a task access module, a document type identification module, a rule package management module, a syntax tree construction module, a material parsing module, an evidence management module, a slot matching module, a constraint context module, a content generation module, a DOCX generation module, a valid layout parsing module, a format verification module, a transaction repair module, a manual confirmation module, and a result output module. Task access module: Establishes task identifiers and standardizes input parameters, permissions, and output requirements; Document type identification module: determines candidate document types, writing direction, and applicable structure, and requests confirmation when confidence is insufficient; Rule package management module: First, it verifies the mandatory rules that cannot be overridden, and then it parses the version, overriding and conflict of each attribute in the order of task, unit, document type and default rule; Syntax tree building module: Generates a node tree containing order, cardinality, condition, evidence, and format constraints; Material analysis module: Analyzes file structure, paragraph position, version and time, and segments candidate facts; Evidence management module: Performs fact-level standardization, deduplication, timeliness checks, authority calculation, and conflict grouping; Slot matching module: Calculates the overall matching score, performs admission, sorts, and records the reasons for exclusion; Constraint Context Module: Generates slot-allowed evidence, fixed terms, prohibited expressions, length, and output structure; Content generation module: calls rule templates or large language models to generate content within a single slot and performs post-generation constraint checks; DOCX generation module: Combines content according to node order, binds styles and numbering, and writes it into DOCX; Effective layout parsing module: Parses OOXML style inheritance, direct formatting, numbering, tables, sections, headers and footers, and page setup; Format validation module: Detects content structure, referencing relationships, and layout issues, and locates the source of the rules; Repair Transaction Module: Creates snapshots based on risk, performs repairs, records the scope of impact, re-checks, and rolls back on failure; Manual confirmation module: Displays the original text, evidence, rules, and candidate actions, and receives approval, rejection, or replacement instructions; Results output module: Generates archiveable text, evidence mapping table, verification report and repair record; Each module associates the rule version, syntax tree, evidence unit, mapping record, generated result, verification problem and repair transaction of the same task through the DocumentTaskContext.

[0011] The task access module sends standardized tasks to the document identification module; the rule package management module parses rules based on document type, unit, and task date; the syntax tree construction module outputs node constraints; the material parsing and evidence management module outputs evidence sets; the slot matching and constraint context module limits the input for the content generation module; the output of the DOCX generation module enters the valid layout parsing and format verification; the repair task module sends the document back for parsing and verification after automatic repair or manual confirmation until the termination conditions are met.

[0012] The present invention, a method and system for multi-source material arrangement and format closed-loop verification based on official document syntax trees, demonstrates its advancement and beneficial technical effects compared to static templates, ordinary retrieval-enhanced generation, and one-time format checks in the following ways: 1. The official document specifications are transformed from static templates into syntax trees with versioning, inheritance, and execution constraints. This makes the document type structure, required elements, sequence, and conditional relationships computer-executable constraints, enabling the specifications to be executed and verified node by node by the computer, rather than being static templates for human reference only. This solves the problem that the required elements, sequence, and conditional relationships of document types can only be filled in manually.

[0013] 2. By establishing a traceable relationship between the main text statements and the original source materials through factual evidence units and source location records, it distinguishes itself from whole-text retrieval and disordered splicing. It establishes an evidence mapping between the factual statements in the main text and the locations of the original source materials, improving the traceability of content sources. Before generation, it processes duplicate, outdated, and conflicting materials, reducing the inclusion of irrelevant or invalid materials in key paragraphs.

[0014] 3. By utilizing comprehensive matching scores, admission thresholds, conflict groups, and timeliness status, the scope of evidence for key slots is limited, reducing the possibility of expired, duplicate, or contradictory materials entering the main text. A closed loop is formed through issue objects, risk levels, repair transactions, re-validation, and failure rollback, reducing the risk of cascading structural errors caused by automatic repair. Simultaneously, evidence mapping, rule hits, issues, and repair trajectories are output, facilitating auditing, review, and subsequent rule upgrades.

[0015] 4. The structure and evidence are controlled by the rule engine, and the large language model is generated only within its slots, avoiding the establishment of invention points based on prompt words or the model's natural language output itself. This narrows the scope of evidence and output accessible to the generation model each time, improving the determinism and verifiability of the generation process. Through rule package version and priority recording, the adoption process of national standards, language rules, unit templates, and task constraints becomes explainable.

[0016] 5. Valid layouts are obtained through OOXML style inheritance calculations, enabling the detection of issues that cannot be found by simply checking surface text or style names. OOXML valid layout parsing improves the ability to detect issues related to style inheritance, direct formatting, and numbering relationships. Pre-repair snapshots, re-validation, and rollback upon failure enhance the recoverability of the document's automatic repair process.

[0017] 6. Different remediation paths are used for deterministic, structural, and content-related issues to prevent high-risk content modifications from being silently executed. The system also outputs the main text, evidence mapping table, verification report, and remediation record, supporting review, proxy drafting, and rule iteration. Attached Figure Description

[0018] Figure 1 The figure shows the system architecture of the multi-source material arrangement and format closed-loop verification method of the present invention; Figure 2 The diagram shown is a closed-loop diagram of document generation and format repair in the multi-source material arrangement and format closed-loop verification method of the present invention. Figure 3 The diagram shown is a schematic diagram of the document syntax tree and rule inheritance in the multi-source material arrangement and format closed-loop verification method of the present invention; Figure 4 This is a schematic diagram of the mapping between material evidence units and paragraph slots in the multi-source material arrangement and format closed-loop verification method of the present invention; Figure 5 The diagram shown is a flowchart of the constrained content generation process in the multi-source material arrangement and format closed-loop verification method of the present invention. Figure 6 The diagram shown is a flowchart of the DOCX valid format parsing method for multi-source material arrangement and format closed-loop verification according to the present invention. Figure 7The diagram shown is a schematic of the verification and repair state machine in the multi-source material arrangement and format closed-loop verification method of the present invention; Figure 8 The diagram shown is the overall flowchart of the multi-source material arrangement and format closed-loop verification method of the present invention. Detailed Implementation

[0019] To make the technical concept and advantages of the invention clearer, the technical solution of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the following embodiments are merely preferred embodiments for explaining and illustrating the present invention, and should not be considered as, nor constitute a limitation on, the scope of patent protection claimed by the present invention.

[0020] Example 1: This invention proposes a method for multi-source material arrangement and format closed-loop verification based on official document syntax trees, the process of which includes: Obtain official document task information and multi-source materials, determine the applicable official document rule set based on the official document task information, and construct an official document syntax tree based on the official document rule set. The official document syntax tree includes multiple nodes corresponding to the components of the official document, and each node is configured with paragraph slots and corresponding structural constraints, evidence constraints and layout constraints. The multi-source material is analyzed to generate multiple evidence units. Each evidence unit includes at least factual content and source location. Based on the matching relationship between the evidence units and paragraph slots, the evidence units that meet the evidence constraints are admitted into the corresponding paragraph slots to form a slot evidence mapping. Slot generation context is constructed based on the node constraints and admission evidence units corresponding to each paragraph slot. Slot content is generated using the content generation engine according to the document syntax tree. The content generation engine is restricted to using only the admission evidence units of the current paragraph slot. A DOCX document is generated based on the slot content and the corresponding layout constraints. The OOXML body part, style part, numbering part and section settings of the DOCX document are parsed. The effective layout of the document elements is determined according to the inheritance and overriding relationships of various format attributes. Based on the official document syntax tree, the official document rule set, the slot evidence mapping and the effective layout, a verification question containing the question location and risk level is generated. For verification issues that meet the conditions for automatic repair, a snapshot before repair is created and repair is performed. The repaired DOCX document is then re-parsed and verified for valid formatting. If the original verification issue disappears and no higher-risk verification issue arises, the repair result is retained; otherwise, a rollback is performed based on the snapshot before repair. For verification issues that do not meet the conditions for automatic repair, manual confirmation is required. If there are no unresolved verification issues, output the verified DOCX document, slot evidence mapping, and repair record; otherwise, output the document awaiting manual processing and the unresolved issues.

[0021] Example 2: See Figure 8 The present invention provides a method for multi-source material arrangement and format closed-loop verification based on official document syntax trees. The specific implementation process includes the following steps: S101, receiving and standardizing official documents; It receives document type, recipient, subject matter, multi-source materials, unit identifier and task constraints, generates task_id, unifies character encoding, time and file identifier, and outputs document task context (DocumentTaskContext). S102 identifies the document type and document relationship, and parses the applicable rule package, its version, and priority; Based on the explicit document type, recipient, subject, and common structure, determine whether it is a notice, request for instructions, report, letter, or minutes, identify the upward, downward, or parallel relationship, perform document type determination, and output the document type decision (DocumentTypeDecision). S103, parse and merge rule packets; Based on the input document type, unit identifier, task date, task constraints, and rule base, the validity period of rules is filtered. First, mandatory rules that cannot be overridden are verified. Then, for each rule attribute, the first defined value is selected in the order of task constraints, unit overriding, document type rules, and system default rules to generate a set of resolved rule sets and rule conflicts. S104. Based on the resolved rule set and task constraints, construct an executable document syntax tree (DocumentSyntaxTree) containing paragraph slots and execution constraints. This includes generating nodes such as title, addressee, introduction, matters, requirements, attachments, signature, and date, and binding order, cardinality, conditions, evidence, and format constraints. S105, analyzes multi-source materials into fact-level or policy-based evidence units; Based on policies, regulations, minutes, historical documents, business data, and attachments, analyze the document structure, paragraphs, tables, versions, dates, and source locations, segment the candidate content into factual or evidence fragments, and output the candidate material unit. S106, Generate fact-level evidence units; Based on the candidate material unit, extract the fact subject, predicate, fact value, topic, evidence type, authority level, validity period and scope of application, and generate a content hash to generate a set of evidence units. S107, perform evidence deduplication, timeliness check, conflict grouping and authority level calculation; Based on the evidence unit set, group by content hash and fact triplet, detect expired and conflicting evidence, determine the main evidence, supporting evidence and evidence prohibited from automatic adoption, and output the evidence set marked with validity, duplicate group and conflict group; S108, Calculate the matching score between the evidence unit and the paragraph slot and perform admission; S109, construct a generation context for each slot and limit the scope of evidence for the generation model; S110, execute the generation of constrained content; The rule template or large language model is called sequentially according to the syntax tree to generate content, and the fact coverage, prohibited expressions, length and citation integrity are verified; the set of slot content is output and the verification record is generated. S111, Combine slot contents and generate a DOCX document with a structured style. Based on the syntax tree, slot content, layout rules, and evidence mapping, paragraphs are grouped in node order, styles, numbering, attachments, signatures, and dates are bound, written into a DOCX package, and a draft document and an evidence mapping table are output. S112, parses DOCX direct formatting, style inheritance, numbering, and page setup to form a valid layout object; S113, Based on the syntax tree and rule package, generate validation issues and determine the risk level to fix them; S114: Perform transactional repair and re-verification on the identified verification issues, outputting a set of RepairTransaction, a set of HumanDecisions, and the re-verification results; and transfer content-related issues to manual confirmation. S115, Output delivery package, including official documents, evidence mapping table, verification report and repair record.

[0022] In the multi-source material arrangement and format closed-loop verification method based on official document syntax trees, in step S108, based on the syntax tree nodes and the set of evidence units, semantics, type, authority, timeliness, constraint fit, conflict and repetition factors are calculated to obtain the matching score (MatchScore) and compared with the node threshold. The matching score between the evidence and the paragraph slot is calculated and admission is performed. The set of interpolation mapping records (SlotMappingRecord) is output. When there is no qualified evidence in the required slot, an evidence missing (EVIDENCE_MISSING) mark is generated and the model is prohibited from supplementing facts.

[0023] In step S109, based on the input syntax tree nodes, approved mappings and task constraints, the allowed evidence, required elements, fixed terms, prohibited expressions, tone, length and output structure of the current slot are summarized, and a generation context is constructed for each slot to limit the evidence range of the generation model; when the context contains unresolved conflict evidence, the slot is marked as pending confirmation.

[0024] In step S112, based on the draft document, the OOXML body, styles, numbering, settings, sections, headers and footers, and related components are parsed, the inherited valid formats and reference relationships are calculated, and a valid layout object (DocumentLayoutObject) is output. In step S113, based on the valid layout object, syntax tree, and resolved rule set, the required nodes, order, evidence citations, heading levels, numbering, attachments, signatures, dates, fonts, font sizes, line spacing, indentation, and page settings are checked to generate a set of validation issues and determine the risks; if a rule cannot be parsed, the rule error is retained and transferred to manual confirmation.

[0025] In step S114, based on the set of ValidationIssue, the repair strategy, and the human decision, snapshots are created for automatically compliant issues and repairs are performed. Issues pending confirmation only enter the repair process after the human decision is approved; if the human decision is rejected or no decision is made, manual intervention is initiated. After repair, steps S112 and S113 are resumed. If the original issue disappears and there are no new issues with higher risk, it is marked as RECHECKED; otherwise, it is rolled back. The process stops when the maximum number of rounds is reached. Then, the set of RepairTransaction, the set of HumanDecision, and the re-inspection results are output.

[0026] In step S115, based on the input final document, evidence mapping, verification issues, remediation transactions, and human decisions, the rule version, evidence source, adoption relationship, issue status, remediation trajectory, and human decisions are solidified; the compliance status is marked as COMPLIANT only when an unresolved issue is established, otherwise it is marked as MANUAL_REQUIRED; then, a document delivery package is output; when compliance is completed, it includes a compliance DOCX, evidence mapping table, verification report, and remediation record; when human intervention is terminated, it includes drafts and a list of human interventions; if there are any unresolved issues, the maximum remediation round is reached, or rollback fails, it must not be marked as a compliance document.

[0027] Example 3: See Figure 8 This invention relates to a method for multi-source material arrangement and format closed-loop verification based on official document syntax trees, comprising the following steps, each of which can be executed on the same server or collaboratively by services connected via a network.

[0028] S101 Receiving and Standardizing Official Documents Input: Document type, recipient, subject matter, multiple source materials, organization identifier, and special requirements. Processing logic: Generate task_id, unify character encoding, time, and file identifier, and confirm that the output is DOCX; if the file type is not specified, the file type recognition module will determine it. Output: DocumentTaskContext Abnormal conditions: If the input file cannot be parsed, record the failed footage and continue processing other footage; if key parameters are missing, request their supplementation. S102 Identifying document type and textual relationship Input: DocumentTaskContext Processing logic: Determine whether it is a notification, request for instructions, report, letter, or minutes based on the explicit document type, recipient, subject, and common structure, and identify upward, downward, or parallel relationships. Output: DocumentTypeDecision Abnormal condition: When the scores of multiple document types are close, the automatic selection will stop and manual confirmation will be requested. S103 Parse and merge rule packages Input: Document type, organization identifier, task date, task constraints, and rule base. Processing logic: For filtering rule validity periods, first verify the enforceable rules that cannot be overridden, then select the first defined value for each rule attribute in the order of task constraints, unit coverage, document type rules, and system default rules. Output: Sets of ResolvedRuleSet and RuleConflict Abnormal conditions: When there is a conflict between mandatory rules, task constraints violate mandatory rules, or no unique selection can be made using rules at the same level, manual confirmation will be required. S104 Constructing an executable document syntax tree Input: ResolvedRuleSet and task constraints Processing logic: Generate nodes such as title, addressee, introduction, subject, requirements, attachments, signature, and date, and bind them with order, base number, conditions, evidence, and format constraints. Output: DocumentSyntaxTree Abnormal condition: If the required node rule is incomplete, output RULE_INCOMPLETE and terminate automatic generation. S105 analyzes multi-source materials Inputs: policies, regulations, minutes, historical documents, business data, and attachments. Processing logic: Parse the file structure, paragraphs, tables, version, time, and source location, and segment the candidate content into factual or evidence fragments. Output: CandidateMaterialUnit collection Abnormal conditions: Encrypted, corrupted, or unsupported file generation of SOURCE_UNREADABLE record. S106 Generate Fact-Level Evidence Units Input: CandidateMaterialUnit collection Processing logic: Extract the fact subject, predicate, fact value, topic, evidence type, authority level, validity period, and scope of application, and generate a content hash. Output: Collection of MaterialEvidenceUnit Abnormal condition: Fragments whose factual structure cannot be determined are retained as low-structured evidence but must not be automatically moved to slots requiring structured facts. S107 performs deduplication, timeliness, and conflict handling. Input: Set of evidence units Processing logic: Group evidence by content hash and fact triples, detect expired and conflicting evidence, and determine the master evidence, supporting evidence, and evidence prohibited from automatic adoption. Output: A set of evidence labeled with validity, duplicate groups, and conflict groups. Abnormal conditions: When conflicts cannot be resolved by authority, version, and time, manual confirmation will be required. S108 Computational evidence matching and slot admission Input: syntax tree nodes and evidence set Processing logic: Calculate semantics, type, authority, timeliness, constraint fit, conflict, and duplication factors to obtain the MatchScore and compare it with the node threshold. Output: SlotMappingRecord collection Abnormal condition: When there is no valid evidence for a required slot, an EVIDENCE_MISSING is generated and model reconstruction is prohibited. S109 Constructing a slot generation context Input: syntax tree nodes, approved mappings, and task constraints Processing logic: Summarize the allowed evidence, required elements, fixed terms, prohibited expressions, tone, length, and output structure for the current slot. Output: GenerationContext collection Exception condition: Mark the slot as PENDING_CONFIRMATION when the context contains evidence of unresolved conflicts. S110 Execute Constrained Content Generation Input: GenerationContext collection Processing logic: The system calls rule templates or the large language model slot by slot in the syntax tree to generate content, and verifies fact coverage, prohibited expressions, length, and citation integrity. Output: SlotContent set and generated verification records Abnormal conditions: If retrying within the same evidence range still fails to meet the constraints, manual modification will be required. S111 Combine content and generate DOCX Input: syntax tree, SlotContent, layout rules, and evidence map Processing logic: Combine paragraphs according to node order, bind styles, numbering, attachments, signatures, and dates, and write them into a DOCX package. Output: DraftDocument and EvidenceMappingTable Abnormal conditions: If the node order or the reference target is missing, the official version will not be output and DOCUMENT_BUILD_FAILED will be generated. S112 Analyze the effective format of DOCX Input: DraftDocument Processing logic: Parse the OOXML body, styles, numbering, settings, sections, headers, footers, and related components; calculate the valid formatting and referencing relationships after inheritance. Output: DocumentLayoutObject Abnormal conditions: When OOXML relationships are broken or components are missing, mark PACKAGE_INVALID and disable automatic repair. S113 Generate verification issues and determine risks Input: DocumentLayoutObject, syntax tree, and ResolvedRuleSet Processing logic: Check required fields, order, evidence citations, heading level, numbering, attachments, signature, date, font, font size, line spacing, indentation, and page setup; generate questions and calculate R0-R3. Output: Collection of ValidationIssue Abnormal conditions: If a rule cannot be parsed, retain the rule error and transfer it to manual confirmation. S114 Execute the repair transaction and re-verify. Input: ValidationIssue set, remediation strategy, and HumanDecision Processing logic: A snapshot is created and repair is performed for AUTO_ELIGIBLE issues; PENDING_CONFIRMATION issues only enter repair mode after HumanDecision is APPROVED, otherwise it transitions to MANUAL_REQUIRED if it is REJECTED or undecided. After repair, it re-enters S112 and S113; if the original issue disappears and there are no new issues with higher risk, it is marked as RECHECKED, otherwise it rolls back; it stops when the maximum number of rounds is reached. Output: RepairTransaction set, HumanDecision set, and re-examination results. Abnormal conditions: The status changes to MANUAL_REQUIRED when rollback fails, manual decision is not completed, R3 issue is not approved, or a higher-risk issue arises. S115 Output Delivery Package Inputs: Final document, evidence map, validation issues, repair transactions, and HumanDecision. Processing logic: Consolidate rule version, evidence source, adoption relationship, issue status, remediation path, and manual decision; mark compliance_status as COMPLIANT only when NoUnresolvedIssue is true, otherwise mark it as MANUAL_REQUIRED. Output: DocumentDeliveryPackage; upon completion of compliance, it includes a compliance DOCX, evidence mapping table, verification report, and remediation record; upon manual termination, it includes drafts and a manual processing list. Abnormal conditions: Documents must not be marked as compliant if there are any unresolved issues, the maximum number of remediation rounds has been reached, or a rollback has failed. Example 4: Figure 1The diagram illustrates the multi-source material arrangement and format closed-loop verification system based on official document syntax trees, as described in this invention. The system adopts a layered architecture of "rule parsing—evidence processing—slot generation—document parsing—verification and repair," comprising a task access module, document type identification module, rule package management module, syntax tree construction module, material parsing module, evidence management module, slot matching module, constraint context module, content generation module, DOCX generation module, valid format parsing module, format verification module, transaction repair module, manual confirmation module, and result output module. Each module is associated with the rule version, syntax tree, evidence unit, mapping record, generated result, verification problem, and repair transaction of the same task through DocumentTaskContext. Task access module: Establishes task identifiers and standardizes input parameters, permissions, and output requirements; Document type identification module: determines candidate document types, writing direction, and applicable structure, and requests confirmation when confidence is insufficient; Rule package management module: First, it verifies the mandatory rules that cannot be overridden, and then it parses the version, overriding and conflict of each attribute in the order of task, unit, document type and default rule; Syntax tree building module: Generates a node tree containing order, cardinality, condition, evidence, and format constraints; Material analysis module: Analyzes file structure, paragraph position, version and time, and segments candidate facts; Evidence management module: Performs fact-level standardization, deduplication, timeliness checks, authority calculation, and conflict grouping; Slot matching module: Calculates the overall matching score, performs admission, sorts, and records the reasons for exclusion; Constraint Context Module: Generates slot-allowed evidence, fixed terms, prohibited expressions, length, and output structure; Content generation module: calls rule templates or large language models to generate content within a single slot and performs post-generation constraint checks; DOCX generation module: Combines content according to node order, binds styles and numbering, and writes it into DOCX; Effective layout parsing module: Parses OOXML style inheritance, direct formatting, numbering, tables, sections, headers and footers, and page setup; Format validation module: Detects content structure, referencing relationships, and layout issues, and locates the source of the rules; Repair Transaction Module: Creates snapshots based on risk, performs repairs, records the scope of impact, re-checks, and rolls back on failure; Manual confirmation module: Displays the original text, evidence, rules, and candidate actions, and receives approval, rejection, or replacement instructions; Results output module: Generates archiveable text, evidence mapping table, verification report and repair record; Each module is associated with the rule version, syntax tree, evidence unit, mapping record, generated result, verification problem and repair transaction of the same task through the DocumentTaskContext.

[0029] The main functions of the module and its main input-output relationships are shown in Table 1 below:

[0030] The logical relationships between the functional modules are as follows: the task access module sends standardized tasks to the document identification module; the rule package management module parses the rules based on the document type, unit, and task date; the syntax tree construction module outputs node constraints; the material parsing and evidence management module outputs the evidence set; the slot matching and constraint context module limits the input for the content generation module; the output of the DOCX generation module enters the valid layout parsing and format verification; and the repair task module sends the document back for parsing and verification after automatic repair or manual confirmation until the termination conditions are met.

[0031] Figure 2 This invention demonstrates a method for processing official documents based on a document syntax tree, involving multi-source material arrangement and closed-loop format verification, and a closed-loop link formed by document generation and format repair during the document review and verification process.

[0032] This invention presents a multi-source material arrangement and format closed-loop verification method based on official document syntax trees. Instead of simply applying static templates, handing all materials over to a generation model, or performing a format replacement after generation, it establishes the following inseparable machine processing chain: receiving document type, issuing object, subject matter, multi-source materials, and task constraints; identifying the document type and parsing the applicable rule package and its version and priority; constructing an official document syntax tree containing paragraph slots and execution constraints; parsing multi-source materials into fact-level or policy-based evidence units; performing evidence deduplication, timeliness checks, conflict grouping, and authority level calculation; calculating the matching score between evidence units and paragraph slots and performing admission; constructing a generation context for each slot and limiting the evidence scope of the generation model; combining slot outputs and generating a DOCX document with a structured style; parsing the DOCX direct format, style inheritance, numbering, and page settings to form a valid layout object; generating verification questions based on the rule package and determining the repair risk level; performing transactional repair on deterministic issues and transferring content-related issues to manual confirmation; re-parsing and verifying the repair results, rolling back or terminating upon failure; and outputting the official document, evidence mapping table, verification report, and repair record.

[0033] The present invention relates to a method and system for processing official documents based on a document syntax tree, which involves multi-source material arrangement and format closed-loop verification. The rule packages, document syntax trees, and version inheritance are as follows: The rules are sourced from national official document format standards, document processing rules, and organization-defined templates. Instead of hardcoding the rules into the generation prompts, the system encapsulates them as RulePackages and filters valid versions by task date.

[0034] The rule priorities are as follows: 1. Mandatory rules and regulations (hard constraints that cannot be overridden) 2. Constraints of this task 3. Unit Template Override Rules 4. Document Type Rules 5. System default rules The system first filters ineffective or expired rules by task date and verifies mandatory rules as hard constraints that cannot be overridden by any lower-level rules. Without violating mandatory rules, for the same rule attribute p, the system selects the first defined and applicable value from left to right, following the order of task constraints, unit template overriding rules, document type rules, and system default rules. Rules at the same level acting on the same attribute that cannot be uniquely selected form a RuleConflict; mandatory rule conflicts or unresolved conflicts at the same level are submitted for manual confirmation.

[0035] MandatoryRule = HardConstraint; EffectiveConfigurableRule(p) =FirstDefined(TaskConstraint(p), OrganizationOverride(p), DocumentTypeRule(p),DefaultRule(p)).

[0036] The initial rule package covers notifications, requests for instructions, reports, letters, and minutes. DocumentSyntaxTree nodes record not only paragraph names but also parent-child relationships, order, cardinality, conditional expressions, evidence requirements, fixed expressions, prohibited expressions, length, and formatting rules. Figure 3 The diagram shown is a syntax tree and rule inheritance diagram for official documents.

[0037] To enable unified calculation and tracking of rules, materials, generation, verification, and repair processes, this invention defines the following core data objects. The core data objects and their relationships are shown in the table below:

[0038]

[0039] After DocumentTaskContext determines the document type using DocumentTypeDecision, it selects one or more RulePackages. Rule parsing generates a ResolvedRuleSet, and attributes that cannot be uniquely selected form a RuleConflict. The ResolvedRuleSet constructs a DocumentSyntaxTree. Multi-source materials are first divided into a CandidateMaterialUnit set, and then standardized into a MaterialEvidenceUnit set. Each evidence unit establishes an interpretable mapping with the syntax tree node through SlotMappingRecord. Approved evidence is loaded into GenerationContext and a SlotContent is generated. The generated result is written to DOCX and parsed into a DocumentLayoutObject. Rule validation generates a ValidationIssue. Repairable issues form a RepairTransaction, and high-risk issues form a HumanDecision. Finally, DocumentDeliveryPackage encapsulates the document status, compliance conclusions, evidence, and repair records.

[0040] Figure 4 The diagram shows the mapping between material evidence units and paragraph slots. This invention, a method for processing official documents based on a document syntax tree, involves multi-source material arrangement and format closed-loop verification. The process of multi-source material evidence processing and slot matching includes: The material analysis module retains the source file, source location, version, release date, effective date, and scope of application, and converts text fragments into fact-level or policy-based MaterialEvidenceUnits. Low-structured fragments can retain the original text, but should not be automatically moved to slots requiring structured facts.

[0041] 1. Evidence deduplication, statute of limitations, and conflicts When two pieces of evidence share the same factual subject and predicate but their factual values, validity periods, or scope of application are incompatible, a conflict group is established. The system sequentially compares mandatory rule associations, authority levels, versions, effective dates, and publication dates; if a determination still cannot be made, automatic generation is prohibited, and the case is transferred to manual confirmation.

[0042] Conflict(e1,e2)=SameSubjectAndPredicate ANDIncompatibleObjectOrValidity 2. Slot matching scoring and admission Where 'e' represents the evidence unit and 'n' represents the syntax tree node; weights, admission thresholds, and minimum authority levels are configured by the rule package. If a required slot lacks valid evidence, an EVIDENCE_MISSING issue is generated; the generation engine is not allowed to fabricate facts. For duplicate evidence of the same fact, only the highest priority evidence is retained as the primary evidence, and the remaining records are considered supporting evidence.

[0043] MatchScore(e,n)=w1*SemanticSimilarity+w2*EvidenceTypeFit+w3*AuthorityScore+w4*FreshnessScore+w5*SlotConstraintFit-w6*ConflictPenalty-w7*DuplicatePenalty. Figure 5 The diagram shows the process of generating constrained content. The slot content generation process under the control of the rule engine includes: The generated model only obtains approved evidence and constraints for the current slot and does not accept unapproved material. After output, it performs structure, fact coverage, prohibited expressions, length, and citation integrity checks; if it fails, it can be retried within the same evidence range, and after exceeding the number of attempts, it will be handled manually.

[0044] GenerationContext(n)=AllowedEvidence(n)+RequiredElements(n)+LanguageRules(n)+OutputSchema(n). The rule engine is responsible for structure, evidence scope, and output constraints, while the large language model serves only as an optional slot generation engine. When required evidence is missing or conflicts remain unresolved, the model must not fabricate factual information based on general knowledge.

[0045] Figure 6The figure shows a flowchart of DOCX valid layout parsing. The DOCX valid layout parsing process: where x represents a single format attribute to be parsed, and FirstDefined represents selecting the first explicitly defined attribute value in left-to-right order. For paragraph attributes, parse the direct paragraph format, the current paragraph style, the basedOn base style chain of this style, and the document default value in sequence; for text run attributes, parse the direct run format, the current character style, the text attributes in the paragraph style, the corresponding basedOn base style chain, and the document default value in sequence. The system generates parsing issues for cyclic or missing style references; numbering attributes, table style attributes, and section page attributes are calculated according to the merging rules of the corresponding OOXML parts respectively. The system parses document.xml, styles.xml, numbering.xml, settings.xml and the relationships of sections, headers and footers, and the verification is based on the effective format calculated per attribute, rather than only based on the direct format or the text displayed by the editor.

[0046] EffectiveProperty(x)=FirstDefined(DirectFormat(x),CurrentStyleProperty(x), BasedOnStyleChainProperty(x),DocumentDefaultProperty(x)). DocumentLayoutObject uniformly records element positions, style sources, inheritance chains, effective attributes, numbering relationships, table geometry, attachment relationships, and section attributes, so that the verification module can locate specific document parts and elements.

[0047] Figure 7 Verification and repair state machine diagram. During the process of verification issues, risk grading and repair state machine, each influencing factor is normalized according to the range set by the rule package, where a, b, c, d and e are non-negative weights; Irreversibility represents the degree of difficulty in recovery after a repair failure. The rule package is configured with three thresholds satisfying theta1<theta2<theta3: a RiskScore less than theta1 is R0, greater than or equal to theta1 and less than theta2 is R1, greater than or equal to theta2 and less than theta3 is R2, and greater than or equal to theta3 is R3. Fact replacement, unresolved evidence conflicts, semantic rewriting and mandatory rule conflicts are not affected by score reduction, and directly trigger the R3 hard threshold. R0 is a local display attribute deviation; R1 is a numbering, date or annotation issue with a determined scope of effect, rollback capability and no change to fact semantics; R2 is a cross-element structure or reference issue; R3 is a content, fact or mandatory rule issue.

[0048] RiskScore = a*ContentImpact + b*StructuralImpact + c*ReferenceImpact+ d*Irreversibility + e*RulePriority

[0049] Before remediation, a snapshot and hash of the affected elements are generated. AUTO_ELIGIBLE issues can directly enter REPAIRING; PENDING_CONFIRMATION issues can only enter REPAIRING after the HumanDecision record is APPROVED, and will transition to MANUAL_REQUIRED if the record is REJECTED or no decision is made. After remediation, the entire impact scope is re-analyzed; if the original issue disappears and no new higher-level issues arise, the status is RECHECKED; otherwise, a snapshot is restored and marked ROLLED_BACK, transitioning to MANUAL_REQUIRED if the retry limit is reached or the rollback fails.

[0050] DETECTED -> AUTO_ELIGIBLE / PENDING_CONFIRMATION; AUTO_ELIGIBLE ->REPAIRING -> REPAIRED -> RECHECKED; PENDING_CONFIRMATION -> APPROVED / REJECTED; APPROVED -> REPAIRING; REJECTED -> MANUAL_REQUIRED; failure ->ROLLED_BACK / MANUAL_REQUIRED The system terminates normally with a CompliantComplete status and allows the document to be marked as compliant only when there are no unresolved issues. If the maximum number of remediation rounds is reached, there are still incomplete manual decisions, or rollback fails, the automatic loop terminates with a SuspendForManual status, outputting drafts and a list of manual actions; these must not be marked as compliant documents. Stop only indicates that the loop has stopped; the results must be further distinguished between CompliantComplete and SuspendForManual to avoid mistaking manual termination for compliance completion.

[0051] This invention relates to a method and system for multi-source material arrangement and format closed-loop verification based on official document syntax trees. It can be implemented through software programs deployed on system servers, cloud computing platforms, organizational office platforms, or other computing devices. The document processing method provided by this invention allows each step to be executed on the same server or collaboratively by services connected via a network. Its form and corresponding layout can be an electronic device including a processor and memory, and a computer-readable storage medium storing the computer program that enables the processor to execute the above method.

[0052] Examples 5-7 below are practical application cases of the multi-source material arrangement and format closed-loop verification method based on official document syntax tree of the present invention.

[0053] Example 5: Generating a working report notification based on multi-source evidence The task requires generating a notification regarding the reporting of specific work progress. The processing procedure is the same as in Example 3.

[0054] Input materials include current policy documents P2, repealed old policy documents P1, meeting minutes M1, historical notices H1, and contact information U1.

[0055] The system identifies the document type as a notification in S102, and selects the notification rule package and unit template overriding rule in S103.

[0056] S104 generates a syntax tree containing a title, addressee, basis for issuance, subject matter, requirements for submission, timeline, submission method, contact information, attachments, signature, and date. The basis for issuance node requires policy-based evidence with an authority level no lower than the rule threshold; the timeline requires meeting decisions or task input evidence; and the contact information allows users to supplement information.

[0057] S105 to S107 resolve P1 and P2 as different versions of the same policy topic.

[0058] P1 was marked as EXPIRED because its expiration time was earlier than the task date, and P2 was identified as the primary evidence. The submission deadline in M1 and the old deadline in H1 constituted a conflict group. The system selected M1 based on the release time of the meeting minutes and the scope of the task. H1 was only used for language style reference.

[0059] S108 calculates the MatchScore for P2 and the posting slot, M1 and the time node slot, and U1 and the contact information slot, respectively. The example weights and thresholds used to illustrate the calculation process are from the current rule package configuration and do not represent production test metrics. Approved evidence forms a SlotMappingRecord, and the reasons for exclusion for P1 and H1 are retained in the mapping table.

[0060] S109 to S110 ensure that the generated model can only access P2 in the publication basis slot and M1 in the time node slot. The model output is written to the corresponding node after being checked for fixed terms, fact coverage, and prohibited expressions. S111 generates a DOCX and records the mapping from each factual statement in the text to the original evidence location.

[0061] S112 to S114 detected that some paragraph font sizes and indentations did not conform to the unit template, and were judged as R0 issues affecting only local display attributes; the spacing of second-level numbering instances, date representation, and attachment annotations were determined non-semantic issues, and were judged as R1. The system automatically repaired and re-checked each issue; only after all issues disappeared and NoUnresolvedIssue was established, did S115 mark the delivery package as COMPLIANT and output the notification text, evidence mapping table, verification report, and repair record.

[0062] Example 6: Generate a request and forward content-related issues to manual confirmation. The task requires generating a request for instructions based on the project plan, budget description, and meeting minutes. The system constructs a request syntax tree, which must include at least the addressee, reason for the request, policy or factual basis, a single, clearly defined request item, a feasibility statement, a closing statement, signature, and date. Evidence analysis reveals that the project plan contains two parallel approval items, while the request rules require one item per document; the amount in the budget description does not match the amount recorded in the meeting minutes. Both issues involve fact selection and semantic structure, and the system generates the REQUEST_SCOPE_CONFLICT and EVIDENCE_CONFLICT issues respectively.

[0063] The slot matching module still allows selecting conflict-free evidence for the reason for the request and the feasibility statement, but the request item slot is marked as PENDING_CONFIRMATION. The generated model cannot merge two items or manually select amounts; it only generates slot drafts that are not affected by conflicts.

[0064] The manual confirmation module displays two items, two sets of amounts, source location, version time, and rule basis to the user. After the user selects a single item and confirms the budget data, the system generates a HumanDecision with the action APPROVED, updates the evidence status and mapping record, and after the PENDING_CONFIRMATION issue enters the APPROVED state, it continues to generate the request item and feasibility statement; if the user rejects it or does not make a decision, it is converted to MANUAL_REQUIRED.

[0065] The format verification stage can automatically correct the format of titles, addressees, paragraph indentation, and closing remarks. However, the selection process before and after manual confirmation, the source of evidence, and the modification actions are all retained in the delivery package, thereby preventing the automatic generation system from making unauditable content decisions when there is a conflict of evidence.

[0066] Example 7: DOCX Effective Format Analysis and Closed-Loop Repair The input is a pre-generated DOCX document. The main body of the document displays the specified font size, but some paragraphs have their paragraph styles overridden by direct formatting; the second-level numbering references the wrong abstract numbering definition; attachment descriptions exist, but the main body does not reference the attachments; and the closing date uses an inconsistent format.

[0067] The effective format parsing module reads document.xml, styles.xml, and numbering.xml, calling FirstDefined for each format attribute. Paragraph attributes are parsed sequentially, including direct formatting, the current paragraph style, the basedOn base style chain, and the document default value. Text attributes further distinguish between text attributes in character styles and paragraph styles. Numbering attributes are processed according to the independent merging rules of numbering.xml. This identifies font size overlay issues that cannot be detected by simply checking style names and maps numbering instances to the corresponding abstract numbering levels.

[0068] The validation module generates issues related to font overlay, numbering definitions, attachment references, and date formatting. Font, numbering, and date are classified as R1; attachment reference completion involves the text structure and is classified as R2. The repair module records the affected paragraphs, the original XML summary, and the repair parameters, and then performs style cleanup, numbering relationship correction, date unification, and attachment reference insertion.

[0069] After the repair is complete, the system re-parses the document. If the insertion of attachment references causes a change in the subsequent numbering hierarchy, a new structural problem is generated during the re-check. The transaction module restores the snapshot before the repair and transfers the attachment problem to manual processing. If all problems disappear, the transaction status is updated to RECHECKED, and it is further marked as COMPLIANT_COMPLETED only when NoUnresolvedIssue is true.

[0070] This embodiment illustrates that the validation object is the valid format after OOXML inheritance calculation, and the repair process has snapshot, scope of impact, re-check and rollback, rather than performing untraceable string or format replacements on the document.

[0071] In the multi-source material arrangement and format closed-loop verification method of this invention, the document syntax tree can be stored in a memory tree, JSON, domain-specific language, or graph database, as long as the nodes can express order, conditions, evidence, and format constraints. Semantic relevance can be calculated by keyword model, vector model, cross-coding model, or rule model. Weights can be configured according to document type, unit, or slot. The content generation module can use a large language model, template engine, rule assembly engine, or a combination thereof. The large language model is not a necessary component, as long as the generation process is constrained by slot evidence and rules. Effective format parsing primarily uses DOCX and OOXML, but can also be extended to WPS, OFD, or other structured document formats that can be converted to a unified document object model. Rule packages, evidence units, and repair transactions can be stored in a relational database, document database, graph database, or memory cache.

Claims

1. A method for multi-source material arrangement and format closed-loop verification based on official document syntax trees, characterized in that, The process includes: Obtain official document task information and multi-source materials, determine the applicable official document rule set based on the official document task information, and construct an official document syntax tree based on the official document rule set. The official document syntax tree includes multiple nodes corresponding to the components of the official document, and each node is configured with paragraph slots and corresponding structural constraints, evidence constraints and layout constraints. The multi-source material is analyzed to generate multiple evidence units. Each evidence unit includes at least factual content and source location. Based on the matching relationship between the evidence units and paragraph slots, the evidence units that meet the evidence constraints are admitted into the corresponding paragraph slots to form a slot evidence mapping. Slot generation context is constructed based on the node constraints and admission evidence units corresponding to each paragraph slot. Slot content is generated using the content generation engine according to the document syntax tree. The content generation engine is restricted to using only the admission evidence units of the current paragraph slot. A DOCX document is generated based on the slot content and the corresponding layout constraints. The OOXML body part, style part, numbering part and section settings of the DOCX document are parsed. The effective layout of the document elements is determined according to the inheritance and overriding relationships of various format attributes. Based on the official document syntax tree, the official document rule set, the slot evidence mapping and the effective layout, a verification question containing the question location and risk level is generated. For verification issues that meet the conditions for automatic repair, a snapshot before repair is created and repair is performed. The repaired DOCX document is then re-parsed and verified for valid formatting. If the original verification issue disappears and no higher-risk verification issue arises, the repair result is retained; otherwise, a rollback is performed based on the snapshot before repair. For verification issues that do not meet the conditions for automatic repair, manual confirmation is required. If there are no unresolved verification issues, output the verified DOCX document, slot evidence mapping, and repair record; otherwise, output the document awaiting manual processing and the unresolved issues.

2. The method for multi-source material arrangement and format closed-loop verification based on official document syntax tree according to claim 1, characterized in that, Its implementation process specifically includes the following steps: S101, receiving and standardizing official documents; Receive document type, recipient, subject matter, multi-source materials, unit identifier, and task constraints; generate task_id; unify character encoding, time, and file identifier; and output the document task context. S102 identifies the document type and writing relationship, and parses the applicable rule package, its version, and priority; Based on the explicit document type, recipient, subject, and common structure, determine whether it is a notice, request for instructions, report, letter, or minutes, identify the upward, downward, or parallel relationship, perform document type determination, and output the document type determination. S103, parse and merge rule packets; Based on the input document type, unit identifier, task date, task constraints, and rule base, the validity period of rules is filtered, mandatory rules that cannot be overridden are first verified, and then the first defined value is selected for each rule attribute in the order of task constraints, unit overriding, document type rules, and system default rules to generate a set of resolved rules and a set of rule conflicts. S104, based on the resolved rule set and task constraints, constructs an executable document syntax tree containing paragraph slots and execution constraints, including generating nodes such as title, addressee, introduction, matters, requirements, attachments, signature and date, and binding order, cardinality, conditions, evidence and format constraints; S105, analyzes multi-source materials into fact-level or policy-based evidence units; Based on policies, regulations, minutes, historical documents, business data, and attachments, analyze the document structure, paragraphs, tables, versions, dates, and source locations, segment the candidate content into factual or evidence fragments, and output candidate material units; S106, Generate fact-level evidence units; Based on the candidate's material units, extract the fact subject, predicate, fact value, theme, evidence type, authority level, validity period and scope of application, and generate content hashes to generate a set of evidence units; S107, perform evidence deduplication, timeliness check, conflict grouping and authority level calculation; Based on the evidence unit set, group by content hash and fact triplet, detect expired and conflicting evidence, determine the main evidence, supporting evidence and evidence prohibited from automatic adoption, and output the evidence set marked with validity, duplicate group and conflict group; S108, Calculate the matching score between the evidence unit and the paragraph slot and perform admission; S109, construct a generation context for each slot and limit the scope of evidence for the generation model; S110, execute the generation of constrained content; The content is generated by calling the rule template or large language model slot by slot in the syntax tree order, and the fact coverage, prohibited expressions, length and citation integrity are verified; the slot content set and the verification record are output. S111, Combine slot contents and generate a DOCX document with a structured style. Based on the syntax tree, slot content, layout rules, and evidence mapping, paragraphs are combined in node order, styles, numbering, attachments, signatures, and dates are bound, written into a DOCX package, and a draft document and evidence mapping table are output. S112, parses DOCX direct formatting, style inheritance, numbering, and page setup to form a valid layout object; S113, Based on the syntax tree and rule package, generate validation issues and determine the risk level to fix them; S114: Perform transactional repair and re-verification on the identified verification issues, and output the recovery transaction set, the manual decision set, and the re-verification results. For content-related issues, transfer them to manual confirmation. S115, Output delivery package, including official documents, evidence mapping table, verification report and repair record.

3. The method for multi-source material arrangement and format closed-loop verification based on official document syntax tree according to claim 2, characterized in that: In step S108, based on the syntax tree nodes and the set of computational evidence units, semantics, type, authority, timeliness, constraint fit, conflict, and repetition factors are calculated to obtain a matching score and compare it with the node threshold. The matching score between the evidence and the paragraph slot is calculated and admission is performed. The set of interpolation mapping records is output. When there is no qualified evidence in the required slot, an evidence missing marker is generated and the model is prohibited from supplementing facts.

4. The method for multi-source material arrangement and format closed-loop verification based on official document syntax tree according to claim 2, characterized in that: In step S109, based on the input syntax tree nodes, approved mappings, and task constraints, the allowed evidence, required elements, fixed terms, prohibited expressions, tone, length, and output structure of the current slot are summarized. A generation context is constructed for each slot, and the evidence range of the generation model is restricted. If the context contains unresolved conflict evidence, the slot is marked as pending confirmation.

5. The method for multi-source material arrangement and format closed-loop verification based on official document syntax trees according to claim 2, 3 or 4, characterized in that: In step S112, based on the draft document, the OOXML body, styles, numbering, settings, sections, headers and footers, and relational components are parsed, the valid formatting and referencing relationships after inheritance are calculated, and the valid layout object is output.

6. The method for multi-source material arrangement and format closed-loop verification based on official document syntax tree according to claim 5, characterized in that: In step S113, based on the valid layout object, syntax tree, and resolved rule set, the required nodes, order, evidence citations, heading levels, numbering, attachments, signatures, dates, fonts, font sizes, line spacing, indentation, and page settings are checked to generate a set of validation issues and determine risks; if a rule cannot be parsed, the rule error is retained and transferred to manual confirmation.

7. The method for multi-source material arrangement and format closed-loop verification based on official document syntax tree according to claim 6, characterized in that: In step S114, based on the set of verification issues, the repair strategy, and the manual decision, a snapshot is created for issues that automatically meet the conditions and repair is performed; issues awaiting confirmation only enter the repair process after the manual decision is approved, and are transferred to manual intervention if they are not accepted or have not been decided. After repair, proceed to steps S112 and S113 again; Mark RECHECKED when the original problem disappears and there are no new problems with higher risk; otherwise, roll back; stop when the maximum number of rounds is reached. Then output the recovery transaction set, the human decision set, and the review results.

8. The method for multi-source material arrangement and format closed-loop verification based on official document syntax trees according to claims 2, 3, 4, 6 or 7, characterized in that: In step S115, based on the input final document, evidence mapping, verification issues, remediation transactions, and manual decisions, the rule version, evidence source, adoption relationship, issue status, remediation trajectory, and manual decisions are solidified; the compliance status is marked as COMPLIANT only when an unresolved issue is established, otherwise it is marked as MANUAL_REQUIRED. Then output the file delivery package; When compliance is completed, it includes a compliance DOCX, evidence mapping table, verification report, and remediation record. When manually suspended, it includes a draft and a manual processing list. Documents should not be marked as compliant if there are any unresolved issues, the maximum remediation round has been reached, or rollback has failed.

9. A multi-source material arrangement and format closed-loop verification system based on official document syntax tree, implementing the multi-source material arrangement and format closed-loop verification method according to any one of claims 1-8, adopting a layered architecture of "rule parsing—evidence processing—slot generation—document parsing—verification and repair", characterized in that: It includes a task access module, a document identification module, a rule package management module, a syntax tree construction module, a material parsing module, an evidence management module, a slot matching module, a constraint context module, a content generation module, a DOCX generation module, a valid format parsing module, a format validation module, a transaction repair module, a manual confirmation module, and a result output module. Task access module: Establishes task identifiers and standardizes input parameters, permissions, and output requirements; Document type identification module: determines candidate document types, writing direction, and applicable structure, and requests confirmation when confidence is insufficient; Rule package management module: First, it verifies the mandatory rules that cannot be overridden, and then it parses the version, overriding and conflict of each attribute in the order of task, unit, document type and default rule; Syntax tree building module: Generates a node tree containing order, cardinality, condition, evidence, and format constraints; Material analysis module: Analyzes file structure, paragraph position, version and time, and segments candidate facts; Evidence management module: Performs fact-level standardization, deduplication, timeliness checks, authority calculation, and conflict grouping; Slot matching module: Calculates the overall matching score, performs admission, sorts, and records the reasons for exclusion; Constraint Context Module: Generates slot-allowed evidence, fixed terms, prohibited expressions, length, and output structure; Content generation module: calls rule templates or large language models to generate content within a single slot and performs post-generation constraint checks; DOCX generation module: Combines content according to node order, binds styles and numbering, and writes it into DOCX; Effective layout parsing module: Parses OOXML style inheritance, direct formatting, numbering, tables, sections, headers and footers, and page setup; Format validation module: Detects content structure, referencing relationships, and layout issues, and locates the source of the rules; Repair Transaction Module: Creates snapshots based on risk, performs repairs, records the scope of impact, re-checks, and rolls back on failure; Manual confirmation module: Displays the original text, evidence, rules, and candidate actions, and receives approval, rejection, or replacement instructions; Results output module: Generates archiveable text, evidence mapping table, verification report and repair record; Each module is associated with the rule version, syntax tree, evidence unit, mapping record, generated result, verification problem, and repair transaction of the same task through the document task context.

10. The multi-source material arrangement and format closed-loop verification system based on official document syntax tree according to claim 9, characterized in that: The task access module sends standardized tasks to the document identification module; the rule package management module parses the rules based on the document type, unit, and task date; the syntax tree construction module outputs node constraints; the material parsing and evidence management module outputs the evidence set; and the slot matching and constraint context module limits the input for the content generation module. The output of the DOCX generation module is processed for valid layout parsing and format verification; the repair module sends the document back for parsing and verification after automatic repair or manual confirmation, until the termination conditions are met.

Images