Legal service project three-party agent pre-auditing arrangement and double-threshold gating method and system based on large language model, and storage medium

Abstract

The invention relates to the field of legal science and technology and generative artificial intelligence, and discloses a legal service project three-party agent pre-auditing arrangement and double-threshold gating method and system based on a large language model, and a storage medium. A platform, party and law institution three-party agent collaborative architecture is constructed, and role recognition, evidence structuring, law mapping, intelligent evaluation and document generation are completed through a chat mechanism. The method comprises the following steps: judging a party role based on LLM and generating an authorization certificate; demand fingerprints and evidence maps are extracted under platform arrangement, and legal mapping and reference chains are generated; hierarchical visible control is realized through a double-threshold scoring function; generating a neutral summary, a strategy tree and a document first draft through combination; and finally, outputting a desensitization packaging result and completing auditing anchoring. According to the method, the compliance, comparability and auditing performance of the project establishment stage are effectively improved, and the method is suitable for multiple types of legal service pre-docking scenes.

Description

Technical Field

[0001] This invention relates to the fields of generative artificial intelligence and legal technology, specifically to a pre-screening arrangement and dual-threshold gating processing method, system and storage medium for three-party intelligent agents (platform intelligent agent × party intelligent agent × law firm intelligent agent) driven by a large language model (LLM). It belongs to the fields of multi-agent dialogue arrangement, evidence-legal provision mapping, visibility domain control and auditable export technology. Background Technology

[0002] In the legal service project initiation stage (preliminary review and selection before formal engagement), there are problems such as: fragmented information, unclear roles and authorizations, risk of leakage due to conflict retrieval, inconsistent dialogue, difficulty in forming comparable bidding materials, heavy burden of cross-border and privacy compliance, and difficulty in process traceability. Existing solutions mostly rely on manual email / IM and rule systems, lacking the ability to collect structured data and map laws based on LLM-based dialogue. They cannot achieve traceable links between facts, legal provisions, and precedents in the early stages, nor can they achieve progressive visibility control based on dual thresholds and end-to-end auditable export loops, making it difficult to achieve both efficiency and compliance. Summary of the Invention

[0003] I. Purpose of the Invention This invention aims to provide a three-party intelligent agent pre-screening orchestration technology based on LLM to address issues such as role / authorization uncertainty, difficulty in fact modeling, conflict retrieval and privacy risks, incomparable materials, gate failure, and weak auditing during the project initiation stage, thereby achieving: (1) The role vector and delegation chain are established through LLM dialogue; (2) Use LLM to extract and generate demand fingerprints and evidence maps and complete legal mapping; (3) Progressive visibility and PEP enforcement are driven by a dual threshold score of S=θ1×θ2×ρ×κ; (4) Under the framework of deliberation, the LLM produces a neutral summary package and a first draft of the document / response card; (5) Achieve an integrated closed loop of sorting takeover, desensitization export, and PSIG audit.

[0004] II. Technical Solution

[0005] (I) Introduction

[0006] The technical solution of the present invention consists of a method, a system, and a storage medium, with LLM being a necessary computation and generation unit.

[0007] (1) Methodology: S1 The LLM establishes RoleVector / DelegationChain / AccessTicket; S2 The LLM×LLM extracts NeedFingerprint through conversation, constructs EvidenceGraph and generates LegalMapping, and performs G0 double-blind conflict pre-detection; S3 The LLM calculates S=θ1 (utility)×θ2 (compliance)×ρ (role confidence)×κ (maturity), generates GatePolicy and implements FROZEN / G0 / G1 / G2 progressive visibility and PEP recommendations; S4 The platform LLM organizes Debate→Deliberation→Synthesis, producing a neutral summary package, strategy tree, AFA recommendations, document first draft / comparable response card; S5 The LLM calculates takeover ranking R, generates interview topics and takeover tickets, completes anonymization rewriting and AnonEnvelope encapsulation, and exports via PEP-Export verification. Key events throughout the process are recorded and batch-anchored using PSIGEvent.

[0008] (2) System modules: including LLM-Role & Delegation, LLM-Policy & Session, LLM-Need / Evidence, LLM-LegalMapping, LLM-Conflict & Ethics, LLM-Gating, LLM-Draft & Compare, LLM-Rank & Handover, LLM-Audit (PSIG), LLM-Redact & Export, etc.; each module has embedded LLM-Gen / LLM-Check sub-devices, and rules / search are only auxiliary means.

[0009] (3) State machine: The LLM generates commands and the platform executes INIT→PROXY_RESOLVE→CLARIFY→LEGAL_MAP→G0_CONFLICT→GATING{FROZEN / G0 / G1 / G2}→DELIBERATE&SYNTHESIZE→HANDOVER_PLAN→REDACT_EXPORT→PSIG_LOG, with red branch ISOLATE / BLOCK.

[0010] (4) Data objects: RoleVector, DelegationChain, AccessTicket, NeedFingerprint, EvidenceGraph, LegalMapping, ConflictReport, GatePolicy / gate_sig, HandoverRank / HandoverTicket / Agenda, AnonEnvelope, PSIGEvent, etc., produced / consumed by LLM.

[0011] (II) Methods and Procedures

[0012] S1 Role and Delegation Initialization (LLM-led) In step S1, the system invokes the Large Language Model (LLM) and its ensemble to perform generative question answering and structured parsing on the input from the parties involved, completing role determination, delegation / authorization chain parsing, access control ticket generation, and session / policy anchoring, outputting RoleVector, DelegationChain, AccessTicket, and session baseline parameters. The steps include:

[0013] S1.1 Acquisition and Preprocessing (LLM-Init) The system initiates multiple rounds of question-and-answer sessions based on LLM, collects the parties' matters, identity statements, basic facts and evidence clues related to the case, and performs regularization, noise reduction and key element extraction on the input to form an intermediate representation for subsequent judgment.

[0014] S1.2 Role Resolve (LLM) The system calls LLM in parallel to complete the following three role determination processes and summarizes them into a unified RoleVector: S1.2.1 Self-selection (R1): The user selects a target role package from the platform's preset role package set; LLM calculates the similarity percentage of the role package based on the dialogue context and the extracted elements and writes it into RoleVector; S1.2.2 Preset Comparison Formula (R2): LLM outputs the similarity distribution (Top-k) for multiple role packs preset by the platform, and records the main role and the candidate weights in RoleVector accordingly; S1.2.3 Delegation Chain Identification (R3): LLM determines whether the party is the principal, agent, or other authorized entity by verifying authorization-related questions and credentials, and generates fields such as subject, agent, scope, time-to-live (TTL), and revocable in the DelegationChain; at the same time, it calculates the role confidence ρ and writes it into the RoleVector.

[0015] S1.3 Role Consistency and Conflict Resolution (LLM) LLM performs consistency checks on the judgment results of R1 / R2 / R3. If inconsistencies are found, supplementary questions and answers are triggered to converge the role conclusions. After convergence, the final RoleVector{role_id, similarity_pct, ρ, persona_tags} is determined and the output of this step is locked.

[0016] S1.4 Access Control Initialization (LLM - AccessInit) LLM generates an initial AccessTicket proposal with a minimum visible scope based on RoleVector and DelegationChain. The proposal includes at least: the visible scope and field granularity, the time-to-live (TTL), the revocable attribute, and watermark / marking parameters; the system establishes an initial visible scope strategy accordingly.

[0017] S1.5 Session and Policy Binding (LLM-PolicyBind) LLM generates and solidifies session and policy anchoring parameters, including session identifier sess_id, time window identifier window_id, policy version policy_ver, and policy summary policy_hash; the system also completes the registration of three policy execution points (PEP-Plan, PEP-Chat, PEP-Export) for subsequent gating and auditing.

[0018] S1.6 Audit Genesis (LLM) The system creates the genesis event for the audit chain, records key summary information related to this step, and prepares for the continuation of the event chain in subsequent gating, exporting, and takeover processes.

[0019] S1.7 Output and Handover (LLM-Emit) The system outputs the RoleVector, DelegationChain, AccessTicket, and session / policy anchoring parameters confirmed by the LLM, which serve as inputs for A2A / A2A2A clarification, gating, and collaboration drafting in subsequent steps.

[0020] S2 A2A Clarification and Fact / Requirement Modeling (LLM×LLM Dialogue, Platform LLM Orchestration) In step S2, the system invokes the Large Language Model (LLM) and its collection to orchestrate and execute the dialogue between the client-side LLM and the law firm-side LLM, completing requirement extraction, fact modeling, legal mapping, and double-blind conflict pre-detection, and outputting structured results for subsequent gating and deliberation. The steps include:

[0021] S2.1 Dialogue Orchestration and Scope Setting (LLM) The platform LLM establishes an A2A conversation orchestration plan, limits the visible domain and field granularity, sets the clarification round budget and time window, assembles PEP-Chat execution points, and generates the conversation outline and verification points for this stage.

[0022] S2.2 Need Fingerprint Extraction (LLM) Under the coordination of the platform LLM, the client-side and law firm-side LLMs completed multiple rounds of clarification. The platform LLMs generated and extracted the dialogue content to form a NeedFingerprint, which included at least: jurisdiction and adjudication / regulatory body, language and translation / interpretation requirements, budget model and AFA preferences, key deadline windows, confidentiality level and data processing restrictions, expected deliverables and stage milestones.

[0023] S2.3 Fact and Evidence Modeling (LLM-EvidenceGraph) The platform LLM transforms narratives, attachments, and receipts into a structured EvidenceGraph, generating nodes and relational edges based on a five-tuple of time, place, person, behavior, and evidence. It also labels the source, acquisition path, and credibility score, and merges duplicates, missing items, and ambiguities into placeholders.

[0024] S2.4 Consistency Verification and Clarification Driven (LLM-Consistency) The platform's LLM performs consistency and completeness checks on NeedFingerprint and EvidenceGraph, outputs a list of conflict points and gaps, generates clarification Q&A cards, and feeds them back to the client's and law firm's LLM to iteratively converge the factual caliber and requirement boundaries; and updates the results of the previous step when necessary.

[0025] S2.5 Legal Mapping and Reference Chain Construction (LLM) The platform LLM performs IRAC-style issue decomposition based on EvidenceGraph, generates LegalMapping, maps facts to candidate legal provisions and precedents, and establishes a traceable citation chain, recording the jurisdiction, court level, year of judgment, main points and similarity score, for subsequent gating and deliberation review.

[0026] S2.6 Maturity Assessment and Characteristic Quantification (LLM-Maturity) The platform LLM quantifies fact connectivity, citation traceability, and document first-version availability, calculates the maturity coefficient κ, and scores the sub-items of θ1 and θ2 for use in the next step of gating.

[0027] S2.7 G0 Double-blind Conflict Preview (LLM-ConflictBlind) The platform LLM generates a salted element set based on the minimum visible domain, triggers conflict retrieval on the law firm side and collects receipts, forming a ConflictReport and risk assessment; the entire process is constrained by the visible domain and the invoice, and does not reveal plaintext information beyond G0.

[0028] S2.8 LLM - Supplement & Emit (Missing Information) When NeedFingerprint, EvidenceGraph, LegalMapping, or ConflictReport does not meet the minimum requirements for proceeding to the next stage, the platform LLM generates a supplement_ticket{TTL, cause_codes} and a supplement list, maintaining the established visibility domain without degradation; when the stage conditions are met, it outputs the confirmed NeedFingerprint, EvidenceGraph, LegalMapping, ConflictReport, and κ as input for the next step.

[0029] S3 Dual Thresholds and Progressive Visibility (LLM Calculation and Enforcement Recommendations) In step S3, the system invokes the Large Language Model (LLM) and its ensemble to perform scoring aggregation, threshold determination, and visibility domain allocation on the results of steps S1 and S2, generating gating policies and proposing enforcement suggestions, driving the session state to transition step by step from FROZEN, G0, G1 to G2. The steps include:

[0030] S3.1 Rating Aggregation (LLM-GatingCalc) LLM calculates S=θ1×θ2×ρ×κ based on NeedFingerprint, EvidenceGraph, LegalMapping, RoleVector, and DelegationChain, and generates sub-item scores and explanations: θ1 (clarity of matter, urgency, value / budget fit, jurisdiction / language fit, completeness of evidence), θ2 (conflict clarity, license / territorial practice compliance, sanctions / AML, confidentiality and privilege, PSIG consistency, response SLA), ρ (role confidence), and κ (maturity: fact connectivity, citation traceability, document first draft usability).

[0031] S3.2 Threshold Determination and Hysteresis Control (LLM-Threshold) LLM determines S based on a preset threshold range and outputs the target gating level and hysteresis window to prevent level jitter caused by short-term fluctuations. S<T0→FROZEN; T0≤S<T1→G0; T1≤S<T2→G1; S≥T2→G2; When S is near an adjacent threshold, a hysteresis window and minimum hold duration suggestion are adopted to ensure gating stability.

[0032] S3.3 Visible Domain Policy Generation (LLM-GatePolicy) LLM generates a GatePolicy, including the gate level, set of visible fields, redaction_profile, granularity of evidence / document display, dialogue anonymization / rewriting rules, and watermark parameters; and proposes tightening or loosening suggestions for the scope and TTL of the AccessTicket to ensure that "unblocking is only performed when the threshold is met."

[0033] S3.4 Ticket and Signature Update (LLM - TicketUpdate) LLM generates access ticket update suggestions based on GatePolicy. The system performs version increment and watermark update on the AccessTicket, and generates gate_sig to bind this gate control decision with policy_hash / window_id for subsequent audit verification.

[0034] S3.5 Three-point policy execution gating (LLM-PEPEnforce) LLM provides enforcement recommendations for PEP-Plan, PEP-Chat, and PEP-Export and outputs a set of actions (PASS, REWRITE / REDACT, DELAY, ISOLATE, BLOCK). The system then performs checks and actions at the corresponding execution points to ensure that content that has not reached the threshold is not accessed or exported without authorization.

[0035] S3.6 Redline Detection and Isolation (LLM-Redline) LLM detects unauthorized practice, sanctions / anti-money laundering violations, privacy / data export non-compliance, license / territorial practice restrictions, and out-of-order access, and outputs red line hits and reason codes; for hit items, it proposes ISOLATE / BLOCK suggestions and rolls back to FROZEN or maintains the current level but freezes sensitive fields.

[0036] S3.7 Non-degradation push notification and consistency verification (LLM-Consistency) When S does not reach the next gating level and no red line is hit, LLM generates a supplement_ticket{TTL,cause_codes} and a supplement list, maintaining the existing visible domain without downgrading; when new evidence or requirements change, a consistency review is triggered, updating θ1, θ2, ρ, κ and S.

[0037] S3.8 Audit Logs and Anchoring (LLM-PSIGLog) The system records gated events PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}, which include S, sub-item score, GatePolicy summary, gate_sig and disposal action, and completes batch anchoring and traceable index generation.

[0038] S3.9 Stage Output and State Transition (LLM-Emit) The system outputs the latest versions of confirmed S, θ1, θ2, ρ, κ, GatePolicy, and AccessTicket, along with gate_sig, and drives the session state to transition between FROZEN, G0, G1, and G2 accordingly, providing input for the agreement and collaboration drafting in step S4.

[0039] S4 A2A2A Agreement and Collaboration Drafting (Full LLM) In step S4, the system invokes the Large Language Model (LLM) and its aggregates to debate, deliberate, and synthesize the dialogue results between the client-side LLM and the law firm-side LLM, completing a neutral summary, strategy generation, and collaborative document drafting. Within the defined visibility domain and strategy execution points, it outputs structured results that can be used for takeover and export. The steps include:

[0040] S4.1 Collaborative Orchestration and Resource Scheduling (LLM) The platform LLM configures council meeting parameters based on GatePolicy and AccessTicket, sets roles and responsibilities, round budgets and time windows, issue priorities and verification order, assembles PEP-Chat and PEP-Export execution points, and generates a list of issues and judgment criteria for this stage.

[0041] S4.2 Debate Stage (LLM-Debate) Under the platform's LLM scheduling, the client-side LLM and the law firm-side LLM conduct multiple rounds of key point presentations and rebuttals around EvidenceGraph and LegalMapping, outputting a set of issues, supporting and opposing arguments, evidence citation positions and corresponding confidence levels, forming an initial version of the dispute matrix and argument relationship diagram.

[0042] S4.3 Citation Verification and Consistency Check (LLM-CiteCheck) The platform LLM verifies each citation generated during the debate phase, checks the traceability of legal provisions and precedents, court levels and time validity, verifies the correspondence between citations and EvidenceGraph, marks missing, ambiguous and conflicting citations, and generates correction suggestions and supplementary evidence items.

[0043] S4.4 Deliberation (LLM-Deliberate) Phase The platform's LLM (Limited Management Module) converges the scope of disputes based on the verification results, merges similar items, splits complex issues, and outputs a dispute matrix confirmed by the deliberation, a three-way mapping list of evidence, legal provisions, and precedents, and compliance review results; it also proposes handling suggestions for items that hit ethical or professional practice restrictions and updates the visibility domain restrictions.

[0044] S4.5 Synthesis (LLM-Synthesize) The platform LLM combines the consensus results to generate a neutral summary package, which includes at least: a confirmed list of key facts, a dispute matrix (including supporting and rebuttal arguments and their confidence levels), a strategy tree (including paths, preconditions, and key milestones), a win rate range, a time range and a cost range, AFA segmentation recommendations and phased deliverables design, and key concerns for subsequent takeover.

[0045] S4.6 Collaborative Drafting and Normalization of Documents (LLM) The platform LLM generates document drafts and response cards based on neutral summary packages, binds sources and citation positions at the paragraph level, and outputs a clause-evidence-citation aligned structure under a unified template; it performs field-level normalization and difference highlighting for drafts from different law firms, forming a comparable view and a list of revision suggestions.

[0046] S4.7 Quality Assessment and Maturity Update (LLM - Quality) The platform LLM quantifies document availability, coverage, citation completeness, and consistency, updates the maturity coefficient κ, and provides revised values ​​and explanatory information for the gating scoring sub-items as input for the next step of sorting and takeover.

[0047] S4.8 Visible Domain Enforcement and Export Pre-Control (LLM - PolicyEnforce) The platform LLM performs anonymization and rewriting of the neutral summary package, document first draft, and response card according to the GatePolicy, limits the visible fields and display granularity, sets watermark parameters and document range for exported content, generates a pre-export verification list and binds it to PEP-Export.

[0048] S4.9 Audit Logs and Stage Outputs (LLM-PSIGLog & Emit) The system records key events of this step to PSIGEvent, including consensus parameters, reference verification summary, caliber convergence results, neutral summary elements, document generation summary and visibility field handling actions, and completes batch anchoring and indexing; outputs neutral summary package, document first version, response card, comparable view and updated κ for use in the takeover and export processing of step S5.

[0049] S5 Takeover and Export (LLM-Rank and LLM-Redact) In step S5, the system invokes the Large Language Model (LLM) and its ensemble to perform takeover sorting, interview arrangement, decision derivation, anonymization and rewriting, and document enforcement on the aforementioned gating and deliberation results, completing the auditable export and closing loop, and outputting structured results for human processing and archiving. The steps include:

[0050] S5.1 Takeover Ranking and Shortlist Determination (LLM-Rank) LLM calculates takeover priority based on the aggregated score results and resource availability, forming a handover_rank: R=αS+β·differentiated advantages-δ·compliance risks+γ·schedule availability, and outputs a corresponding shortlist, priority order, and suggested contact window as the trigger for interviews and negotiations.

[0051] S5.2 Interview Arrangement and Topic Card Generation (LLM - Handover Plan) LLM combines a neutral summary package with a dispute matrix to generate a handover_agenda, including interview objectives, key clarifications, points of contention, phased deliverables, and budget issues; it also outputs time slot matching and participant role assignments for the takeover workbench to schedule.

[0052] S5.3 Handover Ticket and Identity Verification (LLM) LLM generates takeover tickets and verification elements based on GatePolicy. The system issues handover_ticket{scope,ttl,revocable,watermark_sig,gate_ref} and verifies and binds the identity of the takeover party before the meeting. It outputs handling suggestions for mismatched or expired tickets and blocks the establishment of the session.

[0053] S5.4 Export Strategy and Inventory Formulation (LLM - ExportPlan) LLM generates an export strategy based on the gating level and the visibility domain, and provides the export granularity and format: G0 outputs an anonymized summary; G1 outputs restricted details and highlighting of differences; G2 outputs the full text and the first draft of the document; Simultaneously generate an export_checklist, which lists the structured elements, source references, and watermark parameters that should be included.

[0054] S5.5 Desensitization Rewriting and Encapsulation (LLM-RedactPack) LLM performs desensitization, rewriting, and compression according to the export strategy, and assembles AnonEnvelope. The encapsulation includes at least: manifest (feature index), summary (neutral summary), norm_diff (comparable difference), doc_bundle (controlled document set), policy_ref, watermark_sig, and access_rules{scope,ttl,revocable}; the system then completes minimum retention and disk encryption accordingly.

[0055] S5.6 PEP-Export Ticket Verification and Processing (LLM-PEPExport) LLM provides enforcement recommendations for pre-export validation. The system checks the consistency between AccessTicket / gate_sig / policy_hash / window_id and export_checklist at the PEP-Export execution point. For out-of-order, replay, policy inconsistency, or red line violations, it performs BLOCK / ISOLATE / DELAY / REWRITE actions and stops the export.

[0056] S5.7 Audit Logs and Anchoring (LLM-PSIGLog) The system records export and takeover-related events to PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}, including handover_rank, handover_ticket summary, export policy, AnonEnvelope fingerprint, PEP handling and watermark parameters; completes batch anchoring and searchable index generation, ensuring that the process can be reviewed within two minutes.

[0057] S5.8 Feedback Reinjection and Closing Loop (LLM-Feedback) LLM performs structured parsing of takeover interview receipts and export receipts, updates EvidenceGraph, LegalMapping, maturity coefficient κ, and ranking factor, and outputs revision suggestions when necessary and writes them back to the entry point of subsequent processes; it also implements TTL control and revocation policies for exported access tickets.

[0058] (III) System Module Description

[0059] M1|LLM - Role & Delegation Based on the R1 / R2 / R3 three-way dialogue, a RoleVector{role_id, similarity_pct, ρ,persona_tags} is generated; the DelegationChain{principal,agent,scope,ttl,revocable,source_hash} is parsed; and a draft AccessTicket with the smallest visible domain (scope / fields / ttl / watermark_sig / policy_ref) is produced. LLM-Gen is responsible for question answering and extraction, while LLM-Check is responsible for consistency verification and conflict resolution.

[0060] M2|LLM-Policy & Session Generate session / policy anchors: sess_id / window_id / policy_ver / policy_hash; register PEP hooks in Plan / Chat / Export; perform policy canary deployment and consistency rewriting. LLM-Gen generates policy summary, and LLM-Check verifies version alignment with visible domains.

[0061] M3 | LLM - Need / Evidence Extract the NeedFingerprint {jurisdiction, forum, language, budget_model, afa_pref, deadline, secrecy, deliverables, milestones}; construct the EvidenceGraph {nodes, edges, source_map, credibility}, and perform denoising, deduplication, and credibility annotation; generate SupplementTicket {ttl, cause_codes, items} if necessary. LLM-Gen is responsible for structuring, and LLM-Check is responsible for integrity and contradiction detection.

[0062] M4 | LLM - Legal Mapping Perform IRAC issue decomposition; construct LegalMapping{issue_id→[statutes[],cases{court_level,year,holding,similarity,citations}],citation_links}; establish a traceable citation chain and calculate coverage. LLM-Gen is responsible for retrieval and generation, and LLM-Check is responsible for citation traceability and validity verification.

[0063] M5 | LLM - Conflict & Ethics In G0, a double-blind conflict retrieval is triggered using salting factors, generating a ConflictReport{salt_set, result, risk_codes}. Pre-checks are performed for outbound travel related to professional practice, licensing, sanctions, and privacy, and handling recommendations are provided. LLM-Gen produces elements and reports, while LLM-Check identifies red lines and provides isolation / blocking recommendations.

[0064] M6 | LLM-Gating (Gating and Visibility Domain) Calculate S = θ1 × θ2 × ρ × κ and determine FROZEN / G0 / G1 / G2; generate GatePolicy {level, visible_fields, redaction_profile, watermark_params}, update AccessTicket and gate_sig, and propose PEP enforcement recommendations. LLM-Gen generates scores and policies, and LLM-Check performs checks for lag and overreach interception.

[0065] M7|LLM - Draft & Compare Generates the first draft of documents and cross-law firm response cards; paragraph-level source binding; output normalization alignment and difference highlighting. LLM-Gen is responsible for drafting and normalization, while LLM-Check is responsible for citation completeness and coverage assessment.

[0066] M8 | LLM-Rank & Handover Calculate the takeover order: R = α·S + β·diff - δ·risk + γ·availability; Generate HandoverRank, HandoverTicket{id,scope,ttl,revocable,watermark_sig,gate_ref}, and Agenda{topics,questions,stakeholders,time_windows}; LLM-Gen generates ranking and issue cards, and LLM-Check verifies tickets and scheduling conflicts.

[0067] M9 | LLM-Audit (PSIG Audit) Generates PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason} summaries and batch anchoring; supports index recap within two minutes; LLM-Gen writes cause-and-effect chains, and LLM-Check verifies completeness and consistency.

[0068] M10 | LLM-Redact & Export (Desensitization and Export) Perform desensitization / rewriting / compression, assemble AnonEnvelope{manifest, summary, norm_diff, doc_bundle, policy_ref, access_rules, watermark_sig, digest_hash}; issue after PEP-Export verification, and encrypt and retain data to disk with minimum retention (TTL / revocable). LLM-Gen is responsible for rewriting and encapsulation, and LLM-Check is responsible for exporting compliance and out-of-order detection.

[0069] (iv) Media Description A computer-readable storage medium storing computer program instructions, which, when executed on a processor, cause the system to complete pre-screening and dual-threshold gating according to the following process flow and by calling corresponding module units; the entire process is generated, verified, scored, and rewritten by a large language model (LLM) and its collections, and the platform executes invoice and policy enforcement.

[0070] 1. Method instruction flow (S1–S5)

[0071] S1 Role and Delegation Initialization (LLM-led) Call LLM for multi-round question answering and output RoleVector (including similarity and role confidence ρ); parse DelegationChain and generate minimum visible domain AccessTicket proposal; solidify sess_id / window_id / policy_hash and register PEP-Plan / Chat / Export; generate audit genesis record.

[0072] S2 A2A Clarification and Fact / Requirement Modeling (LLM×LLM Dialogue, Platform LLM Orchestration) The platform's LLM orchestrates the dialogue between the client and the law firm, extracts the NeedFingerprint, constructs an EvidenceGraph (five-tuples and credibility), generates LegalMapping (a traceable citation chain of facts to legal provisions / precedents), performs G0 double-blind conflict pre-detection and generates a ConflictReport, and generates a SupplementTicket and reason code when the criteria are not met.

[0073] S3 Dual Thresholds and Progressive Visibility (LLM Calculation and Enforcement Recommendations) LLM calculates S=θ1×θ2×ρ×κ and performs threshold determination and hysteresis control; generates GatePolicy (visibility domain, desensitization and watermark parameters for G0 / G1 / G2), updates AccessTicket and gate_sig; provides ISOLATE / BLOCK suggestions for red-lined items; and records gated events to PSIGEvent.

[0074] S4 A2A2A Agreement and Collaboration Drafting (Full LLM) Under the GatePolicy constraint, LLM sequentially completes Debate, Deliberation, and Synthesis: producing a neutral summary package (dispute matrix, strategy tree, win rate / cost / time intervals and AFA segmentation); generating the first draft of the document and cross-law firm response cards (paragraph-level source binding, comparability and difference highlighting); updating the maturity coefficient κ and forming a pre-export checklist.

[0075] S5 Takeover and Export (LLM-Rank and LLM-Redact) LLM calculates the takeover order: R = α·S + β·diff - δ·risk + γ·availability; It generates a HandoverTicket and an Agenda; it desensitizes / rewrites / compresses and assembles the AnonEnvelope according to the export strategy using LLM; it exports after PEP-Export verification; and it writes the takeover and export events to PSIGEvent, supporting a two-minute replay.

[0076] 2. Modular program units (M1–M10) M1 LLM-Role & Delegation. Generates RoleVector, parses DelegationChain, and produces an AccessTicket draft (scope / ttl / watermark); contains LLM-Gen and LLM-Check. M2 LLM-Policy & Session. Generate and maintain sess_id / window_id / policy_hash, instrument PEP, and execute policy canary rollout and consistency rewriting; M3 LLM-Need / Evidence. Extract NeedFingerprint, construct and annotate EvidenceGraph, and generate SupplementTicket if necessary; M4 LLM-LegalMapping.IRAC issue decomposition, retrieves and outputs LegalMapping and traceable reference chains; M5 LLM - Conflict & Ethics. G0 double-blind conflict retrieval and pre-exit review of UPL / license / sanctions / privacy, resulting in a Conflict Report and handling recommendations; M6 LLM-Gating. Calculate S=θ1×θ2×ρ×κ, generate GatePolicy, update AccessTicket / gate_sig, and propose PEP enforcement recommendations; M7 LLM-Draft & Compare generates document drafts and response cards, completes comparability and difference highlighting, and binds paragraph-level sources; M8 LLM-Rank & Handover. Calculate HandoverRank, generate HandoverTicket and Agenda, and provide shortlist and time period suggestions; M9 LLM-Audit (PSIG). Generates PSIGEvents and batch anchored organizations, outputting cause chains and searchable indexes; M10 LLM-Redact & Export. Performs desensitization / rewriting / compression, assembles AnonEnvelope, minimizes data retention and encrypts data to disk, and drives PEP-Export for verification and processing.

[0077] 3. State machine and audit writing (execution summary) The program instructions cause the system to operate according to the following state machine based on commands generated by the LLM: INIT → PROXY_RESOLVE → CLARIFY → LEGAL_MAP → G0_CONFLICT → GATING{FROZEN / G0 / G1 / G2} → DELIBERATE & SYNTHESIZE → HANDOVER_PLAN → REDACT_EXPORT → PSIG_LOG; Any node hitting the red line enters the ISOLATE / BLOCK branch. All critical events are recorded and batch-anchored using PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}.

[0078] 4. Key data objects (generated / consumed by LLM) RoleVector{role_id, similarity_pct, ρ, persona_tags};DelegationChain{principal,agent,scope,ttl,revocable,source_hash};AccessTicket{ticket_id,scope,fields,ttl,watermark_si g,revocable,policy_ref};NeedFingerprint{jurisdiction,forum,language,budget_model,afa_pref,deadline,secrecy,deliverables,milestones} ;EvidenceGraph{nodes,edges,source_map,credibility};LegalMapping{issue→[statutes[],cases{court_level,year,holding,similarity,citations}],citation_links};ConflictReport{salt_set,result,risk_codes};GatePolicy{level,visible_fields,redaction_profile,watermark_params} With gate_sig; HandoverRank / HandoverTicket / Agenda; AnonEnvelope{manifest,summary,norm_diff,doc_bundle,policy_ref,access_rules,watermark_sig,digest_hash}; PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}; rating values ​​θ1, θ2, ρ, κ, S and ranking value R.

[0079] III. Security Primitives / Service Invocation Structure and Boundary Protection Mechanism Explanation

[0080] 3.1 Security Primitives To ensure the minimum visibility domain, auditability, and enforceability of multi-agent dialogue during the project initiation phase, this invention introduces the following security primitives at each stage of the process, generated and verified by a large language model (LLM) collection, upon which the platform enforces the law: Session and policy anchors: sess_id, window_id, policy_ver, policy_hash. Used to bind any invocation to a specific policy version; Tickets and Signatures: AccessTicket{scope,fields,ttl,revocable,watermark_sig,policy_ref}, handover_ticket{scope,ttl,revocable,watermark_sig,gate_ref}, gate_sig (gated signature). Used for unsealing, taking over, and exporting authorization of the least visible field; Gating and Visibility Domain: Scoring values ​​θ1, θ2, ρ, κ and total score S = θ1 × θ2 × ρ × κ, GatePolicy {level ∈ {FROZEN, G0, G1, G2}, visible_fields, redaction_profile, watermark_params}. Used to control step-by-step unblocking and field granularity; Auditing and anchoring: PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}, batch anchoring merkle_root / anchor_receipt. Used for evidence chains that can be reviewed within two minutes. SupplementTicket with Cause Code: SupplementTicket{ttl,cause_codes,items}. Used for "non-degradation supplementation" and loop closure when the threshold is not reached; Anti-replay / idempotency: `idempotency_key` and `challenge_nonce`. Used for cross-call consistency and replay interception; The deployment form (cloud / edge / device) and source (commercial / open source / self-developed) of the large model are not limited; the key lies in the generation, consumption and law enforcement links of the aforementioned primitives.

[0081] 3.2 Service Invocation Structure The three-way intelligent agent dialogue is orchestrated by the platform's LLM, and collaboratively completed by the party's LLM and the law firm's LLM. All calls are routed through policy and enforced by PEP.

[0082] 1. PEP - Plan (Plan in Advance) Input: RoleVector / DelegationChain / AccessTicket, policy_hash; LLM outputs: dialogue outline, checkpoints, minimum visible area hints; Platform enforcement: Verify the consistency between invoices and strategies, and reject unauthorized plans.

[0083] 2. PEP-Chat (Conversational Law Enforcement) Input: GatePolicy, current AccessTicket; LLM outputs: NeedFingerprint, EvidenceGraph, LegalMapping, ConflictReport, and performs de-identification / rewriting in real time; Platform enforcement: Field granularity and watermark application online; red line hits trigger ISOLATE / BLOCK.

[0084] 3. PEP-Export (Exporting Enforcement Laws) Input: Export manifest and AccessTicket / gate_sig / policy_hash / window_id; LLM output: AnonEnvelope (desensitization package); Platform enforcement: Consistency verification and handling actions PASS / REWRITE / DELAY / ISOLATE / BLOCK, generating PSIGEvent fingerprints; Each call is bound by a request-response contract: the request must carry a policy_hash, a valid ticket, and a window_id; the response must include a gate_sig or PSIGEvent fingerprint. Any bypass direct connection, replay, or inconsistent policy is rejected and recorded.

[0085] 3.3 Boundary Enforcement Progressive visibility: Fields can only be progressively unlocked from FROZEN / G0 / G1 to higher visibility domains when S reaches a threshold; the granularity of field access and display is limited by GatePolicy. Double-blind conflict search: During the G0 stage, the search is triggered on the law firm side by adding salt elements. The platform and the other party only exchange necessary summaries to avoid early disclosure of the parties' explicit information. Red lines and compliance: Unauthorized practice (UPL), license geographical restrictions, sanctions / AML, privacy and data export, out-of-order access, ticket forgery, replay and policy drift are all identified by LLM-Check and trigger ISOLATE / BLOCK, the state machine rolls back to FROZEN or freezes sensitive fields; In-situ processing and summary distribution: When regional or privacy restrictions are triggered, the content is processed locally in the local LLM, and only the summary and necessary indexes are distributed. Minimal retention: The original text is not written to disk; the exported text exists only in AnonEnvelope (de-identified, encrypted, TTL, and revocable); all key nodes are written to PSIGEvent and anchored in batches. BYPASS detection: For anomalies such as "no ticket, policy_hash inconsistency, window drift, duplicate paraphrasing / replay", execute BLOCK / DELAY / ISOLATE and output the reason code.

[0086] 3.4 The Role of the Large Model and the Essence of "Agent-to-Agent" Conversation The core of generation and verification: LLM-Gen is responsible for role vector / delegation chain generation, requirement extraction, evidence mapping, legal mapping, threshold scoring, deliberation summary, document drafting, and de-identification rewriting; LLM-Check is responsible for consistency, traceable citation, compliance red lines, unauthorized access and replay verification. The process attributes of intelligent agent dialogue: Under the platform's LLM orchestration, the client's LLM and the law firm's LLM achieve in-depth profiling and deep fit through multiple rounds of question and answer, driving θ1 / θ2 / ρ / κ to gradually improve so that S approaches or crosses the threshold; unblocking and exporting are always jointly constrained by GatePolicy / AccessTicket / PEP / PSIG; Model neutrality and process sovereignty: No self-developed or trained specific models are required; regardless of whether a cloud-based, edge-based, or embedded model is used, as long as the above-mentioned primitive-call-boundary visible domain enforcement and auditing closed loop is implemented, it falls within the technical solution of this invention. Conversely, even if the model is replaced or self-developed, if this process and mechanism are not implemented, it does not constitute equivalence.

[0087] IV. Terminology Definitions and Identification Boundaries

[0088] 4.1 Basic Terminology Large Language Model (LLM): Refers to a generative model capable of performing generation, extraction, rewriting, induction, reasoning, and scoring. An LLM assembly / LLM agent is an orchestration of multiple LLM sub-devices (including the generation unit LLM-Gen and the verification unit LLM-Check), undertaking core functions such as dialogue, extraction, mapping, gating, rewriting, and audit summaries. Agent-to-Agent (A2A): Multi-round generative interactions between LLM agents under policy and ticket constraints; A2A2A (Three-Party Intelligent Agent): A three-party orchestration and dialogue structure consisting of a platform intelligent agent, a client intelligent agent, and a law firm intelligent agent. The platform intelligent agent is responsible for planning, gating, and auditing. Project initiation: The preliminary review and selection stage before formal commissioning / signing, covering material preparation / case reconstruction and initial assessment through mutual consultation; Gating Levels: The visible domain is gradually unlocked according to the gating level, which is FROZEN → G0 → G1 → G2; Dual-threshold takeover: Gating is performed using S=θ1×θ2×ρ×κ; when S reaches the takeover threshold and the ranking R is completed, a real person takeover is triggered, where: θ1-commercial / utility sub-item, θ2-credibility / compliance sub-item, ρ-role confidence level; κ-maturity level.

[0089] 4.2 Strategy and Audit Related Terminology PEP (Policy Execution Point): Three mandatory ticket verification nodes: Plan, Chat, and Export, used for pre-plan verification, chat time-domain enforcement, and export pre-verification. PSIG (Path Signature Chain): An audit chain that is continuously recorded and anchored in batches using PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}; GatePolicy: A gated policy object, containing at least the level (G0 / G1 / G2), visible field set, de-identification configuration, and watermark parameters; gate_sig binds the decision and policy version; Access Ticket / Handover Ticket: An authorization carrier containing scope / fields / ttl / revocable / watermark_sig / policy_ref; Security primitives such as sess_id, window_id, policy_ver, policy_hash, idempotency_key, and challenge_nonce are fundamental elements used for binding, idempotency, and anti-replay.

[0090] 4.3 Data Object Terminology (Produced / Consumed by LLM) RoleVector: {role_id, similarity_pct, ρ, persona_tags} DelegationChain:{principal, agent, scope, ttl, revocable, source_hash} NeedFingerprint: {jurisdiction, forum, language, budget_model, afa_pref, deadline, secrecy, deliverables, milestones} EvidenceGraph: A graph structure and credibility composed of a quintuple of time / location / person / behavior / evidence. Legal Mapping: issue → [statutes[], cases{court_level,year,holding,similarity,citations}] and traceable citation chain ConflictReport: G0 Double-Blind Conflict Search Results and Risk Codes AnonEnvelope: Exported wrapper for {manifest, summary, norm_diff, doc_bundle, policy_ref, access_rules, watermark_sig, digest_hash}

[0091] 4.4 Rigid Indicators (Auditable and Enforceable) Strong binding ≥99% (identity / authorization / qualification) Completeness of required fields must be ≥95% (within TTL). Threshold compliance rate ≥ 97% Blacklists / whitelists / sanctions / mistaken license plate blocking ≤0.5% SLA first shot ≤ 60s (P95) SLA follow-up questioning ≤10s (P95) Asymptotically visible out-of-order behavior = 0 (including derived out-of-order behavior, which is 0). Anchoring coverage ≥ 98% (PSIG events and batch anchoring) Improved takeover accuracy (accurate picks should be interviewed / designated candidates) A review can be completed in ≤2 minutes (from retrieval to presentation of the chain of evidence).

[0092] 4.5 State Machine Terminology Main process: INIT → PROXY_RESOLVE → CLARIFY → LEGAL_MAP → G0_CONFLICT → GATING{FROZEN / G0 / G1 / G2} → DELIBERATE & SYNTHESIZE → HANDOVER_PLAN →REDACT_EXPORT → PSIG_LOG Red line branches: ISOLATE / BLOCK (unauthorized practice, sanctions / AML, privacy and cross-border issues, forgery / replay of documents, inconsistent policies, etc.)

[0093] 4.6 Pseudo-fusion anti-bypass and boundary identification The model is neutral but functionally rigid: it is not limited by vendor, architecture, training, or deployment type (cloud / edge / device / embedded); however, it must be generated / verified by an LLM to complete any two or more of the following core functions: role and delegate resolution, requirement / evidence extraction, legal mapping, threshold scoring and gating, deliberation summary and document drafting, and de-identification rewriting and export auditing. Meeting these requirements constitutes a valid technical solution of this invention. Pseudo-fusion does not constitute circumvention: Repackaging rules / retrieval / traditional NLP as a "fusion model" or replacing it with a "self-developed / trained / edge chip model" is considered part of this solution as long as LLM is used to perform the aforementioned core functions in the process; merely replacing the generation and verification of LLM with rules / keywords / retrieval does not constitute equivalent implementation. The essential constraint of peer-to-peer chat: Under the constraints of PEP / ticket / gating and PSIG, peer-to-peer intelligent agents (LLM ensemble) are in an iterative process of improving θ1 / θ2 / ρ / κ and reaching the threshold S; direct access and export that bypass this process are considered out of order.

[0094] V. Explanation of Path Control and Abnormal Detour Blocking Mechanism

[0095] 7.1 Path Control Architecture The chat and export functionality of this invention is only allowed to execute along whitelisted paths. These paths are generated by the Large Language Model (LLM), which the platform uses for enforcement, and are constrained by policy_hash / window_id and ticket. Core link: The process involves PLAN → CHAT → EXPORT, with three policy execution points set at PEP-Plan, PEP-Chat, and PEP-Export. Requests at any stage must carry a valid AccessTicket / gate_sig and be consistent with the current GatePolicy and policy_hash.

[0096] 5.2 Enforcement Elements Identity and session anchors: sess_id / window_id / policy_ver / policy_hash; Authorization Ticket: AccessTicket / HandoverTicket{scope,fields,ttl,revocable,watermark_sig}; Gating parameters: GatePolicy{level,visible_fields,redaction_profile,watermark_params} and gate_sig; Audit log: PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason}; LLM roles: LLM-Check is responsible for detection and treatment recommendations, while LLM-Gen is responsible for necessary immediate rewriting / desensitization and minimization of feedback.

[0097] 5.3 Abnormalities and Detour Patterns (Key Judgment Points) The determination made by LLM-Check at the PEP execution point includes at least the following: Direct access without a ticket: Missing / expired AccessTicket or gate_sig; Policy inconsistency: The policy_hash is inconsistent with the request declaration or the current policy on the server. Out-of-order access: Requesting a visible domain or export from FROZEN / G0 / G1; Time window drift: window_id expires, rollback, or replay across windows; Replay / idempotency conflict: Reuse idempotency_key or message hash to match historical receipts; Field out of bounds: The requested field exceeds GatePolicy.visible_fields or is outside the exported list; Cross-domain violations: restrictions on geographical practice / licenses, sanctions / AML, privacy and data export violations; Injection and Bypass: Hints at injection-induced leakage, external link jumps bypassing PEP, and parallel side channels; Forged / tampered with invoices: watermark_sig and gate_ref verification failed.

[0098] 5.4 Treatment and Recovery (1) BLOCK: Reject the request and terminate the current branch; record the reason code; (2) ISOLATE: Enters isolated state, returning only minimal error receipts and compliance prompts; freezes sensitive fields; (3) DELAY: Delay receipt before triggering manual / secondary verification; (4) REWRITE / REDACT: Rewritten or desensitized by LLM-Gen in real time and then returned; (5) FALLBACK (optional): Degrade to a lower visibility domain or publish the abstract outside the peer group; Recovery conditions are generated by LLM-Check and include at least: ticket update, policy alignment, time window reset, and re-gating evaluation. Each action is written to a PSIGEvent and associated with the merkle_root.

[0099] 5.5 Enforcement Procedures (Summary) (1) PEP-Plan: Verify AccessTicket / policy_hash → If an anomaly is found, block / isolate; if it passes, issue the chat outline and verification points; (2) PEP-Chat: Apply field granularity, watermarking and desensitization on-site according to GatePolicy; detect out-of-order, injection, cross-domain violations and time window drift → trigger corresponding handling; if successful, generate structured results and update gate_sig; (3) PEP-Export: Verify the consistency between the exported list and AccessTicket / gate_sig / policy_hash / window_id → If it passes, issue AnonEnvelope; otherwise, BLOCK / ISOLATE / REWRITE.

[0100] 5.6 Guarantees and Boundaries (1) Only whitelisted paths are accessible: Any output is considered invalid and blocked without going through the PEP and ticket link; (2) Progressive visibility strong constraint: Higher visibility domains cannot be unsealed until the threshold S is reached; the field and display granularity are based on GatePolicy; (3) Minimum retention: The original text is not copied to disk, and the exported text is only saved in AnonEnvelope format. It can be cancelled when the TTL expires. (4) Two-minute review: All actions and anomalies form a complete PSIGEvent chain, ensuring that evidence and strategy basis are located within the specified time; The aforementioned mechanisms, methods, and system modules work together to ensure that the chat process is guided by policy constraints, has detectable and blocking capabilities for anomalies, and forms auditable, traceable, and executable boundaries.

[0101] VI. Beneficial Effects (1) Enhanced certainty of roles and authorization: The RoleVector / DelegationChain generated by the LLM conversation clarifies the subject / agent / scope / term, supporting subsequent gating and compliance judgment; (2) Fact-Law Traceability: EvidenceGraph×LegalMapping establishes a three-way mapping and citation chain of facts, legal provisions and precedents to support audit review and consistency verification; (3) Secure conflict retrieval and progressive visibility: G0 double-blind conflict pre-detection and GatePolicy granular control reduce the risk of early leakage and achieve "only the line is reached and the level is gradually unblocked"; (4) Comparability of materials and availability of the first draft: The comparability of the neutral summary package, document first draft and response card generated by the LLM consensus improves the efficiency and quality of the comparison; (5) Closed-loop audit and compliance enforcement: The three ticket verification points of PEP-Plan / Chat / Export and the PSIG path signature chain realize end-to-end traceability and support rapid review; (6) Quantitative controllability: Driven by S=θ1×θ2×ρ×κ and takeover order R, and combined with rigid indicators such as strong binding, integrity, consistency of achievement, SLA, zero overstepping, and anchor coverage, the engineering implementation is realized; (7) Necessity of LLM: Demand extraction, evidence mapping, legal mapping, threshold scoring, deliberation summary, document drafting and desensitization rewriting all rely on the generation and verification capabilities of LLM. Non-generative solutions are difficult to achieve the same effect. Attached Figure Description

[0102] Figure 1 : Schematic diagram of the overall framework of the method and system of this invention (S1–S5 × M1–M10).

[0103] Figure 2 S1 Role and Delegation Initialization Flowchart.

[0104] Figure 3 S2 / S4 A2A and A2A2A Arrangement and Fact-Law Mapping Flowchart.

[0105] Figure 4 S3 Dual Threshold Gating and Progressive Visibility Schematic Diagram.

[0106] Figure 5PEP Three Execution Points and Path Control / Abnormal Detour Blocking Diagram.

[0107] Figure 6 S5 Desensitization Export and Packaging Structure Diagram. Detailed Implementation

[0108] To make the objectives, technical solutions, and beneficial effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. This invention is not limited to the specific embodiments described below; any equivalent substitutions or improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0109] Example 1 (Method Example – Preliminary Review of Labor Dispute “Wage Arrears”)

[0110] S1 Role and Delegation Initialization (LLM-led) S1.1 Generate RoleVector{"Worker with unpaid wages", similarity_pct, ρ} through LLM three-way decision-making; if a colleague inquires on behalf of the worker, parse DelegationChain{principal=worker, agent=colleague, scope=preliminary inquiry, ttl=7d, revocable=true}, and issue the minimum visible field AccessTicket{scope=summary level, fields=[month interval, amount interval], ttl=48h, watermark_sig=…}; S1.2 Solidify sess_id / window_id / policy_hash, register PEP-Plan / PEP-Chat / PEP-Export; record the genesis PSIGEvent.

[0111] S2 A2A Clarification and Fact / Requirement Modeling (LLM×LLM Dialogue, Platform LLM Orchestration) S2.1 Extract NeedFingerprint{forum=Labor Arbitration Priority, jurisdiction=Local Arbitration Commission, language=Chinese, budget_model=AFA+Cap, deadline=T+30d, secrecy=L2}; S2.2 Structured EvidenceGraph: Nodes contain attendance records, pay slips, transfer vouchers, overtime schedules, and witness contact information; edges contain "time-behavior-evidence" associations and are labeled with credibility; S2.3 Generate LegalMapping: Map relevant clauses of the Labor Contract Law with local arbitration precedents to establish a paragraph-level traceable citation chain; S2.4 In G0, a double-blind conflict retrieval triggered by the salted elements {employer hash, industry code, district / county, time window} yields a ConflictReport{result=no_hit, risk_codes=[]}; the evidence gap is marked by SupplementTicket{ttl=72h, items=[social security payment records, overtime approval flow]}.

[0112] S3 Dual Thresholds and Progressive Visibility (LLM Calculation and Enforcement Recommendations) S3.1 LLM calculation: S = θ1(clarity / urgency / value / evidence completeness / jurisdictional matching) x θ2(conflict clarity / license region / sanction AML / privilege confidentiality / PIG consistency / SLA) x ρ x κ, the result reaches G1; generate GatePolicy{level=G1, visible_fields=[evidence catalog summary, amount range, time range], redaction_profile=strong desensitization, watermark_params=…}, update gate_sig / AccessTicket; S3.2 The red line was not met; the unmet item will not be downgraded and the SupplementTicket will be retained.

[0113] S4 A2A2A Agreement and Collaboration Drafting (Full LLM) S4.1 Debate→Deliberation→Synthesis: Form a neutral summary package, providing a matrix of disputes (establishment of labor relations, facts of wage arrears, disputes over working hours), a strategy tree (arbitration→mediation→litigation), and win rate / time / cost ranges and AFA segmentation suggestions; S4.2 Generate the first draft of the documents: arbitration application, list of evidence and explanation of evidence; cross-law firm response card comparability (similar case experience, expected timeframe, and maximum cost).

[0114] S5 Takeover and Export (LLM-Rank and LLM-Redact) S5.1 Calculate the takeover order: R = α·S + β·diff - δ·risk + γ·availability; Output the shortlist and HandoverTicket{scope=G1, ttl=24h, watermark_sig=…},Agenda{topics=[evidence reinforcement, AFA limit, mediation window]}; S5.2 Based on GatePolicy, desensitize / rewrite and assemble AnonEnvelope{manifest, summary, norm_diff, doc_bundle, policy_ref, access_rules, watermark_sig, digest_hash}, and export it after PEP-Export verification; takeover and export events are written to PSIGEvent and batch anchored.

[0115] Example 2 (System Example – System Configuration Compatible with Example 1) M1 LLM-Role & Delegation: Outputs RoleVector{"Workers with unpaid wages", …}; parses DelegationChain; generates a minimum visible AccessTicket draft (digest-level field, short TTL, strong watermark); M2 LLM-Policy & Session: Generate sess_id / window_id / policy_hash; Instrument PEPs in Plan / Chat / Export; Policy canaryization and consistency rewriting ensures alignment with GatePolicy; M3 LLM-Need / Evidence: Extract NeedFingerprint; Construct EvidenceGraph and evaluate credibility; Generate SupplementTicket; M4 LLM-LegalMapping: IRAC decomposition generates a LegalMapping of labor contract law provisions and local arbitration precedents, binding paragraph-level references; M5 LLM-Conflict & Ethics: Triggers a double-blind conflict search in G0 using salted employer factors, outputting a ConflictReport; simultaneously performs pre-checks for professional practice / license / privacy travel abroad; M6 LLM-Gating: Calculate S=θ1×θ2×ρ×κ, determine to G1; generate 6atePolicy{visible_fields=[amount range, time range, evidence catalog summary], redaction_profile=strong desensitization}; update gate_sig / AccessTicket; M7 LLM-Draft & Compare: Generates a first draft of the arbitration application and a list of evidence; outputs a comparable view of cross-law firm response cards with highlighting of differences. M8 LLM-Rank & Handover: Calculate HandoverRank; generate HandoverTicket / Agenda, and allocate takeover time windows and participant roles; M9 LLM-Audit (PSIG): Generates PSIGEvent{seq,ts,prev_hash,event_hash,policy_hash,actor,decision,reason} at key nodes S1–S5 and anchors them in batches, supporting review within two minutes; M10 LLM-Redact & Export: Performs desensitization / rewriting / compression, assembles AnonEnvelope; exports after verifying the consistency of AccessTicket / gate_sig / policy_hash / window_id in PEP-Export; minimum retention and TTL / reversible policies take effect.

[0116] Data flow / state machine (scenario-based): INIT→M1→M2→M3→M4→M5→M6(G1)→M7→M8→M10→M9; If any node hits the red line, M5 / M6 triggers ISOLATE / BLOCK and falls back to FROZEN; The core data objects include RoleVector / DelegationChain / AccessTicket / NeedFingerprint / EvidenceGraph / LegalMapping / ConflictReport / GatePolicy / gate_sig / HandoverTicket / AnonEnvelope / PSIGEvent, which meet the requirements for the generation, consumption and auditing of the claims.

[0117] Example 3 (Storage Medium Example) This embodiment provides the instruction execution flow of a computer-readable storage medium. Medium contents: Stores program instructions used to invoke LLM-Gen and LLM-Check. These instructions, when executed by the processor: 1) Execute S1: Generate RoleVector, parse DelegationChain, generate AccessTicket, solidify sess_id / window_id / policy_hash and register PEP, and record the genesis PSIGEvent; 2) Execute S2: orchestrate A2A conversations, generate NeedFingerprint / EvidenceGraph / LegalMapping, complete G0 double-blind conflict retrieval and ConflictReport, and issue SupplementTickets if necessary; 3) Execute S3: Calculate S=θ1×θ2×ρ×κ, generate Gatepolicy, update gate_sig / AccessTicket, provide ISOLATE / BLOCK for the red line and write it to PSIGEvent; 4) Execute S4: Complete Debate → Deliberation → Synthesis, produce a neutral summary package, strategy tree, AFA recommendations, document first draft and comparable response card, and update κ; 5) Execute S5: Calculate R and generate HandoverTicket / Agenda; rewrite and assemble AnonEnvelope by desensitizing it according to GatePolicy; export it after PEP-Export verification; write the takeover and export events to PSIGEvent and batch anchor them.

[0118] Execution Guarantee: All PEP nodes must verify the consistency between AccessTicket / gate_sig / policy_hash / window_id and the exported list; any out-of-order, replay, or policy inconsistency will be determined by LLM-Check and trigger BLOCK / ISOLATE / DELAY / REWRITE processing; the audit chain PSIGEvent ensures that it can be reviewed within two minutes.

[0119] Example 4 (Method Example – Preliminary Examination of Pre-litigation Injunction for Trademark Infringement on E-commerce Platforms)

[0120] S1 Role and Delegation Initialization (LLM-led) The system generates a RoleVector{"Trademark Rights Holder Representative", similarity_pct, ρ} through a three-way determination; it parses the DelegationChain{principal=Rights Holder, agent=Brand Rights Protection Service Provider / Legal Affairs, scope=Project Pre-examination + Pre-trial Injunction, ttl=7d, revocable=true}; it issues a minimum visible field AccessTicket{scope=Summary Level, fields=[Platform List, Category, Suspected Link Count Range], ttl=48h, watermark_sig=…}; it solidifies sess_id / window_id / policy_hash, registers PEP-Plan / Chat / Export, and records the genesis PSIGEvent.

[0121] S2 A2A Clarification and Fact / Requirement Modeling (LLM×LLM Dialogue, Platform LLM Orchestration) Extract NeedFingerprint{forum=Pre-trial injunction+Platform removal synchronization, jurisdiction=Intellectual Property Court candidate, language=Chinese and English, budget_model=AFA+Preservation special, deadline=T+3~7d,secrecy=L2}; Constructing an EvidenceGraph: Registration certificate / approval notice, specified category, screenshots of the links involved (including timestamps / platform order numbers), test samples and logistics vouchers, comparison chart (identifier similarity / confusing probability), and historical complaint handling records; Generate LegalMapping: Trademark Law / Civil Procedure Preservation Clauses, Platform Intellectual Property Policy and Precedents (Requirements for Injunction Issuance); In G0, a double-blind conflict retrieval is triggered using the salted elements {the accused store's hash, platform ID_hash, category, region} to generate a ConflictReport; SupplementTicket{ttl=72h, items=[purchase payment voucher, customs registration certificate, approximate comparison matrix]} is generated for the missing items.

[0122] S3 Dual Thresholds and Progressive Visibility (LLM Calculation and Enforcement Recommendations) Calculate S = θ1(clarity / urgency / value / evidence completeness / jurisdictional matching) x θ2(conflict clarity / license region / sanction AML / privilege confidentiality / PSI consistency / SLA) x ρ x κ, and determine to G1 or G2; generate GatePolicy{level, visible_fields=[link summary / sales range / comparison matrix summary], redaction_profile=strong desensitization, watermark_params=…}, update gate_sig / AccessTicket; output ISOLATE / BLOCK for red lines such as malicious complaint risk, cross-border evidence export, and platform rule circumvention and write to PSIGEvent.

[0123] S4 A2A2A Agreement and Collaboration Drafting (Full LLM) Debate→Deliberation→Synthesis: Form a neutral summary package (points of contention: trademark validity, similarity and confusion, malicious evidence, urgency); strategy tree (platform complaint removal / review → pre-trial injunction → formal prosecution; parallel customs filing / border inspection interception), giving the win rate / time / cost range and AFA segmentation; Generate the first draft of documents: platform complaint form template, lawyer's letter / cease infringement notice, pre-trial injunction application and evidence list; output comparable cross-law firm response cards (injunction issuance experience, average issuance time, deposit range, platform integration channels).

[0124] S5 Takeover and Export (LLM-Rank and LLM-Redact) Calculate the takeover ranking R = αS + β·banning experience / platform resources - δ·compliance risk + γ·hosting schedule, and output a short list and HandoverTicket{scope=G1 / G2, ttl=24h, watermark_sig=…}, and Agenda{topics=[margin calculation, evidence notarization / acceptance, platform parallel strategy]}; Anonymize / rewrite and assemble AnonEnvelope{manifest, summary, norm_diff, doc_bundle(complaint / injunction request / comparison matrix / evidence catalog), policy_ref, access_rules, watermark_sig, digest_hash} according to GatePolicy, and export it after PEP-Export verification; takeover and export events are written to PSIGEvent and batch anchored.

[0125] Example 5: Preliminary review of cross-border divorce and property division projects S1: RoleVector{“divorced husband”, similarity_pct, ρ}; DelegationChain marks the proxy permissions and TTL for overseas relatives; S2: Extract NeedFingerprint (foreign jurisdiction, language, confidentiality level, temporary injunction requirement); construct EvidenceGraph (marriage registration, real estate / equity / trust structure, joint debt); LegalMapping covers foreign procedural law, property division and custody precedents; G0 double-blind conflict search only exchanges salted subjects and regions; S3: Gated to G1, GatePolicy restricts asset details to only range display; when privacy is violated when data is transferred out of the country, "on-site processing + summary transmission" is enabled; S4: The collegial panel forms a strategy tree (three paths: divorce by agreement / litigation / preservation), generating the first draft of the application for a preliminary injunction and the complaint; the comparable response card standardizes the division ratio range, custody arrangements and timeline; S5: Output HandoverTicket / Agenda, export AnonEnvelope (watermark can be revoked); Results achieved: Minimizes cross-border data export in privacy-critical scenarios, ensures traceable citations and document first drafts, and improves comparison accuracy; Inadequacy of existing technology: Existing systems are unable to generate the first draft of documents for cross-border privacy enforcement, hierarchical visibility domains, and dialogue-based consensus before project initiation.

[0126] Example 6: Preliminary Review of Antitrust Application for Cross-border Mergers and Acquisitions S1: RoleVector{“Merger Buyer’s Representative”, similarity_pct, ρ}, the authorization chain includes external financial advisor agents; S2: Extract NeedFingerprint (target jurisdiction DE / FR, M&A size range, bilingual requirements, milestone T+60); EvidenceGraph: estimate CIM / equity structure / market share; LegalMapping: generate relevant market definition, centralized filing thresholds, and EU / member state precedents; G0: double-blind conflict search to avoid premature exposure of counterparties; S3: If the score reaches G1, the GatePolicy will be open to details of restrictions and shortlisted law firms for discussion; if the score is not reached, a SupplementTicket will be used to supplement the market share calculation method and data source; S4: Deliberation output strategy tree (simplified / normal procedure / remedial commitment), win rate and time range, AFA segmentation; generate application material framework and question list; comparability of response cards from multiple law firms (team experience, similar case cycles, commitment plan experience). S5: Output HandoverRank / HandoverTicket and export AnonEnvelope for the approval process; Achieved results: Under the constraints of transaction confidentiality, the mapping between the market and legal provisions, the selection of procedures and the drafting of commitment strategies are completed, achieving standardized comparison and selection; Current technology is insufficient: conventional DMS / retrieval cannot automate the relevant market definition and program strategy generation in the early stages, and it is even more impossible to achieve double-blind conflict resolution and hierarchical visibility domain enforcement.

[0127] Example 7: Compliance Notification and Cross-Domain Management Project Initiation Pre-approval for Data Breach Incidents S1: RoleVector{“Data Controller Representative”, similarity_pct, ρ}; Authorization chain covers outsourced processors; S2: Extract NeedFingerprint (affected entity size, data type, detection time, cross-border flow); construct EvidenceGraph (intrusion timeline, system logs, handling actions); LegalMapping covers GDPR / Data Security Act / state law notification deadlines and regulatory templates; G0 performs double-blind preliminary conflict investigation on external service providers; S3: The prerequisite for gating to G2 is to complete the data subject type confirmation and risk classification; if not met, maintain G1 and issue a SupplementTicket; for cross-border outbound hits, activate on-site processing; S4: The deliberation generates a neutral summary package (event characterization, impact assessment, notification obligation matrix), and outputs the first drafts of three types of documents: regulatory notices, data subject notices, and media statements; the comparable response card lists the response time commitments and resource allocations. S5: Calculate R and generate HandoverTicket; export AnonEnvelope (including timeline and evidence fingerprint), PSIG can replay within two minutes; Achieved results: Realize the mapping of legal jurisdictions, the obligation matrix, and the first draft of three types of documents within the emergency window, ensuring timeliness compliance and auditability; Current technology is inadequate: traditional work orders and compliance ledgers cannot achieve rapid cross-domain regulation mapping and traceable citation, nor do they have the ability to hierarchically visible domains and instant de-identification and rewriting.

[0128] Example 8: Preliminary Review of Arbitration Path for International Engineering Contract Disputes S1: RoleVector{“EPC contractor”, similarity_pct, ρ}, the proxy chain includes the resident project manager; S2: Extract NeedFingerprint (candidate arbitration venue / institution, language, amount range, progress claims / change disputes); EvidenceGraph (contract terms, change orders, progress records, correspondence); LegalMapping: Map arbitration rules, applicable law, and similar awards; G0: Preliminary check for conflicts of interest with the owner's agency; S3: Gated to G1, allowing access to restricted details and shortlisted chats; generates GatePolicy to display only the amount range and terms summary; S4: Deliberation output strategy tree (negotiation / mediation / arbitration), win rate and cost range, AFA segmentation; generate the first version of the arbitration notice and claim details form; comparability of response cards (rule experience, technical expert database, past rulings). S5: Output HandoverRank / HandoverTicket, export AnonEnvelope; PSIG record; Achieved outcome: Complete rule selection, strategy and document drafting without revealing key information about the opponent, and quickly proceed to takeover interviews and awarding contracts; Insufficient technology: Existing tools cannot automatically complete the traceable mapping and standardized comparison of contract terms, arbitration rules, and award precedents.

[0129] Conclusion: The above scenario examples all demonstrate that, under the constraints of PEP and GatePolicy, the three-party intelligent agents complete a closed loop through LLM dialogue: deep profiling, fact modeling, legal mapping, dual threshold gating, deliberation drafting, ranking takeover, de-identification export, and PSIG auditing. The achieved double-blind conflict retrieval, hierarchical visibility domain enforcement, traceable citation, and comparable document first draft are features not available in traditional rule systems, retrieval tools, or manual communication.

Claims

1. A method for pre-screening and dual-threshold gating of third-party intelligent agents for legal service project initiation based on a large language model, characterized in that, include: (a) Role and Delegation Initialization (S1): The Large Language Model (LLM) is invoked to perform three-way role determination (self-selection, pre-selection comparison, and delegation chain recognition), generating RoleVector{role_id, similarity_pct, ρ}, parsing DelegationChain{scope, ttl, revocable} and forming an AccessTicket proposal with the minimum visible domain; sess_id / window_id / policy_hash is fixed, PEP-Plan / PEP-Chat / PEP-Export is registered, and the genesis PSIGEvent is recorded; (b) A2A Clarification and Fact / Need Modeling (S2): The platform LLM orchestrates the conversation between the client LLM and the law firm LLM, extracts the NeedFingerprint, constructs an EvidenceGraph containing a five-tuple of time / location / person / behavior / evidence and credibility, generates a LegalMapping with a paragraph-level traceable citation chain, performs double-blind conflict retrieval of salted elements at the G0 level to obtain a ConflictReport, and generates a SupplementTicket{TTL,cause_codes} if the minimum requirements are not met; (c) Dual Thresholds and Progressive Visibility (S3): The comprehensive score S = θ1 × θ2 × ρ × κ is calculated by LLM, where θ1 is the utility parameter, θ2 is the compliance parameter, ρ is the role confidence level, and κ is the maturity level; the state is mapped to FROZEN / G0 / G1 / G2 according to the threshold and hysteresis policy, and GatePolicy{level, visible_fields, redaction_profile, watermark_params} is generated and AccessTicket and gate_sig are updated; ISOLATE / BLOCK suggestions are output for red lines such as professional practice / license / sanctions / privacy travel / order violations, and gate control decisions are recorded with PSIGEvent; (d) A2A2A Deliberation and Collaborative Drafting (S4): Under the constraints of GatePolicy, the three parties conduct deliberation in the order of Debate→Deliberation→Synthesis. The LLM generates a neutral summary package (including the dispute matrix, strategy tree, win rate / time / cost range and AFA segmentation), generates the first draft of the document and comparable response card, and performs paragraph-level source binding and difference highlighting. The maturity coefficient κ is updated and an export pre-check list is formed. (e) Takeover and Export (S5): The LLM calculates the takeover order R=αS+β·differentiation-δ·compliance risk+γ·schedule availability, and generates the HandoverTicket and Agenda; according to the GatePolicy, it performs desensitization / rewriting / compression and assembles AnonEnvelope{manifest, summary, norm_diff, doc_bundle, access_rules, watermark_sig, digest_hash}, and exports it after PEP-Export verification. The takeover and export events are written to PSIGEvent to complete the batch anchoring.

2. A system for implementing the method of claim 1, comprising modules with embedded LLM-Gen and LLM-Check: M1 LLM-Role & Delegation generates RoleVector, parses DelegationChain, and produces an AccessTicket draft; M2 LLM-Policy & Session generates and maintains sess_id / window_id / policy_hash, and instrumentes PEP; M3 LLM-Need / Evidence: Extract NeedFingerprint, construct and annotate EvidenceGraph; M4 LLM-LegalMapping performs IRAC decomposition and constructs a traceable reference chain; M5 LLM-Conflict & Ethics, performing G0 double-blind conflict search and compliance pre-check; M6 LLM-Gating calculates S and generates GatePolicy, and updates gate_sig / AccessTicket; M7 LLM-Draft & Compare generates document drafts and comparable response cards; M8 LLM-Rank & Handover: Calculate HandoverRank and generate HandoverTicket / Agenda; M9 LLM-Audit(PSIG) generates PSIGEvents and batch anchors organizations; M10 LLM-Redact & Export performs desensitization / rewriting / compression and assembles AnonEnvelope.

3. A computer-readable storage medium having a program stored thereon, wherein the program, when executed by a processor, implements the method of claim 1 and performs the corresponding function through the system module of claim 2.

4. The method according to claim 1, wherein S1 determines roles through three methods: self-selection, preset comparison, and delegation chain identification; LLM outputs RoleVector{role_id, similarity_pct, ρ}, and increases ρ when the delegation chain is complete and consistent with the narrative.

5. The method or system according to claim 1 or 2, wherein the AccessTicket / HandoverTicket at least includes scope, fields, ttl, revocable, watermark_sig, policy_ref, and the gate signature gate_sig is bound to policy_hash / window_id for visible domain enforcement and audit verification.

6. The method or system according to claim 1 or 2, wherein NeedFingerprint includes at least jurisdiction, language, budget model, AFA preference, deadline and confidentiality level; EvidenceGraph is modeled and labeled with credibility using a five-tuple of time, place, person, behavior and evidence; and SupplementTicket{TTL,cause_codes} is generated by LLM when the minimum requirements are not met.

7. The method or system according to claim 1 or 2, wherein LegalMapping constructs a fact → legal provision / case mapping based on IRAC issue decomposition, the citation chain includes court level, year, summary, similarity and citation number, and is traceable at the paragraph level.

8. The method or system according to claim 1 or 2, wherein the gating determines S based on thresholds T0, T1, and T2 and maps it to FROZEN / G0 / G1 / G2, the LLM generates a hysteresis window and a minimum hold time, and the GatePolicy contains at least visible_fields, redaction_profile, and watermark_params.

9. The method or system according to claim 1 or 2, wherein the Debate→Deliberation→Synthesis of A2A2A produces a neutral summary package, a dispute matrix, a strategy tree (including win rate / time / cost range and AFA segmentation suggestions), a document first draft, and a comparable response card, and highlights the source and differences of paragraphs.

10. The method or system according to claim 1 or 2, wherein the AnonEnvelope{manifest, summary, norm_diff, doc_bundle, access_rules, watermark_sig, digest_hash} assembled by LLM is exported, PEP-Export verifies the consistency of AccessTicket / gate_sig / policy_hash / window_id and records PSIGEvent, and completes batch anchoring and TTL / revocable policy.

Images