Labor arbitration reasoning tree generation method and system fusing statutes and case chains

Abstract

The present application belongs to the technical field of data processing, and relates to a labor arbitration reasoning tree generation method and system based on the fusion of articles and case chains. The method comprises the following steps: obtaining a request type, article text, case chain text and rule engine structure constraints, generating predicate expressions and source anchoring records; loading rewriting rules matched with the request type, writing the predicate expressions into an equivalence graph and performing equation saturation to obtain proof element slots; generating article constraint hyperedges and case observation hyperedges, constructing a proof element constraint graph and determining absorbable links and conflict candidate links; constructing a formal concept lattice and determining a boundary slot set; generating a candidate reasoning tree in an adversarial manner; extracting a minimum conflict kernel and generating an isolation condition, performing maximum satisfiability constraint solving, and outputting a reasoning tree data file. The present application can improve the unified organization and source tracing capability of article constraints, case observations and conflict links.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method and system for generating labor arbitration reasoning trees by integrating legal provisions and case chains. Background Technology

[0002] Labor arbitration rule engines typically need to transform legal texts, case chain texts, and the rule engine structure into executable decision paths, enabling the system to invoke corresponding rules according to preset nodes and branches. Existing technologies often employ methods such as keyword extraction, case similarity retrieval, manual rule tree configuration, or single-path template generation to separately organize legal conditions and case facts before writing them into the rule base. While these methods can form basic rule invocation entry points, the lack of a unified intermediate representation between legal expressions, case facts, and the rule engine structure leads to the potential for duplicate modeling or incorrect merging when the same evidentiary element appears in different texts with different expressions.

[0003] In practice, legal texts typically emphasize necessary conditions, evidentiary conditions, and exceptional conditions, while case chain texts include factual descriptions, evidentiary materials, period expressions, monetary expressions, and existing directional labels. If only text similarity or keyword matching is used as the basis for connection, it's difficult to distinguish the differences in constraint attributes between legal conditions and case observations, and it's also difficult to determine whether a case chain can be absorbed into the rule path or should be isolated as a conflict link. Furthermore, when case chains with the same factual combination have different directional labels, existing rule tree generation methods often directly incorporate conflicting samples into the rule path or discard related case chains entirely, resulting in the inability to minimize and locate the source of conflict, and unclear boundaries of the generated rule paths. Consequently, the resulting inference tree data files, when entering the rule engine, may suffer from issues such as duplicate nodes, branch drift, unisolated conflicting conditions, and difficulty in tracing the output path. Summary of the Invention

[0004] This invention provides a method and system for generating labor arbitration reasoning trees by integrating legal provisions and case chains. It is used to at least solve the problem of how to generate a reasoning tree data file that meets the structural constraints of the rule engine and is traceable, under the condition that there are differences in expression and conflict in direction between legal provision texts and case chain texts.

[0005] In a first aspect, the present invention provides a method for generating a labor arbitration reasoning tree by integrating legal provisions and case chains, the method comprising: The process involves: acquiring the request type, legal text, case chain text, and rule engine structural constraints to obtain predicate expressions and source anchoring records; loading rewriting rules matching the request type; writing the predicate expressions into the equivalence graph and performing equality saturation based on the source anchoring records and rewriting rules to obtain proof element slots; generating legal constraint hyperedges and case observation hyperedges based on the proof element slots; constructing a proof element constraint graph and determining absorbable links and conflict candidate links; constructing a formal concept lattice based on absorbable links and determining the boundary slot set; generating candidate inference trees using a counterexample-driven approach based on legal constraint hyperedges, the boundary slot set, and case observation hyperedges; extracting the minimum conflict kernel and generating isolation conditions based on the conflict candidate links; solving the maximum satisfiable constraints of the candidate inference trees in conjunction with the rule engine structural constraints; and outputting the inference tree data file.

[0006] In one possible implementation, obtaining predicate expressions and source anchoring records includes: dividing the legal text and case chain text into text fragments, identifying factual expressions, evidentiary expressions, period expressions, monetary expressions, exception condition expressions, and directional label expressions from the text fragments, and associating the position identifier, source identifier, and original hash of the text fragments with the identified factual expressions, evidentiary expressions, period expressions, monetary expressions, exception condition expressions, and directional label expressions, respectively, to generate predicate expressions and source anchoring records.

[0007] In one possible implementation, the rewrite rules matching the request type are loaded, and the predicate expressions are written into the equivalence graph and equality saturation is performed based on the source anchor record and the rewrite rules to obtain proof element slots. This includes: determining the normalized expression of the predicate expression according to the rewrite rules; writing predicate expressions with the same normalized expression and satisfying the merging conditions limited by the source anchor record into the same equivalence class; determining the representative expression from the same equivalence class; and generating proof element slots based on the representative expression.

[0008] In one possible implementation, generating legal constraint hyperedges and case observation hyperedges based on proof element slots includes: determining necessary slots, evidence slots, exception slots, and output ports from proof element slots generated from predicate expressions corresponding to legal texts, and generating legal constraint hyperedges; determining fact slots, evidence slots, direction labels, and source anchoring records from proof element slots generated from predicate expressions corresponding to case chain texts, and generating case observation hyperedges.

[0009] In one possible implementation, a proof element constraint graph is constructed and absorbable links and conflict candidate links are determined, including: constructing a proof element constraint graph with proof element slots as graph nodes and legal constraint hyperedges and case observation hyperedges as hyperedges; determining the case observation hyperedge as an absorbable link when the fact slots and evidence slots in the case observation hyperedge cover the required slots in the legal constraint hyperedge and no exception slots are triggered; and determining the case observation hyperedge as a conflict candidate link when the case observation hyperedge lacks a required slot, triggers an exception slot, or has a direction label inconsistent with other case observation hyperedges with the same set of fact slots.

[0010] In one possible implementation, a formal concept lattice is constructed with absorbable links as objects and proof feature slots as attributes. The boundary slot set is determined based on the slot differences corresponding to different directional labels in the formal concept lattice. This includes: generating object attribute relationships based on the inclusion relationship between absorbable links and proof feature slots; constructing a formal concept lattice based on the object attribute relationships; determining the slot differences between concepts with different directional labels in the formal concept lattice; and determining the slots used to distinguish different directional labels as the boundary slot set.

[0011] In one possible implementation, a candidate inference tree is generated using a counterexample-driven approach based on the legal constraint hyperedge, the boundary slot set, and the case observation hyperedge. This includes: generating inference tree constraints based on the legal constraint hyperedge, generating candidate slot nodes based on the boundary slot set, and combining the inference tree constraints and candidate slot nodes into an initial inference tree; replaying the initial inference tree using the case observation hyperedge, and determining the case observation hyperedge as a counterexample sample if the replay path does not match the direction label of the case observation hyperedge; and adding, deleting, or replacing nodes or branches of the initial inference tree based on the counterexample sample to obtain the candidate inference tree.

[0012] In one possible implementation, extracting the minimum conflict kernel and generating isolation conditions based on the conflict candidate links includes: determining the proof element slots and legal constraint hyperedges involved in the conflict candidate links as the set of constraints to be tested, and performing satisfiability testing on the set of constraints to be tested; if the set of constraints to be tested is not satisfiable, extracting the minimum constraint subset from the set of constraints to be tested, wherein the minimum constraint subset makes the constraint solution of the candidate inference tree unsatisfiable, and the constraint subset obtained after deleting any constraint from the minimum constraint subset is satisfiable, determining the minimum constraint subset as the minimum conflict kernel, and generating isolation conditions based on the minimum conflict kernel.

[0013] In one possible implementation, the candidate inference tree is solved for maximum satisfiability constraints by combining the rule engine structural constraints, and the inference tree data file is output. This includes: encoding candidate nodes and candidate branches in the candidate inference tree as Boolean variables, using the rule engine structural constraints and isolation conditions as hard constraints, using the playback consistency of case observation hyperedges as soft constraints, solving for node sets and branch sets based on hard and soft constraints, and generating the inference tree data file based on the node sets and branch sets.

[0014] Secondly, this invention provides a labor arbitration reasoning tree generation system that integrates legal provisions and case chains, used to implement a method for generating labor arbitration reasoning trees that integrates legal provisions and case chains. The system includes: an acquisition module for acquiring request type, legal provision text, case chain text, and rule engine structural constraints, obtaining predicate expressions and source anchoring records; a saturation module for loading rewriting rules matching the request type, writing predicate expressions into an equivalence graph based on source anchoring records and rewriting rules, and performing equality saturation to obtain proof element slots; a graph construction module for generating legal provision constraint hyperedges and case observation hyperedges based on the proof element slots, constructing a proof element constraint graph, and determining absorbable links and conflict candidate links; a concept module for constructing formal concept lattices based on absorbable links and determining a set of boundary slots; and a generation module for generating candidate reasoning trees using a counterexample-driven approach based on legal provision constraint hyperedges, the set of boundary slots, and case observation hyperedges. The solution module is used to extract the minimum conflict kernel based on the candidate conflict links and generate isolation conditions. It combines the structural constraints of the rule engine to solve the maximum satisfiable constraints of the candidate inference tree and outputs the inference tree data file.

[0015] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows: By acquiring request type, legal text, case chain text, and rule engine structural constraints, and generating predicate expressions and source anchoring records, the binding between input text content and source location is achieved, enabling subsequent processing to merge expressions under traceable conditions. By loading rewriting rules matching the request type, and writing predicate expressions into the equivalence graph based on source anchoring records and rewriting rules, and performing equality saturation, synonymous or near-synonymous expressions in different texts can be unified into proof element slots, reducing the problem of repeated modeling or incorrect splitting of the same proof element. By generating legal constraint hyperedges and case observation hyperedges and constructing proof element constraint graphs, legal conditions and case chain facts can be connected in the same slot space, while distinguishing between absorbable links and conflict candidate links. By constructing formal concept lattices based on absorbable links and determining the set of boundary slots, the branching basis of candidate reasoning trees can be extracted from the slot differences corresponding to different directional labels. By generating candidate reasoning trees using a counterexample-driven approach, and extracting the minimum conflict kernel and generating isolation conditions based on conflict candidate links, directional label conflicts can be located and isolated. The inference tree data file is output by solving the maximum satisfiable constraints, so that the final result conforms to the rule engine structure constraints and preserves the correspondence between nodes, branches and source anchors. Attached Figure Description

[0016] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is a diagram showing the input text fragment and source anchoring record in an embodiment of the present invention; Figure 3 This is the equivalent diagram and proof element slot generation diagram in the embodiments of the present invention; Figure 4 This is the proof element constraint graph and the case observation hyperedge decision graph in the embodiments of the present invention; Figure 5 This is a diagram showing the formal concept grid and boundary slot set in an embodiment of the present invention; Figure 6 This is a diagram showing the counterexample-driven playback and candidate inference tree correction in an embodiment of the present invention. Figure 7 This is a diagram illustrating the solution for minimum conflicting kernel isolation and maximum satisfiable constraints in an embodiment of the present invention. Figure 8 This is a block diagram of the module composition of the system of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of one or more embodiments. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this invention.

[0018] In this embodiment, the fusion of legal provisions and case chains uses request type as the processing entry point and legal provision text, case chain text, and rule engine structural constraints as input data. The legal provision text provides the source of required slots, evidence slots, exception slots, and output ports; the case chain text provides the source of fact slots, evidence slots, period expressions, monetary expressions, direction label expressions, and source anchoring records; and the rule engine structural constraints limit the node format, branch format, and path connection relationships in the reasoning tree data file. After receiving the above input data, the executing entity segments the legal provision text and case chain text into text fragments, identifies fact expressions, evidence expressions, period expressions, monetary expressions, exception condition expressions, and direction label expressions, and associates the identified expressions with location identifiers, source identifiers, and original text hashes to form predicate expressions and source anchoring records. Thus, the legal provision text forms the constraint source, and the case chain text forms the observation source; both enter the same slot processing chain, providing a data foundation for subsequent equivalence graph writing, proof element slot generation, proof element constraint graph construction, and candidate reasoning tree generation.

[0019] like Figure 1 As shown, a method for generating a labor arbitration reasoning tree that integrates legal provisions and case chains includes the following processing steps.

[0020] In this implementation, the executing entity receives the request type, legal text, case chain text, and rule engine structural constraints, and writes these input objects into the same processing batch. The request type is used to limit the scope of labor arbitration matters addressed in subsequent processing, the legal text is used to provide the normative basis, the case chain text is used to provide the historical processing chain, and the rule engine structural constraints are used to limit the node format and branch format that can be read by the rule engine in subsequent inference tree data files.

[0021] The enforcement body segments the legal text and case chain text into text fragments, ensuring that each text fragment retains an independent location and source identifier. After segmenting the text fragments, the enforcement body identifies factual expressions, evidentiary expressions, period expressions, monetary expressions, exception condition expressions, and directional label expressions from the text fragments, and converts the identified expressions into predicate expressions.

[0022] The executing entity synchronously generates source anchor records. These records store the location identifier, source identifier, and original text hash of the text fragment, and associate this information with the predicate expression. The generated predicate expression enters the equivalence graph processing stage, with the source anchor records serving as the merging constraint and tracing basis for subsequent equality saturation.

[0023] In one embodiment, text segmentation is performed based on the natural paragraphs, clause numbers, reasoning paragraphs, and factual description paragraphs of the legal text and case chain text. For the legal text, the executing entity prioritizes segmentation according to the positions of clauses, paragraphs, items, sub-items, and punctuation marks such as periods and semicolons; for the case chain text, the executing entity prioritizes segmentation according to the paragraphs containing the requested matters, factual findings, evidence listing, reasoning content, and directional tags. After text segmentation, each text segment is configured with a location identifier and a source identifier. The location identifier records the paragraph number, character start and end positions, or page position of the text segment in the original text; the source identifier records whether the text segment originates from the legal text or the case chain text, and further records the text version, regional source, document number, or case number. The original text hash is generated based on the original character sequence of the text segment and is used to verify whether the text segment has been replaced or rewritten during subsequent processing.

[0024] The factual representation is used to record the actions, states, or factual relationships in labor arbitration matters, such as onboarding, offboarding, wage payment, termination of employment, and overtime arrangements. The evidentiary representation is used to record the types of materials or records that support the factual representation, such as employment contracts, pay slips, attendance records, termination notices, and chat logs. The period representation is used to record the time range in which the factual representation occurred or lasted, such as onboarding date, offboarding date, period of unpaid wages, and overtime period. The monetary representation is used to record wage amounts, compensation amounts, damages amounts, or other calculable amounts. The exception condition representation is used to record restrictive conditions that affect the scope of application of the factual representation, such as probationary period, serious misconduct, changes in objective circumstances, payment already made, and receipt already signed for. The directional label representation is used to record the directions of support, rejection, partial support, supplementary materials, or manual review that have appeared in the case chain text. These are not directly written into the reasoning tree data file as the final judgment result, but rather serve as input for subsequent case observation superedges and replay samples.

[0025] The executing entity can identify the aforementioned expressions using a combination of dictionary matching, syntactic rules, and sequence labeling. Dictionary matching handles consistently occurring labor arbitration terms, syntactic rules identify the combinational relationships between subjects, actions, periods, and amounts, and sequence labeling identifies factual and evidentiary expressions with indefinite boundaries. The identified expressions are not directly used as nodes in the reasoning tree; instead, they are first converted into predicate expressions. These predicate expressions preserve the associations between expression type, expression content, request type, location identifier, source identifier, and original text hash, ensuring that expressions identified within the same text fragment can be received by subsequent equivalence graphs.

[0026] When a text segment contains multiple expressions, the execution agent generates multiple predicate expressions, sharing the same position identifier, source identifier, and original text hash. If the expression boundaries in the text segment cannot be stably determined, the execution agent retains the expression boundary with the highest confidence and records the unadopted candidate boundaries as candidate content, preventing them from entering the subsequent equivalence graph processing stage. The confidence level can be determined based on dictionary hits, syntactic rule hits, and sequence label output consistency, used to constrain the admission of predicate expressions. The generated predicate expressions and source anchor records can simultaneously provide expression content and source constraints in subsequent equality saturation.

[0027] In this implementation, the executing entity receives the predicate expressions and source anchor records generated in the previous stage and loads rewriting rules that match the request type. The rewriting rules are used to convert predicate expressions with different forms but consistent semantics into normalized expressions, enabling factual expressions, evidence expressions, period expressions, monetary expressions, exception condition expressions, and direction label expressions to enter a unified data structure.

[0028] The executing entity writes predicate expressions into the equivalence graph. The equivalence graph is used to store the relationships between predicate expressions, normalized expressions, equivalence classes, and source anchor records. During the writing process, the executing entity generates normalized expressions according to the rewrite rules and checks the merging conditions through the source anchor records. Predicate expressions with the same normalized expressions and that meet the merging conditions are written into the same equivalence class; predicate expressions that do not meet the merging conditions are retained in different equivalence classes.

[0029] After equivalence saturation is achieved, the executing entity determines a representative expression from each equivalence class and generates proof element slots based on these representative expressions. These proof element slots then proceed to the subsequent generation stages of legal constraint hyperedges and case observation hyperedges.

[0030] In one embodiment, rewriting rules are loaded according to request type, and the expression type, expression content, and source constraints are used as the basis for rule matching. Rewriting rules can be used to handle synonymous expressions, differences in word order, differences in monetary units, differences in period format, and differences in evidence names. For example, salary slips, bank statements recording salary payments, and transfer records recording salary payments can be converted into the same normalized expression of evidence; termination of contract, termination of employment relationship, and termination of employment relationship can be converted into the same normalized expression of fact when the request type and semantic boundaries are consistent. Rewriting rules do not directly change the source anchor record; the source anchor record always retains the original text fragment's location identifier, source identifier, and original hash.

[0031] The equivalence graph can be implemented in terms of nodes and edges in its storage structure. Predicate expressions are written into the equivalence graph as nodes to be merged, normalized expressions serve as the basis for merging equivalence classes, and source anchor records serve as constraints before merging. When writing predicate expressions, the execution entity first checks if an equivalence class with the same normalized expression already exists in the equivalence graph. If no equivalence class with the same normalized expression exists, the execution entity creates a new equivalence class and writes the predicate expression, normalized expression, and source anchor record into the new equivalence class. If an equivalence class with the same normalized expression exists, the execution entity reads the source anchor records of the existing predicate expressions within the equivalence class and performs a merge condition check between the source anchor records of the newly added predicate expression and the existing source anchor records.

[0032] Merging conditions are used to restrict the write boundaries of equivalence classes. Merging conditions can be determined based on request type consistency, expression type consistency, source identifier traceability, original text hash integrity, and text fragment boundary stability. Request type consistency prevents the same textual expression under different labor arbitration request types from being incorrectly merged; expression type consistency prevents factual and evidentiary expressions from being written into the same equivalence class; source identifier traceability confirms that predicate expressions can be traced back to legal provisions or case chain text; original text hash integrity confirms that text fragments have not been replaced; and text fragment boundary stability confirms that the original semantic boundary corresponding to the normalized expression does not cross unrelated text fragments. When all the above merging conditions are met, the executing entity writes the new predicate expression into an existing equivalence class; if any merging condition is not met, the executing entity creates an independent equivalence class and retains the source anchoring record associated with the new predicate expression.

[0033] Equivalence saturation continues execution using the equivalence graph as the processing object. The execution entity iteratively reads the predicate expressions in the equivalence classes, uses rewrite rules to generate new normalized expressions, and checks whether the new normalized expressions can be merged with other equivalence classes. If the new normalized expressions meet the merging conditions, the execution entity merges the corresponding equivalence classes and simultaneously retains the source anchoring record associated with each predicate expression. If the rewrite rules can no longer generate new normalized expressions, or if none of the newly generated normalized expressions meet the merging conditions, equality saturation stops. When equality saturation stops, each equivalence class in the equivalence graph represents a set of predicate expressions that can be considered to have the same meaning as the proof element under the current request type and source constraints.

[0034] Representative expressions are determined from the same equivalence class. These representative expressions are used to generate proof element slots and are not used to cover source anchor records of other predicate expressions within the equivalence class. The determination of representative expressions can be based on the completeness of expression type, the completeness of source anchor records, the stability of normalized expressions, and the adaptability to subsequent rule engine structural constraints. Expression type completeness prioritizes predicate expressions that can clearly distinguish between factual expressions, evidentiary expressions, period expressions, monetary expressions, exception condition expressions, or direction label expressions; source anchor record completeness prioritizes predicate expressions with complete location identifiers, source identifiers, and original hashes; normalized expression stability prioritizes predicate expressions that maintain the same normalized expression after multiple rewrite rules are applied; and rule engine structural constraint adaptability prioritizes expressions that can serve as node or branch fields in the reasoning tree data file.

[0035] The executing entity generates proof element slots based on representative expressions. Each proof element slot stores the representative expression, expression type, request type, equivalence class identifier, and a set of source anchor records. The set of source anchor records consists of source anchor records for each predicate expression within the same equivalence class, used for source tracing during subsequent generation of legal provision constraint hyperedges and case observation hyperedges. After generating the proof element slots, the executing entity passes them to subsequent processing stages to distinguish between constraint relationships from legal provision texts and observation relationships from case chain texts.

[0036] In this implementation, the executing entity receives the proof element slots generated in the previous stage and reads the source anchoring records associated with the proof element slots. The proof element slots are divided into a set of slots corresponding to the legal text and a set of slots corresponding to the case chain text, according to their source.

[0037] The executing entity extracts slots that can limit the processing path from the proof element slots corresponding to the legal text, forming legal constraint hyperedges. The executing entity also extracts slots that can reflect the historical chain from the proof element slots corresponding to the case chain text, forming case observation hyperedges.

[0038] Legal constraint hyperedges and case observation hyperedges are jointly written into the proof element constraint graph. Proof element slots serve as graph nodes in the proof element constraint graph, while legal constraint hyperedges and case observation hyperedges serve as hyperedges connecting multiple graph nodes. After completing the construction of the proof element constraint graph, the executing entity determines absorbable links and conflict candidate links based on the relationships between fact slots, evidence slots, necessary slots, exception slots, and direction labels, and then passes the determination results to the formal concept lattice construction stage.

[0039] In one embodiment, when generating legal constraint hyperedges, the executing entity first reads the proof element slots generated from the predicate expressions corresponding to the legal text. These proof element slots retain the request type, representative expression, expression type, equivalence class identifier, and source anchor record set. Based on the expression type and representative expression, the executing entity divides the proof element slots into required slots, evidence slots, exception slots, and output ports. Required slots represent proof elements that must be covered by facts or evidence under a certain request type, such as the existence of an employment relationship, termination facts, wage payment facts, and the period range. Evidence slots represent the types of materials or record content that can support the required slots, such as employment contracts, payroll records, attendance records, and termination notices. Exception slots represent conditions that restrict or change the processing path, such as serious misconduct, payment already made, exceeding the period, and receipt confirmation. Output ports represent the path exits in subsequent inference tree data files, enabling the legal constraint hyperedges to establish connections with nodes and branches in the candidate inference tree.

[0040] When determining required slots, evidence slots, exception slots, and output ports, the executing entity does not rely solely on a single keyword. Instead, it considers the expression type, representative expression, and source anchoring record of the evidentiary element slot. If an evidentiary element slot originates from a text fragment in the legal provision containing obligatory, prohibitive, or conditional expressions, and the representative expression points to a necessary fact in the request type, that evidentiary element slot is written into a required slot. If an evidentiary element slot originates from a text fragment in the legal provision listing evidentiary materials, burden of proof, or content to be presented, that evidentiary element slot is written into an evidence slot. If an evidentiary element slot originates from a text fragment in the legal provision containing exceptions, provisos, limiting conditions, or defenses, that evidentiary element slot is written into an exception slot. The output port is determined based on the request type, the processing direction of the legal provision constraint hyperedge, and the rule engine structural constraints.

[0041] Legal constraint hyperedges store the combination relationships between required slots, evidence slots, exception slots, and output ports. A legal constraint hyperedge can connect multiple proof element slots simultaneously, enabling subsequent proof element constraint graphs to express relationships such as multiple slots being valid together, slots being missing, and exceptions being triggered. The executing entity writes a source anchor record set to each legal constraint hyperedge, and the source anchor record set comes from the proof element slots that participated in generating that legal constraint hyperedge. In this way, legal constraint hyperedges not only contain computable slot combinations but also allow backtracking to specific text fragments in the legal text during subsequent conflict candidate link extraction.

[0042] When generating case observation hyperedges, the executing entity reads the proof element slots generated from the predicate expressions corresponding to the case chain text, and determines the fact slots, evidence slots, direction labels, and source anchor records from them. Fact slots represent factual descriptions already appearing in the case chain text; evidence slots represent evidence materials appearing alongside factual descriptions in the case chain text; and direction labels represent existing processing directions in the case chain text. Source anchor records preserve the source positions of the fact slots, evidence slots, and direction labels in the case chain text. Case observation hyperedges are not directly written into the candidate reasoning tree, but rather serve as observation links in the proof element constraint graph, used for subsequent absorbable links, conflict candidate links, formal concept lattices, and the generation of candidate reasoning trees using a counterexample-driven approach.

[0043] In one embodiment, the executing entity constructs a proof element constraint graph using proof element slots as graph nodes and legal provision constraint hyperedges and case observation hyperedges as hyperedges. The proof element constraint graph is used to express the connection state of the constraint relationships formed by the legal provision text and the observation relationships formed by the case chain text within the same slot space. Graph nodes retain the equivalence class identifier and source anchor record set of the proof element slots, while hyperedges retain the set of connected graph nodes, source type, and direction label. The source type is used to distinguish whether the hyperedge originates from the legal provision text or the case chain text, and the direction label is only used as the historical link direction in the case observation hyperedge.

[0044] The executing entity reads each case observation hyperedge in the proof element constraint diagram and performs a coverage check between the fact slots and evidence slots in the case observation hyperedge and the required slots in the legal provision constraint hyperedge. The coverage check determines whether the fact slots and evidence slots in the case observation hyperedge satisfy the legal provision constraint hyperedge's requirement for required slots. Coverage relationships can be determined through consistency of equivalence class identifiers, representative expressions, or normalized expressions. If the fact slots and evidence slots cover the required slots, and the case observation hyperedge does not trigger any exceptional slots in the legal provision constraint hyperedge, the executing entity identifies the case observation hyperedge as an absorbable link. An absorbable link indicates that the case observation hyperedge can be accepted by the current legal provision constraint hyperedge and enters the boundary slot set determination process as an object of the formal concept lattice.

[0045] The executing entity also performs conflict candidate link checks on case observation superedges. If the fact slots and evidence slots in a case observation superedge do not cover the required slots in a legal constraint superedge, it indicates that the case observation superedge lacks the necessary content to support the current legal constraint superedge, and the case observation superedge is identified as a conflict candidate link. If a case observation superedge hits an exceptional slot in a legal constraint superedge, it indicates that although the case observation superedge has some fact slots or evidence slots, there are restrictions affecting path entry, and the case observation superedge is also identified as a conflict candidate link. If two case observation superedges have the same set of fact slots but different direction labels, the executing entity includes the aforementioned case observation superedges in the conflict candidate link range for subsequent minimum conflict kernel extraction.

[0046] When identifying other case observation hyperedges with the same set of fact slots, the executing agent uses the equivalence class identifier of the fact slots as the comparison criterion. If the set of fact slots is consistent, the executing agent compares the direction labels. If the direction labels are different, and the difference cannot be explained by the exception slot triggering relationship, the case observation hyperedge is retained as a conflict candidate link. This process prevents direction label conflicts from directly entering the boundary slot set and also avoids incomplete links in the case observation hyperedge being misused as positive samples in the candidate inference tree.

[0047] After the absorbable links and conflict candidate links are determined, the executing entity will pass the absorbable links to the formal concept lattice construction stage and the conflict candidate links to the minimum conflict kernel extraction stage. The proof element constraint graph will continue to retain the connection relationships between the legal constraint hyperedges, case observation hyperedges, graph nodes, and source anchor record sets, which will be used for subsequent replaying and constraint solving of candidate reasoning trees.

[0048] The executing entity receives the absorbable links and proof element slots determined in the previous stage, and reads the case observation hyperedges, direction labels, and source anchoring records associated with the absorbable links. Absorbable links are used to represent case observation hyperedges that can be accepted by legally binding hyperedges, and proof element slots are used to represent the expression of facts, evidence, periods, amounts, exceptions, and direction labels in a unified slot space.

[0049] The executing entity treats the absorbable link as an object and the proof element slot as an attribute, establishing an inclusion relationship between the absorbable link and the proof element slot. After the inclusion relationship forms an object attribute relationship, the executing entity constructs a formal concept lattice according to the object attribute relationship.

[0050] After the formal concept lattice is constructed, the executing entity reads concepts with different directional labels from the formal concept lattice, compares the slot differences between concepts, and writes the slots that can distinguish different directional labels into the boundary slot set. The boundary slot set is passed to the candidate reasoning tree generation stage to generate candidate slot nodes in the candidate reasoning tree.

[0051] In one embodiment, when constructing object attribute relationships, the executing entity uses a single absorbable link as an object record and a proof element slot as an attribute record. Each object record retains an absorbable link identifier, a case observation hyperedge identifier, a direction label, and a source anchor record set. Each attribute record retains an equivalence class identifier, a representative expression, an expression type, and a source anchor record set for the proof element slot. The executing entity reads the fact slot, evidence slot, period slot, amount slot, exception condition slot, and direction label slot associated with the absorbable link one by one, and determines whether the above slots appear in the proof element slot set. If the absorbable link contains a proof element slot, the executing entity writes an inclusion flag in the object attribute relationship; if the absorbable link does not contain a proof element slot, the executing entity does not write an inclusion flag. The object attribute relationship can be stored using a Boolean matrix, a key-value table, or a sparse index; the storage method does not change the inclusion meaning between the absorbable link and the proof element slot.

[0052] The executing entity constructs a formal concept lattice based on object attribute relationships. Each concept in the formal concept lattice is formed by a set of absorbable links and a set of proof element slots. The absorbable link set represents the scope of objects sharing the same set of proof element slots, and the proof element slot set represents the attribute scope shared by the aforementioned object scopes. The executing entity hierarchically connects concepts according to inclusion relationships, ensuring that upper-level concepts retain fewer proof element slots and a larger absorbable link scope, while lower-level concepts retain more proof element slots and a smaller absorbable link scope. Direction labels enter the formal concept lattice along with the absorbable links, but do not directly participate in hierarchical connections as ordinary attributes; instead, they are used for comparing differences between subsequent concepts.

[0053] During the construction of the formal concept lattice, the implementing entity needs to exclude absorbable links with missing source anchor records. Missing source anchor records indicate that the absorbable link cannot be traced back to a text fragment in the case chain text, resulting in a lack of source evidence for slot differences after entering the formal concept lattice. The implementing entity can also exclude absorbable links that only contain direction labels without fact slots or evidence slots, preventing direction labels from independently affecting the boundary slot set without being linked to fact or evidence slots. These exclusion conditions are set based on the completeness of source anchor records and slot type completeness, and are used to constrain the input range of object attribute relationships.

[0054] When determining the boundary slot set, the executing entity selects concepts with different direction labels for comparison within the formal concept lattice. During comparison, the executing entity reads the proof element slot groups of the two concepts, identifying slots that exist only in one concept, thus forming a slot difference. If the slot difference can reliably distinguish different direction labels, and the slot difference originates from a fact slot, evidence slot, period slot, amount slot, or exceptional condition slot, the executing entity writes the corresponding slot into the boundary slot set. If the slot difference originates only from a direction label slot, the executing entity does not write the corresponding slot into the boundary slot set separately, avoiding the candidate reasoning tree directly using historical direction labels as judgment nodes.

[0055] Each slot in the boundary slot set retains a source anchor record set and an associated direction label. The source anchor record set is used to trace the slot source during the candidate inference tree generation stage, and the associated direction label is used to determine whether the playback path is consistent with the case observation hyperedge when generating the candidate inference tree using the counterexample-driven approach. After the boundary slot set is determined, the executing entity outputs the boundary slot set to the candidate inference tree generation stage, where it participates in the candidate inference tree generation together with the legal constraint hyperedge and the case observation hyperedge.

[0056] In this implementation, the executing entity receives the legal constraint hyperedge, the boundary slot set, and the case observation hyperedge, and establishes the processing relationship between the three types of input objects. The legal constraint hyperedge provides the inference tree constraints, the boundary slot set provides candidate slot nodes, and the case observation hyperedge provides replay samples and direction labels.

[0057] The executing entity generates inference tree constraints based on the connection relationships between required slots, evidence slots, exception slots, and output ports in the legal constraint hyperedge. These inference tree constraints limit the connectable range of nodes and branches in the initial inference tree.

[0058] The executing entity converts the slots in the boundary slot set into candidate slot nodes and combines the inference tree constraints with the candidate slot nodes to form an initial inference tree. Case observation hyperedges are input into the initial inference tree for playback, forming playback paths. When the direction labels of the playback paths and case observation hyperedges are inconsistent, the case observation hyperedges are identified as counterexamples. Based on the counterexamples, the executing entity adds, deletes, or replaces nodes or branches in the initial inference tree to form candidate inference trees, and then passes the candidate inference trees to the minimum conflict kernel and maximum satisfiable constraint solving stage.

[0059] In one embodiment, when generating the inference tree constraints, the executing entity converts each legal provision constraint hyperedge into connectable constraints, required constraints, evidence constraints, exception constraints, and port constraints. Connectable constraints limit that slots within the same legal provision constraint hyperedge can form a continuous path in the initial inference tree. Required constraints limit that a required slot must be covered by a fact slot or evidence slot before entering a path. Evidence constraints limit the support relationship between evidence slots and fact slots, preventing individual evidence slots from branching off from fact slots. Exception constraints limit the check position of exception slots in the path, enabling exception slots to block paths that do not meet the conditions. Port constraints limit the path exit in the initial inference tree, allowing the playback path to be compared with the direction label of the case observation hyperedge.

[0060] When the executing entity generates candidate slot nodes based on the boundary slot set, it reads the expression type, equivalence class identifier, source anchoring record set, and association direction label for each slot in the boundary slot set. The expression type determines the node type of the candidate slot node in the initial inference tree. The equivalence class identifier determines whether a slot in the replay sample matches a candidate slot node. The source anchoring record set preserves the text source of the candidate slot node. The association direction label is only used for replay verification and is not directly used as a criterion for judging candidate slot nodes. After the candidate slot nodes are generated, the executing entity, according to the inference tree constraints, places the candidate slot nodes corresponding to the required slots at the beginning of the path, connects the candidate slot nodes corresponding to the evidence slots to the relevant fact slots, and connects the candidate slot nodes corresponding to the exception slots to locations that may trigger path blocking.

[0061] After the initial inference tree is formed, the executing entity uses case observation hyperedges as replay samples to perform path replay. Each case observation hyperedge carries a fact slot, an evidence slot, a direction label, and a source anchor record. The executing entity reads the set of slots in the case observation hyperedges according to the node order in the initial inference tree and determines whether a node is hit based on the equivalence class identifier or representative expression. After a node is hit, the executing entity continues to read the next node along the corresponding branch until it enters the output port or stops, thus forming the replay path. If a case observation hyperedge is missing a necessary slot, the replay path enters the direction of supplementary materials or manual review; if a case observation hyperedge triggers an exception slot, the replay path enters the direction corresponding to the exception condition; if a case observation hyperedge satisfies both the necessary slot and the evidence slot, the replay path enters the corresponding output port.

[0062] If the direction label of the replay path is inconsistent with the case observation hyperedge, the executing agent identifies the case observation hyperedge as a negative example. Negative examples are used to record the replay path, direction labels, hit nodes, missing nodes, triggering branches, and source anchoring records. The executing agent adjusts the nodes or branches of the initial inference tree based on the negative examples. If a negative example shows that a missing boundary slot causes inconsistent direction labels, the executing agent adds a candidate slot node corresponding to that boundary slot to the initial inference tree. If a negative example shows that a candidate slot node has no distinguishing effect among multiple direction labels, the executing agent deletes that candidate slot node. If a negative example shows that a branch connection causes the replay path to enter the wrong direction, the executing agent replaces that branch connection, connecting it to the output port that conforms to the legal constraint hyperedge and direction label.

[0063] After processing the counterexamples, the executing entity forms a candidate inference tree with adjusted nodes and branches. The candidate inference tree retains the relationships between the generated legal constraint hyperedges, boundary slot sets, case observation hyperedges, and source anchoring records. The candidate inference tree is not the final output, but rather the object to be solved in subsequent minimum conflict kernel extraction and maximum satisfiable constraint solving.

[0064] In this embodiment, the executing entity receives conflict candidate links, candidate inference trees, and rule engine structural constraints. Conflict candidate links are used to provide proof element slots and legal constraint hyperedges that may cause the candidate inference tree to be unstable in solving. Rule engine structural constraints are used to limit the node format, branch format, and connection relationship that the candidate inference tree can write into the inference tree data file.

[0065] The executing entity extracts a set of constraints to be tested from the candidate conflict links and performs a satisfiability test on the set of constraints. If the test result is unsatisfiable, the executing entity extracts a minimum subset of constraints, determines the minimum conflict kernel, and generates isolation conditions based on the minimum conflict kernel.

[0066] Isolation conditions and rule engine structural constraints are combined to solve for the maximum satisfiable constraints. The execution entity selects candidate nodes and branches from the candidate inference tree, forming a node set and a branch set, and writes the node set and branch set into the inference tree data file.

[0067] In one embodiment, when processing conflict candidate links, the executing entity reads the proof element slots, legal constraint hyperedges, direction labels, and source anchoring records involved in each conflict candidate link into the same detection batch. The proof element slots are used to represent the facts, evidence, period, amount, exception conditions, or direction labels that cause the conflict. The legal constraint hyperedges are used to represent the required slots, evidence slots, exception slots, and output ports related to the aforementioned proof element slots. The direction labels are used to locate the source of inconsistency between the conflict candidate link and the candidate reasoning tree replay path. The source anchoring records are used to backtrack to the legal text or case chain text after conflict localization.

[0068] The set of constraints to be detected is formed by the proof element slots and legal constraint hyperedges involved in the conflict candidate links. The executing entity transforms the proof element slots into slot existence constraints, slot absence constraints, or slot exclusion constraints, and transforms the legal constraint hyperedges into mandatory constraints, evidence constraints, exception constraints, and port constraints. Slot existence constraints represent slots that must be retained in the candidate inference tree; slot absence constraints represent slots that were not covered in the replay samples; and slot exclusion constraints represent slots that cannot enter the same path simultaneously. Mandatory constraints restrict the slot conditions that the candidate inference tree must meet before entering the output port; evidence constraints restrict the support relationship between evidence slots and fact slots; exception constraints restrict path entry when an exception slot is triggered; and port constraints restrict path exits from conforming to the rule engine structure constraints.

[0069] Satisfactionability testing is used to determine whether the set of constraints to be tested can simultaneously meet all conditions. The executing entity inputs the set of constraints to be tested into the constraint solving program. If the program can find a combination of nodes and branches that satisfies all constraints, the set of constraints to be tested is considered satisfies, and the associated conflict candidate links are not included in the minimum conflict kernel extraction. If the program cannot find a combination of nodes and branches that satisfies all constraints, the set of constraints to be tested is considered unsatisfies, and the executing entity extracts a minimum constraint subset from the set of constraints to be tested. The minimum constraint subset must simultaneously satisfy two conditions: when retaining the minimum constraint subset, the constraint solving of the candidate reasoning tree is unsatisfying; and the constraint subset obtained after deleting any constraint from the minimum constraint subset is satisfies. The executing entity determines the minimum constraint subset that satisfies the above conditions as the minimum conflict kernel.

[0070] Isolation conditions are generated based on the minimum conflict kernel. If the minimum conflict kernel is caused by a missing required slot, the isolation condition prevents the candidate inference tree from directly connecting the playback path of the missing required slot to the output port. If the minimum conflict kernel is triggered by an exceptional slot, the isolation condition connects the relevant path to the branch corresponding to the exceptional slot. If the minimum conflict kernel is caused by inconsistent direction labels under the same set of fact slots, the isolation condition prevents the relevant case observation hyperedge from directly entering the maximum satisfiability constraint solution as a positive sample of the candidate inference tree. After the isolation conditions are generated, they are stored in association with the candidate inference tree and passed to the maximum satisfiability constraint solution stage.

[0071] In one embodiment, when the executing entity solves the maximum satisfiability constraint of the candidate inference tree, the candidate nodes and candidate branches in the candidate inference tree are encoded as Boolean variables. The Boolean variable for a candidate node indicates whether the candidate node enters the node set, and the Boolean variable for a candidate branch indicates whether the candidate branch enters the branch set. The rule engine structural constraints and isolation conditions are set as hard constraints, which must be satisfied. The replay consistency of the case observation hyperedge is set as a soft constraint, used to select the node set and branch set that can cover more replay paths among multiple feasible solutions.

[0072] The rule engine's structural constraints include node format constraints, branch format constraints, entry constraints, exit constraints, and connectivity constraints. Node format constraints restrict each candidate node in the node set to having a node identifier, slot type, and source anchor record that can be written to the inference tree data file. Branch format constraints restrict each candidate branch in the branch set to having a start node, an end node, and a branch condition. Entry constraints restrict the existence of entry nodes in the candidate inference tree that can be invoked by the rule engine. Exit constraints restrict the paths in the candidate inference tree to reach the output port. Connectivity constraints prevent isolated nodes in the node set that cannot be reached from the entry node.

[0073] Isolation conditions are treated as hard constraints in the solution process. The execution entity reads the minimum conflict kernel pointed to by the isolation condition and prevents conflicting constraints in the minimum conflict kernel from appearing simultaneously in the same valid path. If a candidate node or candidate branch would cause conflicting constraints to be met simultaneously, the execution entity excludes that candidate node or candidate branch from the selection range, or forces it to connect to the branch corresponding to the manual review direction or the exception slot. The above processing ensures that the minimum conflict kernel will not form an unisolated path in the inference tree data file.

[0074] The consistency of the playback of case observation hyperedges is incorporated into the solution process as a soft constraint. The execution entity replays each case observation hyperedge into the candidate inference tree, recording whether the playback path reaches the output port consistent with the direction label. When the playback path is consistent, the relevant soft constraint is satisfied; when the playback path is inconsistent, the relevant soft constraint is not satisfied, but this does not directly lead to solution failure. The maximum satisfiable constraint solution, while satisfying all hard constraints, ensures that the number of satisfied soft constraints meets the solution objective, and outputs the node set and branch set.

[0075] The node set and branch set form the main content of the inference tree data file. The execution entity writes candidate nodes from the node set into the node list, candidate branches from the branch set into the branch list, and also writes the entry node, output port, source anchor record, rule engine structure constraint version, and isolation condition index into the inference tree data file. After the inference tree data file is generated, it can be read by the rule engine. The rule engine executes the path according to the node list and branch list, and prevents conflicting paths from directly entering the output port when an isolation condition is hit.

[0076] In this embodiment, the request type is double wage difference for failure to sign a written labor contract. The executing entity receives legal text, case chain text, and rule engine structural constraints. The legal text is derived from relevant regulations on labor contract signing and double wage difference, and the case chain text is derived from historical case chains that have been anonymized. The rule engine structural constraints are used to limit the entry node, node list, branch list, output port, isolation condition index, and source anchoring field in the reasoning tree data file.

[0077] In this embodiment, the input sample includes one legal provision text fragment and four case chain text fragments. The legal provision text fragment is numbered L-01, its source type is legal provision text, and its identified expressions include the facts: no contract signed, period: more than one month, amount: double wages, and the corresponding source anchor is location: L1-002, source: LAW-HT, hash: 9F3A7C21. In the attached figure of this embodiment, "no contract signed" is the field shown in the attached figure, corresponding to the "no written labor contract" in the proof element slot.

[0078] Case chain text fragment C-081 is of case chain text source type, and the identified expressions include the fact: no contract signed, evidence: bank statements, and direction: support. The corresponding source anchor is location: C081-P3, source: CASE-081, hash: 4B9E2D10. Case chain text fragment C-116 is of case chain text source type, and the identified expressions include the evidence: difference paid, and direction: partial support. The corresponding source anchor is location: C116-P2, source: CASE-116, hash: A8C6F091. Case chain text fragment C-135 is of case chain text source type, and the identified expressions include the fact: no contract signed, evidence: bank statements, and direction: supplementary materials. However, the corresponding period expression for the period without a contract is not identified. The corresponding source anchor is location: C135-P2, source: CASE-135, hash: B17C3E62. The case chain text fragment C-190 is of the case chain text type. The identified expressions include the same fact slot, direction: rejection, and the corresponding source anchor is position: C190-P4, source: CASE-190, hash: D45A01BE.

[0079] like Figure 2 As shown in the figure, the processing results of the input data are displayed in four columns: text number, source type, identification expression, and source anchoring. The text number is used to distinguish between legal text fragments and case chain text fragments; the source type is used to distinguish between legal text and case chain text; the identification expression is used to carry factual expression, evidence expression, period expression, monetary expression, and directional label expression; and the source anchoring is used to record the location identifier, source identifier, and original text hash. Figure 2 Each line in the data corresponds to a text fragment, and subsequent predicate expressions, equivalence classes, proof element slots, and inference tree data files can all be traced back to the corresponding text fragments through hashing.

[0080] After completing text segmentation and generating recognition expressions, the executing entity converts the recognition expressions into predicate expressions and loads rewriting rules that match the request type. For example... Figure 3As shown, the predicate expressions P01 "no signed labor contract" and P02 "no written labor contract concluded" are rewritten using rewriting rule R1 and then written into equivalence class E01. The normalized expression of equivalence class E01 is "no written labor contract concluded," generating proof element slot S02, with slot type being fact expression. The predicate expressions P03 "bank statements" and P04 "salary statements" are merged into evidence using rewriting rule R2 and then written into equivalence class E02. The normalized expression of equivalence class E02 is "salary payment evidence," generating proof element slot S06, with slot type being evidence expression. After the predicate expressions P05 "2023-04 to 08" and P06 "April 1 to August 31" are normalized according to the rewriting rule R3, they are written into the equivalence class E03. The normalized expression of the equivalence class E03 is the unsigned period, and the proof element slot S04 is generated, with the slot type being the period expression.

[0081] When merging equivalence classes, the executing entity uses consistency of request type, consistency of expression type, complete source anchoring record, and verifiable original hash as merging conditions. P01 and P02 both belong to factual expressions and can be traced back to the legal text or case chain text through the source anchoring record, thus entering equivalence class E01. P03 and P04 both belong to evidentiary expressions and correspond to bank statements or salary slips, thus entering equivalence class E02. P05 and P06 both belong to period expressions and represent the same unsigned period, thus entering equivalence class E03. Figure 3 The arrows in the text indicate that the predicate expression enters the equivalence class after being rewritten by the rules, and the equivalence class generates the proof element slots.

[0082] The executing entity generates legal constraint hyperedges and case observation hyperedges based on the proof element slots. For example... Figure 4 As shown, the legal constraint superborder L-E01 consists of necessary slots S01 to S05, evidence slot S06, exception slot S09, and output ports. S01 represents the employment relationship, S02 represents the absence of a signed contract, S03 represents the start date, S04 represents the period without a signed contract, S05 represents the wage base, S06 represents wage evidence, and S09 represents the statute of limitations exception. The output ports include P1 support, P2 partial support, P3 supplementary materials, and P4 isolated review.

[0083] Figure 4The right side displays the results of the case observation superedge determination. Case observation superedge C-E081 has slot states S01 to S06, a direction label of "support," and its factual and evidence slots cover the required and evidence slots in legal constraint superedge L-E01, without triggering any exception slots; therefore, it is determined to be an absorbable link. Case observation superedge C-E116 has slot states S01 to S06 and S10, a direction label of "partial support," and S10 corresponds to evidence of paid difference; this case observation superedge is also determined to be an absorbable link. Case observation superedge C-E135 lacks S04, and its direction label is "supplementary material"; due to the lack of a required slot, it is determined to be a conflict candidate link. Case observation superedge C-E190 has the same set of factual slots, and its direction label is "rejection"; due to a direction label conflict with C-E081, it is determined to be a conflict candidate link.

[0084] The executing entity uses the absorbable link as the object and the proof element slot as the attribute to generate object attribute relationships. For example... Figure 5 As shown, absorbable links A1 to A4 correspond to absorbable objects of different case observation superedges under the same request type, where A3 and A4 are absorbable links in the same batch of extended examples. A1 contains S01 to S06, S10 is 0, S12 is 0, and the direction is support. A2 contains S01 to S06 and S10, S12 is 0, and the direction is partially support. A3 contains S01 to S06 and S12, S10 is 0, and the direction is support. A4 contains S01 to S06, S10, and S12, and the direction is partially support. The value 1 in the object attribute relationship indicates that the absorbable link contains the corresponding proof element slot, and the value 0 indicates that it does not contain the corresponding proof element slot.

[0085] Based on object attribute relationships, the execution entity constructs a formal concept lattice. Concept C0 contains S01 to S06, corresponding to A1 to A4. Concept C1 adds S10 to C0, corresponding to A2 and A4, with a partial support orientation. Concept C2 adds S12 to C0, corresponding to A3 and A4, with a mixed orientation. Concept C3 contains both S10 and S12, corresponding to A4, with a partial support orientation. The execution entity compares the slot differences between concepts corresponding to different orientation labels, determines that S10 is used to distinguish the path differences corresponding to support and partial support, and S12 is used to retain the slot differences corresponding to the mixed orientation concept, and writes S10 and S12 into the boundary slot set.

[0086] The set of boundary slots containing S10 and S12 enters the candidate inference tree generation stage. For example... Figure 6As shown, the executing entity generates a candidate inference tree based on the legal constraint superedge and boundary slot set. The candidate inference tree contains candidate nodes N01 to N06, where N01 represents the employment relationship, N02 represents the period without a signed contract, N03 represents the period without a signed contract, N04 represents the wage base, N05 represents wage evidence, and N06 represents the difference already paid. The output ports include P1 support, P2 partial support, P3 supplementary materials, and P4 isolated review.

[0087] The executing entity uses case observation hyperedges to replay candidate inference trees. Slots S01 to S06 of C-E081 are labeled "Support," the replay result is P1, and the sample status is consistent. Slots S01 to S06 and S10 of C-E116 are labeled "Partial Support," and after hitting N06 (the difference has been paid), the replay result is P2, and the sample status is consistent. Slot S04 of C-E135 is missing, the direction label is "Supplementary Material," the replay result is P3, and the sample status is consistent. Slots S01 to S06 of C-E190 are labeled "Rejection," the replay result is P1, and because the replay result is inconsistent with the direction label, it is identified as a negative example. Based on the negative example, the executing entity introduces an isolation review path, causing the direction conflict sample to enter the P4 isolation review, preventing the direction label conflict from directly entering the support port.

[0088] The candidate conflict link enters the minimum conflict kernel extraction stage. For example... Figure 7 As shown, the set of constraints to be tested includes K01 to K05. K01 is required for S04 and is in a reserved state. K02 is an exception to S09 and is in a reserved state. K03 corresponds to support for C-E081 and is in a reserved state. K04 corresponds to rejection for C-E190 and is in a conflict state. K05 requires that the same fact slots cannot be directed in opposite directions and is in a conflict state. The executing entity performs a satisfiability test on the above set of constraints to be tested. If both K04 and K05 exist, the constraint solution of the candidate inference tree cannot be satisfied. After deleting either K04 or K05, the remaining constraints can be satisfied. Therefore, K04 and K05 form the minimum conflict kernel MC01.

[0089] The executing entity generates isolation condition IC01 based on the minimum conflict kernel MC01. Isolation condition IC01 is used to constrain case observation hyperedges that are inconsistent with the fact slots and have different direction labels to enter the isolation verification path. In the maximum satisfiable constraint solving stage, candidate nodes N01 to N06 and candidate branches B01 to B08 are encoded as Boolean variables. The rule engine structural constraints and isolation condition IC01 serve as hard constraints, while the playback consistency of case observation hyperedges serves as soft constraints. Figure 7 In the soft constraint region, 3 out of 4 playback samples have playback paths that match the direction labels, and 1 sample with a conflicting direction is isolated for review and is not directly absorbed as a consistent sample.

[0090] The maximum set of nodes N01 to N06 and P1 to P4 can be satisfied by solving constraints, and a set of branches B01 to B08 is also output. The execution entity generates a reasoning tree data file based on the node and branch sets. The reasoning tree data file fields include requestType, entryNode, nodeList, branchList, isolationIndex, and sourceHashSet. requestType is RQ-01, entryNode is N01, nodeList is N01 to N06 and P1 to P4, branchList is B01 to B08, isolationIndex is IC01, and sourceHashSet contains 5 hashes. The 5 hashes in sourceHashSet correspond to... Figure 2 The numbers 9F3A7C21, 4B9E2D10, A8C6F091, B17C3E62, and D45A01BE are used to trace the source of legal text fragments and case chain text fragments.

[0091] In this embodiment, predicate expressions are entered into equivalence classes through rewriting rules and merging conditions. Equivalence classes generate proof element slots, which further generate legal constraint hyperedges and case observation hyperedges. Absorbable links are entered into formal concept lattices, which output a set of boundary slots. Conflict candidate links are extracted using a minimum conflict kernel, which generates isolation conditions. Candidate inference trees are then solved using the maximum satisfiable constraint to form an inference tree data file. Thus, a traceable data processing closed loop is formed between the input text fragment, source anchoring records, intermediate slots, link determination, boundary slots, counterexample samples, isolation conditions, and the inference tree data file.

[0092] like Figure 8 As shown, a labor arbitration reasoning tree generation system that integrates legal provisions and case chains includes the following modules.

[0093] The acquisition module consists of a data interface circuit, an input cache unit, a text preprocessor, and a hash operation unit. The data interface circuit receives the request type, legal text, case chain text, and rule engine structural constraints. The input cache unit temporarily stores the received data. The text preprocessor performs text segmentation and expression recognition. The hash operation unit generates the original text hash for the text segment and forms a source anchor record together with the location identifier and source identifier.

[0094] The saturation module consists of a rule memory, an equivalence graph memory, a graph update processor, and a saturation iteration controller. The rule memory loads rewrite rules that match the request type. The equivalence graph memory stores predicate expressions, normalized expressions, and equivalence classes. The graph update processor controls the writing of predicate expressions into the equivalence graph based on source anchor records and rewrite rules. The saturation iteration controller controls the repeated execution of equivalence saturation and outputs proof feature slots when there are no new equivalence class merging results.

[0095] The graph construction module consists of a slot buffer, a hyperedge generation processor, a graph structure memory, and a link determination processor. The slot buffer receives proof element slots, the hyperedge generation processor generates legal constraint hyperedges and case observation hyperedges, the graph structure memory stores the proof element constraint graph, and the link determination processor determines absorbable links and conflict candidate links based on the relationships between required slots, evidence slots, exception slots, and direction labels.

[0096] The concept module consists of an object attribute relation store, a concept lattice construction processor, and a boundary slot filtering processor. The object attribute relation store stores the inclusion relationship between absorbable links and proof element slots. The concept lattice construction processor constructs a concept lattice based on object attribute relations. The boundary slot filtering processor compares the slot differences between concepts corresponding to different directional labels and outputs a set of boundary slots.

[0097] The generation module consists of a reasoning tree cache, a playback processor, a negative example sample storage, and a tree structure correction processor. The reasoning tree cache stores the initial reasoning tree formed by the set of rule constraint hyperedges and boundary slots. The playback processor inputs the case observation hyperedges into the initial reasoning tree and generates playback paths. The negative example sample storage stores the case observation hyperedges where the playback paths do not match the direction labels. The tree structure correction processor adds, deletes, or replaces nodes or branches based on the negative examples to generate candidate reasoning trees.

[0098] The solution module consists of a constraint encoding processor, a conflict kernel extraction processor, a constraint solving processor, and a data file output interface. The constraint encoding processor encodes candidate nodes and candidate branches into Boolean variables. The conflict kernel extraction processor extracts the minimum conflict kernel based on the conflict candidate links and generates isolation conditions. The constraint solving processor combines the rule engine structure constraints to perform the maximum satisfyable constraint solution. The data file output interface writes the node set and branch set into the inference tree data file.

[0099] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0100] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A method for generating a labor arbitration reasoning tree that integrates legal provisions and case chains, characterized in that, The method includes: Obtain the request type, legal text, case chain text, and rule engine structural constraints to obtain predicate expressions and source anchoring records; Load the rewrite rule that matches the request type, write the predicate expression into the equivalence graph according to the source anchor record and the rewrite rule, and perform equality saturation to obtain the proof element slot; Based on the proof element slots, generate legal constraint hyperedges and case observation hyperedges, construct a proof element constraint graph and determine absorbable links and conflict candidate links; Based on the aforementioned absorbable link, a conceptual lattice is constructed and the set of boundary slots is determined. Based on the legal constraint hyperedge, the boundary slot set, and the case observation hyperedge, a candidate inference tree is generated using a counterexample-driven approach. The minimum conflict kernel is extracted from the candidate conflict links, and isolation conditions are generated. The maximum satisfyable constraint is solved for the candidate inference tree in combination with the rule engine structure constraints, and the inference tree data file is output.

2. The method according to claim 1, characterized in that, The acquisition of predicate expressions and source anchoring records includes: The legal text and the case chain text are divided into text segments. Factual expressions, evidentiary expressions, period expressions, monetary expressions, exception condition expressions, and directional label expressions are identified from the text segments. The position identifier, source identifier, and original text hash of the text segments are associated with the identified factual expressions, evidentiary expressions, period expressions, monetary expressions, exception condition expressions, and directional label expressions, respectively, to generate the predicate expression and the source anchoring record.

3. The method according to claim 1, characterized in that, The loading of rewrite rules matching the request type, based on the source anchoring record and the rewrite rules, writes the predicate expression into the equivalence graph and performs equality saturation to obtain proof element slots, including: The normalized expression of the predicate expression is determined according to the rewriting rules. Predicate expressions with the same normalized expression and satisfying the merging condition of the source anchoring record are written into the same equivalence class. A representative expression is determined from the same equivalence class, and the proof element slot is generated based on the representative expression.

4. The method according to claim 1, characterized in that, The generation of legal constraint hyperedges and case observation hyperedges based on the proof element slots includes: From the proof element slots generated by the predicate expression corresponding to the legal provision text, determine the required slots, evidence slots, exception slots, and output ports, and generate the legal provision constraint hyperedge; The fact slot, evidence slot, direction label, and source anchor record are determined from the proof element slots generated from the predicate expression corresponding to the case chain text, and the case observation hyperedge is generated.

5. The method according to claim 4, characterized in that, The construction of the proof element constraint graph and the determination of absorbable links and conflict candidate links include: The proof element constraint graph is constructed using the proof element slots as graph nodes and the legal constraint hyperedges and the case observation hyperedges as hyperedges. If the fact slots and evidence slots in the case observation hyperedge cover the required slots in the legal constraint hyperedge, and the exception slots are not triggered, the case observation hyperedge is determined as the absorbable link. If the case observation superedge is missing the required slot, triggers the exception slot, or has a different direction label than other case observation superedges with the same set of fact slots, the case observation superedge will be identified as the conflict candidate link.

6. The method according to claim 5, characterized in that, Using the absorbable link as the object and the proof element slot as the attribute, a formal concept lattice is constructed. The boundary slot set is determined based on the slot differences corresponding to different directional labels in the formal concept lattice, including: Based on the inclusion relationship between the absorbable link and the proof element slot, an object attribute relationship is generated, and the formal concept lattice is constructed based on the object attribute relationship; In the formal concept lattice, the slot differences between concepts with different directional labels are determined, and the slots used to distinguish different directional labels are determined as the boundary slot set.

7. The method according to claim 6, characterized in that, Based on the legal constraint hyperedge, the boundary slot set, and the case observation hyperedge, a candidate inference tree is generated using a counterexample-driven approach, including: Based on the legal constraint hyperedge, generate inference tree constraints, generate candidate slot nodes based on the boundary slot set, and combine the inference tree constraints and the candidate slot nodes into an initial inference tree; The initial inference tree is replayed using the case observation superedge. If the direction label of the replay path is inconsistent with that of the case observation superedge, the case observation superedge is identified as a negative example. Based on the negative example, nodes or branches of the initial inference tree are added, deleted, or replaced to obtain the candidate inference tree.

8. The method according to claim 1, characterized in that, The step of extracting the minimum conflict core and generating isolation conditions based on the conflict candidate links includes: The proof element slots and legal constraint hyperedges involved in the conflict candidate links are determined as the set of constraints to be detected, and the satisfiability of the set of constraints to be detected is detected. If the set of constraints to be tested is unsatisfiable, a minimum constraint subset is extracted from the set of constraints to be tested. The minimum constraint subset makes the constraint solution of the candidate inference tree unsatisfiable, and the constraint subset obtained after deleting any constraint from the minimum constraint subset is satisfactory. The minimum constraint subset is determined as the minimum conflict kernel, and the isolation condition is generated based on the minimum conflict kernel.

9. The method according to claim 1, characterized in that, The step involves combining the rule engine structural constraints to solve for the maximum satisfiable constraints of the candidate inference tree, and outputting an inference tree data file, including: The candidate nodes and candidate branches in the candidate inference tree are encoded as Boolean variables. The rule engine structure constraints and the isolation conditions are used as hard constraints, and the playback consistency of the case observation hyperedge is used as a soft constraint. The node set and the branch set are obtained by solving based on the hard constraints and the soft constraints, and the inference tree data file is generated based on the node set and the branch set.

10. A labor arbitration reasoning tree generation system integrating legal provisions and case chains, used to implement the labor arbitration reasoning tree generation method integrating legal provisions and case chains as described in any one of claims 1 to 9, characterized in that, The system includes: The acquisition module is used to acquire request type, legal text, case chain text and rule engine structural constraints, and obtain predicate expression and source anchoring record; The saturation module is used to load rewrite rules that match the request type, write the predicate expression into the equivalence graph according to the source anchor record and the rewrite rules, and perform equality saturation to obtain the proof element slot; The graph construction module is used to generate legal constraint hyperedges and case observation hyperedges based on the proof element slots, construct the proof element constraint graph, and determine absorbable links and conflict candidate links. A concept module is used to construct a formal concept lattice based on the absorbable link and determine the set of boundary slots; The generation module is used to generate candidate inference trees based on the legal constraint hyperedges, the boundary slot set, and the case observation hyperedges, using a counterexample-driven approach. The solution module is used to extract the minimum conflict kernel based on the conflict candidate links and generate isolation conditions, and combine the rule engine structure constraints to solve the maximum satisfiable constraints of the candidate inference tree, and output the inference tree data file.

Images