Multi-model collaborative AI substitute chat marriage matching method and system based on dynamic personality and threshold value takeover, and storage medium

Abstract

The invention discloses a multi-model collaborative AI substitute chat marriage matching method and system based on dynamic personality and threshold takeover, and a storage medium. And collecting hard / soft information to generate an initial personality vector, and backfilling evidence with RFI + TTL in substitute chat to dynamically update the personality. Hard filtering and soft sorting are firstly carried out, threshold value compatibility screening is carried out, then an AI substitute chat sandbox is entered, the AI is obviously identified, and contact information / external links / PII are prohibited. The scoring device continuously calculates bidirectional scores SAB and SBA, weights of sensitive attributes are reduced, fair constraints are applied, and explainable evidences are output. And only when the two-way scores simultaneously reach a threshold value, a real person is triggered to take over and exit from the substitute chat domain, and substitute chat records and selectable contact information are opened through secondary grading agreement. The system modularization realizes identity and privacy management, matching with a threshold state machine, security evidence storage, telemetering and strategy gray level and SDK / API gateway.

Description

Technical Field

[0001] This invention relates to the application of artificial intelligence in online dating and intelligent interaction, particularly in multi-model collaborative human-computer dialogue, user profiling and matching scoring, and privacy and compliance governance. Specifically, it provides a dating matching method, system, and storage medium based on dynamic personality vectors and dialogue-driven updates, covering engineering implementations such as multimodal data processing, security auditing, policy management, and SDK / API access. This technology is applicable to mobile internet, web platforms, and other terminals with computing and communication capabilities, and is not limited to specific large models or frameworks. Background Technology

[0002] Online dating services generally rely on static forms and one-way preferences, making it difficult to reflect the real changes in users during the communication process; data gaps (daily routines, budgets, taboos, values) and "cold start" lead to inefficient matchmaking and high churn.

[0003] While existing platforms have introduced several intelligent functions (such as automatic generation of opening remarks and data optimization), they lack an engineered closed loop of dialogue-driven dynamic personality modeling and two-way threshold determination before human intervention. Common problems include: (1) Matching decisions are not interpretable, and sensitive factors (appearance, income) can easily amplify biases; (2) The boundaries of AI intervention are unclear, lacking mutual consent and clear identification, resulting in high compliance risks; (3) The dialogue records lack minimal retention and auditable evidence, making them difficult to trace; (4) Insufficient management of anti-fraud and diversion methods (transformed contact information, QR codes / short links); (5) Without threshold compatibility filtering and hysteresis, it is easy to cause "low-scoring samples to push high-threshold users" and "critical jitter false triggering".

[0004] In the context of increasingly stringent privacy and compliance requirements, there is an urgent need for a technical solution that ends with "threshold takeover." This solution should ensure authenticity, clear identification, and controllable boundaries, allowing AI to complete the data first. Only when both parties meet the threshold should a human takeover occur. The solution should also have the system capabilities to be explainable, auditable, and rollbackable. Summary of the Invention

[0005] I. Purpose of the Invention 1. Provide a multi-model collaborative AI-assisted matchmaking method, system, and storage medium based on dynamic personality and threshold takeover, establishing a closed-loop process of "AI-to-AI dialogue → dual threshold achievement → real person takeover"; 2. By fusing hard and soft information (multi-role selection, DIY role description), a dynamically updated personality vector (V_t) is generated and continuously updated during the dialogue through the RFI mechanism to achieve dialogue-driven continuous representation; 3. Introduce a hierarchical matching strategy that combines hard filtering, soft sorting, and threshold-compatible filtering. Only initiate proxy chats for objects that meet the matching conditions (S_AB≥T_A and |T_A - T_B|≤ΔT_max) to ensure that the candidate quality is consistent with the threshold. 4. After mutual consent, establish a chat proxy sandbox, clearly identify AI chat proxy, prohibit the exchange of contact information, external links and personal information, and support multi-model collaboration and secure rewriting / downgrading; 5. Construct a two-way scoring system (S_AB / S_BA) to comprehensively evaluate role similarity, interests, lifestyle, dialogue quality, etc., and reduce the weight of sensitive components and impose fairness constraints to support the interpretability of the scores and evidence mapping. 6. Using the achievement of two thresholds as the sole trigger condition, execute threshold takeover and state switching, forcibly switch to a real person's profile picture, and controllably open chat history and contact information based on secondary consent. 7. Achieve auditable traceability through PSIG event chain and batch anchoring, and ensure privacy compliance by combining edge encryption and minimal retention; 8. Design modules such as three mandatory ticket verification points (PEP-PLAN, PEP-CHAT, PEP-EXPORT), policy repository, canary rollback, and SDK / API gateway to ensure the system's deployability, maintainability, and measurability; 9. It is clear that the endpoint of this method is threshold takeover. Real-person dialogue and external platform integration after takeover are not within the scope of this invention.

[0006] II. Technical Solution

[0007] (I) Methods and Procedures

[0008] Step 1: Real Anchor Points and Data Acquisition (Initialization) (S0) This step establishes the correspondence between users and devices, generates an initial personality vector, and initializes the state. The specific operations are as follows: 1. Identity and Device Anchoring: Receive and verify mobile phone verification codes, collect device fingerprints (device ID, system version, network information, etc.), perform liveness detection and document verification (optional), and generate a unique user identifier (uid) and authentication level (verif_level). 2. Certification Level and Badge Generation: Output certification level based on verification evidence (such as liveness, identification documents, education, income, etc.), generate visual badges and record them; 3. Hard information collection and standardization: Collect information such as age, city, income, and education, perform legality and consistency checks, and generate a standardized hard information vector (H0). 4. Soft information collection and role setting: Allows users to select multiple roles and set weights, receives and reviews multimedia descriptions of user-created roles, as well as self-narrated text / voice, and generates a soft information set (S_raw). 5. Vectorization and Initial Personality Generation: The hard information (H0), weighted role vector (R0), and semantic embedding (U0) are fused to generate an initial personality vector (V0), and the confidence score (conf(V0)) and field coverage (cov(V0)) are output. 6. Initialize consent status: Before obtaining explicit authorization, initialize the consent flag for proxy chatting to OFF and record a timestamp; 7. Field governance and modification constraints: Set modification thresholds and review processes for hard information, while modifications to soft information take effect immediately but require verification; 8. Privacy minimization and display control: Use minimization strategies (such as range-based or obfuscated) for sensitive information, and prohibit the storage of precise addresses or company names; 9. Secure storage and integrity verification: Data is stored in encrypted form, generating an immutable event chain and supporting auditing; 10. Errors and Rollback: If the verification fails, perform a downgrade or retain the preset configuration and prompt for modification; 11. Output and Gating: This step outputs the initial personality vector (V0), certification badge, agreement position (OFF), data completeness score (profile_score), etc., as prerequisites for the next step.

[0009] Step 2: Threshold setting and candidate pre-screening (threshold-compatible filtering) (S1) This step is used to establish individual thresholds and perform threshold-compatible filtering after both hard and soft screening to generate a candidate set that meets the preconditions for triggering proxy chat, specifically including:

[0010] 1. Threshold Acquisition and Standardization 1.1 Receive the user-defined individual threshold T_A∈[0,100]. If not set, use the system default value T_default (e.g., 80) and record the source, timestamp, and version number; 1.2 Set a minimum cooling time cooldown_T and a maximum step ΔT_step_max for threshold changes to prevent frequent adjustments from causing fluctuations in the filtering results or circumventing the filtering strategy; 1.3 Persist T_A to the policy repository, generate the configuration fingerprint policy_hash, and write it to the audit chain event THRESHOLD_SET{uid, T_A, ts, policy_hash}.

[0011] 2. Hard Filter 2.1 Based on the user's hard criteria and compliance requirements, perform Boolean filtering on the entire population to obtain set H. Filtering conditions include, but are not limited to: geographical region / commuting radius r≤r_max, age range, marital status / whether or not there are children, education range, income range, industry / work-rest restrictions, platform blacklists / whitelists, and separation of minors; 2.2 Geographic location information should only be matched at a fuzzy granular level (district / commuting radius), and the use of precise addresses should be prohibited; 2.3 Output the bitmap of the hard filtering result and the reason code (such as AGE_OUT_OF_RANGE, REGION_MISMATCH), and record the event HARD_FILTER_APPLIED{uid, |H|, criteria_digest, ts}.

[0012] 3. Soft Rank 3.1 For candidate b in set H, calculate the comprehensive matching score S_AB of individual A for candidate b: S_AB = w1·RoleSim(A,b) + w2·InterestSim(A,b) + w3·LifestyleFit(A,b) + w4·DialogReadiness(b) + w5·Trust(b) - Penalties(b), where w1…w5 are issued by the policy repository; sensitive features (appearance / income, etc.) are downweighted by default and subject to fairness constraints; 3.2 RoleSim calculates V0_A and V0_b based on the output of step one (e.g., cosine similarity + temperature scaling); Penalties include data inconsistencies, insufficient data completeness, and risk signals; 3.3 Generate a sorted list R = sort(H, by=S_AB, desc) and record the event SOFT_SORT_DONE{uid, |R|, weights_digest, ts}.

[0013] 4. Threshold Compatibility Gate 4.1 For each candidate b in R, execute the first threshold: (i) S_AB ≥ T_A. Those that do not meet this are directly excluded; 4.2 For candidates that meet (i), execute the second threshold (dual - threshold compatibility): (ii) The candidate b has a set threshold T_B and |T_A - T_B| ≤ ΔT_max (e.g., 10), otherwise mark it as PENDING_TB and do not push it temporarily; 4.3 Only those that meet both (i) and (ii) enter the candidate pool; for individuals marked as PENDING_TB, enter the pending list and re - evaluate after T_B takes effect; 4.4 Record the event COMPATIBILITY_ENFORCED{uid, kept, dropped_i, pending_j,T_A, ΔT_max, ts}, where dropped_i at least includes the quantity statistics of "excluded due to low scores" (e.g., S_AB < T_A), and the situation of "pushing a user with an 80 - point threshold for a 30 - point match" is prohibited.

[0014] 5. Candidate Pool Generation and Quota Control 5.1 Output the candidate pool C = topK(kept, K, tie_breaker) according to the deduplication rule and rate limit, where tie_breaker uses time / diversity / fairness correction; 5.2 Suppress the objects that have been exposed within the same time window to avoid repeated exposure; perform diverse sampling on similar portraits to prevent a single portrait from dominating; 5.3 Record the event CANDIDATES_EMITTED{uid, |C|, quota, ts} and the consumption of the exposure quota.

[0015] 6. Abnormal and Fallback Strategies 6.1 If C is empty, output WAIT_HINT and "suggestions for relaxing conditions" (e.g., expanding r_max, adjusting ΔT_max, or expanding the interest dimension), but do not automatically modify the user threshold; 6.2 If the user raises the threshold multiple times in a short period, triggering throttling and cooling hints to prevent the strategy from bypassing; 6.3 For candidates with critical threshold fluctuations (|S_AB - T_A| < ε), mark them as BORDERLINE and enter the observation queue for re - evaluation after the data is completed.

[0016] 7. Output and Gating 7.1 Output of this step: Candidate pool C, suspended list PENDING_TB, drop statistics DROP_STATS, policy parameter snapshot {T_A, ΔT_max, weights_digest}, and audit anchor psig_anchor_S2; 7.2 The above output serves as a prerequisite for proceeding to the next step, “Both parties agree to establish a chat proxy sandbox”; no candidate may be pushed or enter the chat proxy process if (i) or (ii) is not met.

[0017] 8. Anti-scratching and compliance requirements 8.1 ΔT_max is a platform-level strong constraint, stored in the policy repository and included in the audit; changes to the threshold and changes to ΔT_max must be recorded with the event and approval source. 8.2 It is prohibited to circumvent compatibility filtering by temporarily lowering and then raising the threshold; risk control marking and cooling should be enabled for T_A rapid oscillation; 8.3 The entire process does not expose highly sensitive fields such as precise address / work unit; only range and non-identifiable information are provided in the sorting interpretation.

[0018] Step 3: Mutual Agreement and Establishment of the Chat Sandbox (S2) This step is used to obtain explicit authorization from both parties for "AI-assisted chat" and to create a controlled session domain, ensuring compliance and auditability regarding authorization, identification, permissions, and record visibility. Specifically, it includes:

[0019] 1. Collection and recording of mutual consent 1.1 Display the consent interface to both parties in the conversation, clearly listing: AI-assisted chat attributes, records are managed by default and are not visible before the double threshold and second consent, contact information and external links are prohibited, and the right to withdraw at any time; 1.2 Collect and verify the consensus bits Consent.ai_chat∈{ON,OFF}, record the source, IP / device fingerprint, timestamp and version number, and generate ConsentRecord; if not all are ON, proceed to the next step. 1.3 Set an expiration period (consent_ttl) and a cooldown period (cooldown_consent) for the consent record. If the consent record is withdrawn during this period, the session will be forcibly terminated. Generate an audit event CONSENT_GRANTED{uid, ts, policy_hash} and write it to the chained evidence storage.

[0020] 2. Sandbox Session Domain Creation and Identification Strategy 2.1 Under the condition that both parties agree to be ON, create a sandbox session instance, assign session_id and sandbox_id, and bind the policy fingerprint policy_hash and threshold parameter snapshot; 2.2 Force the "AI Chatting" prominent label (including icon / watermark / prefix) to be enabled in the conversation UI and message header, and synchronize it to both parties' terminals; the label cannot be turned off, obscured or tampered with by the user or any third party; 2.3 Enable permission whitelist within the session domain: prohibit contact information (phone number, WeChat, email, QR code, etc.) and external links / redirects; attachment type, length, and frequency are subject to policy-based rate limiting; sensitive words and illegal content are blocked by the security gate and a reason code is returned; 2.4 Resource isolation between proxy chat domain and real user domain: Session handles, record storage, visibility policies and export interfaces are all scoped to sandbox_id and must not be accessed across domains.

[0021] 3. Policy loading and route initialization 3.1 The orchestrator loads session policies: model routing, RFI trigger threshold, message rhythm and round limit, detection and interception rules, and anomaly fallback policy; 3.2 Bind the snapshots of both parties' profiles V_A(t0), V_B(t0) and the scoring weight w, record the parameter snapshots and incorporate them into the audit anchor psig_anchor_S2.

[0022] 4. Session Initiation and State Change 4.1 After satisfying 2.1–2.4, set the session state to ACTIVE and generate an audit event AI_CHAT_STARTED{session_id, sandbox_id, ts}; 4.2 The default session storage policy is "encrypted hosting, invisible": records are stored in encryption, and the server only stores the hash and timestamp; without reaching the two thresholds and obtaining secondary consent, neither party may view the full text record.

[0023] 5. Exception and Rollback Handling 5.1 If either side fails to complete authorization within the consent_ttl period, the sandbox will be automatically destroyed and CONSENT_TIMEOUT will be recorded; if one side withdraws or closes the consent bit, the session will be terminated immediately and STOPPED_BY_USER will be generated. 5.2 Upon detecting attempts to bypass the system (such as disguised contact information, obfuscated external links, QR code images, etc.), an interception and alarm are triggered, generating ABUSE_FLAGGED and the handling result (blocking / isolation / downgrading).

[0024] 6. Output and Gating 6.1 Output of this step: session_id, sandbox_id, Consent.ai_chat=ON / ON, policy_hash (policy and parameter snapshot), and audit anchor psig_anchor_S2; 6.2 The above output serves as a prerequisite for proceeding to the next step, “AI-to-AI Chatting and RFI Completion”; if any prerequisite is missing or withdrawn, the system shall not proceed to the next step.

[0025] Step 4: AI-to-AI Chatting and RFI Completion (Dynamic Personality) (S3)

[0026] 1. Session Orchestration Initialization 1.1 Load the snapshots of both parties' portraits V_A(t0), V_B(t0) and the weight parameter w; 1.2 Binding session strategies (message rhythm, round limit, sensitive interception, RFI trigger threshold, abnormal rollback).

[0027] 2. Gap Identification and RFI Generation 2.1 Based on profile coverage, contradiction detection, and matching objectives, an RFI list RFI_k is generated for missing slots (work schedule, budget, dietary restrictions, whether to accept relocation, etc.); 2.2 Set the time limit TTL_k∈{24h,48h} and priority for each RFI_k, and push it to the corresponding user terminal.

[0028] 3. RFI Submission and Form Merging 3.1 Receive user-completed information and perform legality, contradiction, and sensitive word checks; 3.2 Merge and update to structured completion ΔS_k, recording the source, timestamp, and evidence fingerprint; 3.3 Generate and write events RFI_ISSUED{session_id,k,TTL_k} and PROFILE_UPDATED{uid,fields}.

[0029] 4. Dynamic Personality Vector Update 4.1 Based on the dialogue corpus, the completed ΔS_k, and the behavioral signals (response delay, rejection rate, stability), update the following formula: V_t = (1-λ)·V_{t-1} + λ·f(dialogue content, ΔS_k, behavioral signals), where λ∈(0,1) and f is the semantic embedding fusion function; 4.2 When a conflict occurs, perform a consistency check, output the reason code, and reduce the confidence level of the conflict dimension; 4.3 Record update coverage and confidence: cov(V_t), conf(V_t).

[0030] 5. Expiration and Disposal 5.1 If TTL_k expires and is not submitted, mark it as RFI_EXPIRED and apply a penalty (deduction of points or reduction of confidence) to the corresponding scoring dimension. By default, the threshold is not automatically reduced. 5.2 Only when the user explicitly selects "Allow threshold reduction" can the individual threshold be reduced step by step ΔT_step_max according to the policy and included in the audit.

[0031] 6. Boundary and Security Control 6.1 In the chat domain, the exchange of contact information and identifiable information is prohibited. Attempts to bypass the exchange (using modified phone numbers, QR codes, or external links) will be automatically blocked and an alert will be issued. 6.2 DIY characters must be approved before going live; any abuse or violation will result in blacklisting and loss of visibility. 6.3 Session records are encrypted and hosted by default and are not visible; the server only stores the hash and timestamp.

[0032] 7. Abnormalities and Rollbacks 7.1 High-frequency RFI triggers are merged into a one-time form; 7.2 For abnormal chat sessions (prolonged silence, repeated output, violation triggering), downgrade or pause according to the policy, and retain the chat anchor point for recovery.

[0033] 8. Output and Gating 8.1 Output the updated V_A(t), V_B(t), pending RFI queue, coverage / confidence metrics, and audit anchors; 8.2 Serves as a prerequisite input for subsequent scoring and threshold determination.

[0034] 9. Key points for preventing skewing 9.1 Contact information and external links are strictly prohibited during the chat proxy phase; 9.2 The expiration of RFI only affects the score / confidence level. Unless the user explicitly agrees, the system shall not automatically lower the threshold. 9.3 Unapproved DIY characters are not allowed to participate in matchmaking calculations or chat on behalf of others.

[0035] Step 5: Two-way scoring and threshold determination (interpretable) (S4)

[0036] 1. Scoring Input and Update Beat 1.1 Within the rolling evaluation window W_k, receive feature snapshots {V_A(t), V_B(t), RFI status, security event summary, authentication level, data consistency flag} generated by session and profile updates; 1.2 Calculate the scores S_AB(k) and S_BA(k) for both sides using a fixed rhythm or a trigger-based method (data completion / profile update / round completion).

[0037] 2. Scoring Model and Weighted Fingerprint 2.1 Define the comprehensive score: S = w1·RoleSim + w2·InterestSim + w3·LifestyleFit + w4·DialogQuality + w5·Trust - Penalties; 2.2 Generate and persist the weighted fingerprint weights_digest = H(w1…w5, policy_ver) to ensure that it can be restored in subsequent audits.

[0038] 3. Component Calculation Rules 3.1 RoleSim: Based on the vector similarity (cosine / Mahanobis distance) of V_A(t) and V_B(t), temperature scaling and hysteresis suppression are performed; 3.2 InterestSim / LifestyleFit: Based on the matching degree of interest tags, daily routines and lifestyle constraints, a gap penalty is used to deal with incomplete slots; 3.3 DialogQuality: A composite indicator based on politeness, reciprocity, information increment, emotional stability, and topic progression; 3.4 Trust: Generated based on certification level, historical risk signals, RFI completion rate, and consistency verification results; 3.5 Penalties: These include penalties for data discrepancies, RFI timeouts, violation triggers, and abnormal similarity jumps.

[0039] 4. Weighting of Sensitive Features and Fairness Constraints 4.1 For sensitive features such as appearance / income, a default weighting coefficient β_sens≤β_max is set, and the contribution ratio of these features is limited to contrib_sens≤α_sens_max; 4.2 Output the sensitivity contribution metric sens_ratio and the fairness constraint enforcement flag as part of the interpretable results.

[0040] 5. Smoothing and jitter control 5.1 Applying exponential smoothing and window hysteresis to S_AB(k) and S_BA(k): S smooth (k)=γ·S(k) + (1-γ)·S smooth (k-1); The threshold condition is met only when n consecutive windows satisfy the threshold condition to avoid critical jitter. 5.2 Samples with abnormal jumps (|S(k)-S(k-1)|>θ) are entered into the manual review channel.

[0041] 6. Interpretable output and evidence binding 6.1 Generate a breakdown report for each update: {Dimension Score, Weight Snapshot, Sensitive Contribution, Penalty Item List}; 6.2 Bind evidence fragments (segment ID, RFI response fingerprint, timestamp) to form an evidence map and output the event SCORE_UPDATED{session_id, S_AB, S_BA, weights_digest, sens_ratio, ts}.

[0042] 7. Threshold Determination Logic 7.1 Let the user thresholds be T_A and T_B respectively; S_A and T_B are defined as follows: smooth _AB ≥ T_A ∧ S smooth If _BA ≥ T_B, the double threshold is determined to have been met; 7.2 Triggering event THRESHOLD_HIT_BOTH{session_id, T_A, T_B, S smooth _AB,S smooth _BA, ts, weights_digest}, and freeze the current parameter snapshot for subsequent evidence collection.

[0043] 8. Unilateral compliance handling: When only S smooth _AB ≥ T_A or only S smooth When _BA ≥ T_B, output a "Single side meets the standard" prompt to the corresponding side, do not open the chat history, do not expose any contact information or identifiable information, and do not trigger takeover.

[0044] 9. Exception and Rollback Strategies 9.1 When signs of score manipulation are detected (repeated template phrases, identical text, highly similar anomalies), the judgment process will be paused and a review will commence; if necessary, the Trust score will be reduced and additional penalties will be imposed. 9.2 When multiple window thresholds are not met, output "Completion Suggestion / Relaxation Suggestion", but do not automatically lower the threshold unless the user explicitly selects and logs the audit event.

[0045] 10. Output and Gating 10.1 Output of this step: Final score pair (S) smooth _AB, S smooth _BA), decomposition details and evidence map, sensitivity contribution, frozen parameter snapshot and audit anchor points; 10.2 Reaching both thresholds is the sole trigger condition for entering the subsequent "threshold takeover and state switching" steps; if not reached, the proxy chat state will remain and the evaluation will continue in a loop.

[0046] Step Six: Threshold Takeover and State Switching (Method Endpoint) (S5)

[0047] 1. Triggering conditions and snapshot freeze 1.1 In step five, determine if S is satisfied. smooth _AB ≥ T_A ∧ S smooth When _BA ≥ T_B, the takeover process is triggered, freezing the current parameter snapshot (T_A, T_B, S). smooth _AB, S smooth _BA, weights_digest, policy_hash, psig_anchor_S5), and generate an audit event TAKEOVER_INIT{session_id, sandbox_id,ts}.

[0048] 2. Chat domain shutdown and resource sealing 2.1 Immediately stop the generation and sending / receiving channels of the chat proxy sandbox, and seal the unpersistent intermediate states and caches within the sandbox; 2.2 Mark the proxy chat domain as SEALED, allowing controlled access only after secondary consent is granted, according to the visibility policy.

[0049] 3. Forced switching of avatar / icon 3.1 Forcefully disable the "AI chat proxy" icon on both terminals and enable the "real person" avatar / watermark and corresponding UI prompts; 3.2 Generate the event AVATAR_SWITCHED{session_id,uid_A,uid_B,ts}; this identifier cannot be turned off or bypassed.

[0050] 4. Session domain migration (proxy chat domain → real person domain) 4.1 Create a real-person session domain handle real_session_id and establish a read-only mapping between it and session_id / sandbox_id; 4.2 The migration only includes permissions and visibility policies, and does not migrate the content of the chat messages; by default, no chat messages are open.

[0051] 5. Secondary consent gating (record visibility) 5.1 Display the secondary consent interface to both parties separately, listing the visibility options {summary, evidence section, full text}; 5.2 Controlled replay will be enabled only when both parties explicitly agree and select the same or compatible levels, and an event TRANSCRIPT_REVEALED{level, session_id, ts} will be generated. 5.3 In the absence of a second consent, the chat logs remain encrypted and unavailable.

[0052] 6. Contact information exchange gate 6.1 The exchange of contact information may be selectively enabled only after the second consent is obtained; 6.2 The exchange of contact information requires confirmation from both parties. The record fields are minimized, and the event CONTACT_EXCHANGE_ALLOWED{session_id, fields_digest, ts} is generated. 6.3 If either party refuses, no form of explicit or disguised disclosure of contact information is permitted.

[0053] 7. Record custody and evidence preservation 7.1 Chat logs are encrypted and hosted on the client side before and after the takeover. The server only saves the hash and timestamp (does not save plaintext) and writes them into the chained evidence storage {seq,ts,prev_hash,event_hash}. 7.2 Users can choose to delete or export chat logs; deletion only clears the ciphertext and key, retaining the minimum hash and timestamp for non-repudiation proof.

[0054] 8. Safety and anti-swerving measures 8.1 After takeover, it is strictly forbidden to write back or add content from the real user domain to the proxy chat domain; attempts to disclose proxy chat content through screenshots, external links, coded information, etc. will trigger interception and alarms; 8.2 It is prohibited to circumvent the visualization of "real people" by turning off the logo or changing the avatar; violations will generate audit events and enter the handling process.

[0055] 9. Abnormalities and Rollbacks 9.1 If one party withdraws authorization during the second consent stage, the chat history will remain invisible and this process will end; 9.2 If the avatar / identity switching fails or the terminal is incompatible, a "Real Person Status" message will be displayed as a text banner until the switching is completed.

[0056] 10. Output and Method Termination 10.1 This step outputs: real_session_id, AVATAR_SWITCHED, (optional) TRANSCRIPT_REVEALED, (optional) CONTACT_EXCHANGE_ALLOWED, and a snapshot of the visibility policy after takeover; 10.2 This concludes the method. Post-takeover live chat, continued communication within the platform, or external integration are not part of the method steps or claims of this invention.

[0057] (II) System Module Description

[0058] M1 Identity and Authentication Module 1. Collect and verify the mobile phone verification code to generate a unique user identifier (uid); bind the device fingerprint (device_id, system version, network fingerprint, geographic region information) to form an identity anchor. 2. Perform liveness detection and document verification (optional education / income verification), output the certification level verif_level∈{L0…Ln} based on the strength of the evidence, and generate the corresponding certification badge set badge_set; 3. Establish a tiered authentication ledger: record the source of evidence, verification time, validity period (verif_ttl), revocation conditions, and review records; automatically downgrade upon expiration and trigger a re-verification reminder; 4. Output the initial value of the consent state: Consent.ai_chat=OFF; record the source, timestamp, and policy fingerprint (policy_hash); 5. Highly sensitive elements (ID number, face template) are encrypted and stored to a minimum on the client side, with the server only storing hashes and timestamps; keys and data are managed in separate domains. 6. Device / Account Anomaly Detection: Multiple concurrent devices, abnormal geographical drift, and suspected shared accounts trigger risk control flags and secondary verification; 7. Generate and write audit events: KYC_PASSED / FAILED, BADGE_ISSUED / REVOKED, CONSENT_SET; use {seq,ts,prev_hash,event_hash} chained evidence storage; 8. Outputs: uid, device_id, verif_level, badge_set, policy_hash, psig_anchor_M1; these serve as strong inputs for subsequent modules.

[0059] M2 Field Governance and Privacy Minimization Module 1. Create a field dictionary field_dict: field type, value range, display granularity (range-based / fuzzy to district / county level / industry level), sensitivity level, and retention strategy; 2. Collect hard information and perform legality, contradiction, and timeliness checks; if it fails, return a reason code and enter draft state without triggering profile update; 3. Modify the workflow to a work order format: require evidence upload and manual review for key fields such as height / education / income, generate a version number ver_k and a receipt; upon approval, trigger the incremental event PROFILE_FIELD_UPDATED; 4. Display Control: External displays will default to range-based and fuzzy representation (such as income range, commuting radius, industry), and precise addresses and specific company names will be strictly prohibited from being displayed externally; 5. Visibility Range Management: Fields are bound to visibility tags {SELF, MATCHED_AFTER_THRESHOLD, NONE}; no identifiable information should be displayed if the two thresholds are not met. 6. Minimal retention of sensitive fields: Only hash / summary and timestamp are saved, while the main text is encrypted and hosted; the deletion process is triggered upon expiration or withdrawal of consent, and a minimal audit hash is retained; 7. Conflict and Anomaly Management: If cross-version conflicts, falsified evidence, or abnormally frequent modifications are detected, mark PROFILE_CONFLICT and restrict access to matching. 8. Output: Normalized data vector H_t, visibility map vis_map, field version set ver_set, psig_anchor_M2.

[0060] M3 Character / Personality Vector Engine 1. The pre-defined role library R={role_i} supports multiple selections and percentage weights w_i, with a constraint ∑w_i=100%; DIY roles receive text / image / audio descriptions and enter the review queue. 2. Role vectorization: Maintain a multi-dimensional feature vector R_i for each role_i; calculate the weighted role vector R0=∑(w_i·R_i); 3. Self-narration and speech-to-text processing: text denoising, desensitization, structuring and semantic embedding to obtain the user's self-narration vector U0; 4. Initial personality generation: Based on the fusion function V0=f(H0,R0,U0), output V0, confidence conf(V0), and coverage cov(V0); only the non-invertible vector is stored, and the original text is not retained; 5. Dynamic Update: Dialogue / Completion and Behavior Signal Trigger Update V_t = (1-λ)·V_{t-1} + λ·f(dialogue, completion, behavior); Update beats and trigger conditions are issued from the strategy repository; 6. Consistency Verification: When new evidence conflicts with historical profiles, the conflicting dimensions are marked and the confidence level is reduced; manual review is triggered when necessary. 7. DIY Role Management: Before going live, roles will pass sensitive word / policy / copyright and security checks. Roles that fail the review will not be included in matchmaking or proxy chat. 8. Output: V_t, conf(V_t), cov(V_t), character weight snapshot w, psig_anchor_M3.

[0061] M4 Multimodal Feature Module 1. Image Features: Perform quality assessment (clarity, occlusion, forgery signs), liveness / consistency detection, and basic attribute estimation (style / age group similarity) on portraits / photos; generate irreversible image embeddings (ImgEmb); 2. Text Features: Perform language detection, standardization, PII anonymization, and compliance verification; output semantic embedding TxtEmb and risk tags (pornography / hate speech / illegal content, etc.); 3. Speech Features: Perform ASR transcription (device-side priority), sound quality and anomaly detection, and extract auxiliary features such as prosody / stability; output speech embedding AudEmb and text transcription; 4. Embedding Specifications: All modal embeddings are irreversible vectors and are prohibited from being used for identity recognition backtracking; vectors are encrypted and normalized before being stored in the database. 5. Authenticity Verification: Verification of consistency between images and device, time, and geographic region; abnormal samples are subject to further review. 6. Security Gate: Detects and blocks obfuscated inputs such as external links / QR codes / distorted contact information, returns a reason code, and writes it into the audit. 7. Events and Retention: Generate events such as MEDIA_INGESTED, EMB_GENERATED, SAFETY_BLOCKED and store them in a chain; process the original media according to the minimum retention strategy; 8. Output: ImgEmb / TxtEmb / AudEmb, authenticity label, risk label, and psig_anchor_M4, for use by the matching and scoring modules.

[0062] M5 Matching and Threshold Compatible Filtering Engine 1. Hard Filtering: Boolean filtering is performed on the entire user set based on conditions such as city / commuting radius, age range, marital status, education / income range, industry / work schedule restrictions, isolation of minors, and blacklists / whitelists to obtain set H; geographical location is matched only at the district / county / commuting radius granularity. 2. Soft ranking: For candidate b in H, calculate S_AB = w1·RoleSim + w2·InterestSim + w3·LifestyleFit + w4·DialogReadiness + w5·Trust - Penalties; RoleSim is based on the similarity of V_A and V_B (cosine / Mahanobis distance + temperature scaling), and sensitive features (appearance / income) are weighted by default and a contribution cap is applied; 3. Threshold-compatible filtering: Only candidates with S_AB ≥ T_A and |T_A-T_B| ≤ ΔT_max (issued from the policy repository, e.g., 10 points) are selected; candidates without T_B are tagged as PENDING_TB and suspended for waiting. 4. Candidate Pool Generation: Perform topK and diversity / fairness correction on the selected set, and output the candidate pool C; enable exposure suppression and frequency control within the same time window to avoid duplicate access; 5. Explanation and Statistics: Generate an explanation entry (main boosting dimension and penalty item) for each selected / removed sample, and record the reason code for rejection and the number of rejections (DROP_STATS). 6. Policy and Audit: ΔT_max, weight w, fairness constraints, and filtering rules all generate fingerprints weights_digest / policy_hash and are written to the audit event COMPATIBILITY_ENFORCED; it is strictly prohibited to "push low-scoring (e.g., 30) users to high-threshold (e.g., 80) users"; 7. Exceptions and Rollback: When C is empty, output WAIT_HINT and optional "relaxation suggestions" (such as expanding commuting radius, adjusting interest dimensions), but do not automatically lower the threshold; enable cooling and risk control flags for users whose thresholds oscillate rapidly; 8. Output: Candidate pool C, suspended list PENDING_TB, drop statistics DROP_STATS, parameter fingerprints {T_A, ΔT_max, weights_digest} and psig_anchor_M5; as prerequisite inputs for the subsequent "agreement and establishment of the chat sandbox".

[0063] M6 Consent and Identification Management Module 1. Two-way consent collection: Display the consent interface to both parties in the conversation, listing the chat proxy attributes and visibility rules; collect Consent.ai_chat∈{ON,OFF}, and record the source, device fingerprint, timestamp, and version number; set the validity period consent_ttl and the cooldown time cooldown_consent; write the event CONSENT_GRANTED{uid, ts,policy_hash}; 2. Consent Status Governance: Entry into proxy chat is prohibited when no ON / ON combination is formed; withdrawal or expiration on either side triggers forced termination and records STOPPED_BY_USER / CONSENT_TIMEOUT; 3. AI Identifier / Watermark Control: Force the "AI Chatting Assistant" identifier to be enabled in message headers, avatar watermarks, and conversation banners (cannot be turned off or obscured by users); if the terminal is incompatible, it will revert to a text banner prompt; 4. Pause / Resume: Supports session-level pause (PAUSED) and resume (RESUMED), blocking downstream routing and generation during pause; writes events to SESSION_PAUSED / RESUMED; 5. Policy fingerprinting and auditing: Generate policy_hash and chain evidence {seq, ts, prev_hash, event_hash} for the agreement interface, visibility rules and identifier styles; 6. Output: ConsentRecord, ai_label_state=ON, policy_hash, psig_anchor_M6, which serve as prerequisites for establishing the chat sandbox.

[0064] M7 Proxy Chat Sandbox and Session Arranger 1. Sandbox Creation: After the ON / ON agreement is established, assign session_id and sandbox_id; create a list of resources and permissions for the proxy chat domain (text only / compliant media, prohibited contact information / external links / QR codes); default "encrypted hosting, invisible"; 2. Channel isolation: Separate storage and access control for proxy chat domains and real user domains; prohibit cross-domain read and write operations; enable rate limiting and concurrency limits; 3. Policy-based routing: Load routes in stages {RFI generation, dialogue generation, rewriting / de-identification, score update}; support multi-model collaboration and degradation matrix; record route_plan_hash; 4. Rhythm and pragmatic control: Configure turn limit (turn_limit), minimum turn gap (min_turn_gap), politeness / reciprocity / conciseness constraints; trigger RATE_LIMITED for abnormal repetitions or sparing; 5. Storage and Encryption: Session fragments are stored in encrypted form; the server only stores the hash and timestamp; keys and data are managed separately; data is not visible until both thresholds are met and a second agreement is reached. 6. Anomalies and Recovery: Generation failure / timeout → Automatically switch to suboptimal route or template as a fallback, record DEGRADED / RECOVERED; Severe anomalies trigger SESSION_ABORTED; 7. Output: session_id, sandbox_id, route_plan_hash, psig_anchor_M7, for use by the RFI, scoring and thresholding modules.

[0065] M8 RFI Gap Analysis and Request Engine 1. Difference / Gap Detection: Based on image coverage, conflict markers, and matching targets, identify unfilled slots and contradictory fields; generate an RFI list {RFI_k}; 2. Request delivery: Assign a time limit TTL_k∈{24h,48h}, priority and reminder strategy to each RFI_k; push to the corresponding user terminal; record the event RFI_ISSUED{session_id,k,TTL_k}; 3. Submission Validation and Merging: Receive the completed form, perform validity / contradiction / sensitivity checks, generate a structured complete form ΔS_k and merge it with the profile; write it to PROFILE_UPDATED{uid,fields,ts}; 4. Expiration Penalty: If TTL_k expires and is not submitted, it is marked as RFI_EXPIRED, and a penalty is imposed on the scoring dimension (deduction of points or reduction of confidence). By default, the threshold is not automatically reduced unless the user explicitly selects it and records the audit. 5. Form merging and frequency control: High-frequency RFIs are automatically merged into a single form; frequency control and cooling are enabled for excessive triggering, returning the reason code RFI_RATE_LIMITED; 6. Exceptions and Review: Completed and historical conflicts are entered into the review queue, and the reason code and suggestions are output; illegal content is directly intercepted and recorded as SAFETY_BLOCKED; 7. Output: pending queue, ΔS_k, RFI_EXPIRED statistics, psig_anchor_M8; used as input for dynamic personality update and scoring.

[0066] M9 scorer and interpretable engine 1. Score Calculation: For candidate pair A ←→ B, calculate S_AB and S_BA: S = w1·RoleSim + w2·InterestSim + w3·LifestyleFit + w4·DialogQuality + w5·Trust - Penalties; Sensitive features (appearance / income) are demoted by default and their contribution limits are restricted; 2. Smoothing and Hysteresis: Exponential smoothing and window hysteresis are used to avoid critical jitter; abnormal jumps are reviewed. 3. Interpretable decomposition: Output dimension scores, weight fingerprints (weights_digest), sensitivity contribution (sens_ratio), and a list of penalty items; generate an evidence map {dimension → segment ID / RFI fingerprint}. 4. Event writing: Each update records SCORE_UPDATED{session_id, S_AB, S_BA,weights_digest, ts}; when the double threshold is reached, the state machine module triggers the takeover event. 5. Fairness constraints: Fairness constraints (maximum percentage and threshold protection) are applied to sensitive items, and the weights automatically revert to compliance weights in case of violations; 6. Outputs: S_AB, S_BA, decomposition report, evidence_map, weights_digest, psig_anchor_M9, for threshold state machine determination.

[0067] M10 Threshold State Machine and Takeover Control 1. Status definitions: AI_ONLY (pure chat proxy), HUMAN_IN_LOOP (optional chat proxy), TAKEOVER_PENDING (dual thresholds met, waiting to switch), REAL_ONLY (real person domain). 2. Trigger determination: if and only if S smooth _AB ≥ T_A ∧ S smooth _BA ≥ T_B Enter TAKEOVER_PENDING; freeze the parameter snapshot and write it to TAKEOVER_INIT{session_id,ts}; 3. Forced switch: Turn off the "AI chat proxy" label, turn on the "real person" avatar / watermark and write it to AVATAR_SWITCHED; stop and seal the chat proxy sandbox, and create a real person domain handle real_session_id; 4. Domain Migration and Gating: Only migration permissions and visibility policies are implemented; chat logs are not visible by default; secondary consent is required before playback and selective exchange of contact information can be enabled at the {summary / evidence section / full text} level (related events are recorded in the system log). 5. Method Termination: Entering REAL_ONLY signifies the end of this method; subsequent live chat and external platform integration do not constitute steps in this method. 6. Output: real_session_id, AVATAR_SWITCHED, frozen snapshot, psig_anchor_M10.

[0068] M11 Security / Policy Gate and Anti-Fraud Module 1. Multi-level detection: Implements policy and risk detection on text / images / audio, covering traffic redirection / monetization / external links / QR codes, pornography / hate speech / illegal activities, personally identifiable information and disguised contact information; adopts a cascaded judgment of rules + multi-stage classifiers; 2. Interception and Handling: Upon triggering, perform tiered handling such as BLOCK / DELAY / QUARANTINE / DEGRADE; return the cause code and remedial suggestions to the sending end; 3. Minors are isolated: Based on age verification and risk characteristics, minors are strictly isolated and prohibited from entering matchmaking and proxy chatting; MINOR_BLOCKED is written to their names. 4. Anti-fraud signal aggregation: Combine authentication level, historical reports, RFI anomalies, and homogeneous text / template signs to generate a risk score and write it back to the Trust component of the scorer; 5. Manual review channel: High-risk, controversial, or low-confidence samples are submitted for manual review; the review results are fed back into the strategy repository. 6. Auditing and Retention: All intercepted / handled events are written to audit logs such as SAFETY_BLOCKED / ABUSE_FLAGGED and stored in a chain; a minimal evidence summary and timestamp are retained; 7. Output: Risk label, handling result, risk_score, psig_anchor_M11; return executable rectification and retry strategies to the upstream module.

[0069] M12 Audit and Evidence Storage Module (PSIG) 1. Event Structure and Signature Chain: A unified structure {seq, ts, type, actor, session_id, payload_digest, policy_hash, prev_hash, event_hash} is adopted for key events throughout the entire process; event_hash = H(seq || ts || type || actor || session_id || payload_digest || policy_hash || prev_hash), forming an immutable chain structure; 2. Batch anchoring: Aggregate event hashes by time window, construct a Merkle tree, generate merkle_root and anchor_id, and perform batch anchoring through a trusted timestamp service; record ANCHOR_COMMITTED{anchor_id, merkle_root, ts}; 3. Integrity Verification: Provides interfaces for chain consistency verification and block verification; triggers AUDIT_ALERT upon detecting broken chains or duplicate sequence numbers; 4. Alerts and Tiered Handling: Define risk levels and alert rules (abnormal similarity jumps, rapid threshold fluctuations, duplicate text from the same source, external link attempts); output ALERT{severity, rule_id, evidence_digest} and link it to risk control. 5. Compliance Export: Generates a minimal audit package {timeline.csv, anchor_meta.json, merkle_proof}, with whitelisted and de-identified fields; package body encryption; and separate domain hosting for keys and data. 6. Retention and cleanup: Audit events and anchored metadata are retained in retention_ttl according to the policy, and cleaned up upon expiration while retaining tombstone_hash; 7. Output: anchor_id / merkle_root, AUDIT_ALERT, export_bundle, psig_anchor_M12.

[0070] M13 Record Hosting and Encrypted Storage Module 1. Encrypted Hosting on the Client Side: Chat records are encrypted and stored on the client side using the session key MEK (AES-GCM); MEK is encapsulated by KEK, and KEK is derived from the user key or protected by a hardware key; 2. Minimal server storage: The server only stores record hashes and timestamps as indexes and non-repudiation credentials, and does not store plaintext; optional encrypted cloud backup requires separate agreement and independent key domain management. 3. Access Control: Invisible by default; only issued according to the {Summary / Evidence Segment / Full Text} level after the two thresholds are met and secondary consent is completed; each access generates ACCESS_LOG{uid, level, ts, purpose}. 4. Deletion and Withdrawal: User deletion destroys local encrypted data and related keys (including backup paths); the server retains the tombstone_hash and timestamp; withdrawal of consent terminates any replay interface. 5. Export capability: Generate encrypted export packages for users on demand (with evidence_map and hash_manifest); supports integrity verification and playback verification; 6. Exception handling: If unauthorized access or a faulty key is detected, DATA_ACCESS_ALERT is triggered and session access is frozen; 7. Output: hash_index, ACCESS_LOG, tombstone_hash, export_artifact, psig_anchor_M13.

[0071] M14 Telemetry and SLO Panel 1. Metrics Collection: Aggregate runtime events and performance logs to generate core metrics: Takeover conversion rate (CR_takeover = #THRESHOLD_HIT_BOTH / #AI_CHAT_STARTED), RFI completion rate, fraud interception rate, appeal rate, scoring consistency index, strategy hit rate, chat session interruption rate, TTFT / latency / error rate, etc. 2. Scoring consistency: Calculate the correlation coefficient between cross-window scores and the hysteresis pass rate; abnormal jitter triggers SLO_ANOMALY; 3. Threshold and Strategy Impact Analysis: Evaluate the impact of changes to T / ΔT_max / λ / TTL on CR_takeover, RFI completion rate, and interception rate, and output POLICY_IMPACT_REPORT; 4. Alerts and Budgets: Set upper / lower limits for key metrics, and suggest degradation or rollback if the limits are exceeded; record SLO_BREACH{metric, value, ts, suggestion}. 5. Multi-dimensional dashboards: Display data segmented by region, age group, authentication level, and traffic source; supports grayscale / control group A / B analysis; 6. Data minimization: The indicator aggregation process uses only de-identified statistics; it does not expose personally identifiable information; 7. Output: SLO_DASHBOARD, SLO_BREACH, POLICY_IMPACT_REPORT, psig_anchor_M14.

[0072] M15 Role Verification and Crowd Review Module 1. Review Process: DIY user enters automatic pre-review (sensitive words / policy / copyright / counterfeiting detection) → manual review → conclusion APPROVED / REJECTED / LIMITED; failure returns reason code; 2. Crowd Review Mechanism: Boundary samples are distributed to the compliance crowd review pool, scores and consistency coefficients are aggregated, review recommendations are formed and submitted for arbitration; 3. Version and Visibility: Upon approval, a role_id and version number role_ver are generated; visibility {PRIVATE, FAMILY, PUBLIC} and validity period are bound; expired or non-compliant content will be removed. 4. Blacklist and Removal: Samples that violate regulations or are reported are added to the blacklist, and ROLE_REVOKED{role_id,reason, ts} is executed, along with cascading cleanup of references; 5. Anti-counterfeiting and copyright protection: Detect similarity to well-known figures / brands, and require authorization certificates or force rejection when necessary; 6. Auditing and Retention: The entire process is written to ROLE_AUDIT_LOG and stored in a chain; only minimal evidence summaries and timestamps are retained; 7. Output: role_id / role_ver, visibility policy, ROLE_REVOKED, psig_anchor_M15.

[0073] M16 Strategy Repository and Canary Release 1. Parameter Management: Centrally manage policy parameters such as T, ΔT_max, λ, TTL, w1…w5, β_sens, and α_sens_max, define their value range, default values, and dependencies; generate policy_hash; 2. Gray-scale and Rollback: Supports gray-scale distribution by proportion / audience / region; monitors SLO metrics and triggers rollback strategies to the previous stable version; records POLICY_ROLLED_BACK{from,to,ts}. 3. Version and Activation: Parameter updates require two people to review and sign, generating a policy_ver; distribution uses a signature package and idempotent keys, and terminals switch according to the activation time window; 4. Consistency and caching: Provides strong consistent reads and multi-level caching by region; policies are automatically refreshed when they expire, and the last stable version is used in case of failure; 5. Auditing and Reconciliation: The entire chain of events for updating, publishing, and rolling back is written to the audit; a "snapshot reconciliation" interface is provided to verify the consistency between the actual effect on the terminal and the repository; 6. Output: policy_ver, policy_hash, grayscale rule, POLICY_ROLLED_BACK, psig_anchor_M16.

[0074] M17 SDK / API Gateway 1. Access methods: Provides SDKs and REST / gRPC APIs for mobile apps / mini-programs / Web; unified authentication, flow control, and logging; 2. Authentication and Signature: Supports OAuth2 / AK-SK; requests must include ts / nonce / idempotency_key and a signature; cross-domain and CORS whitelist control; 3. Rate limiting and quotas: Multi-dimensional rate limiting and burst control based on uid / app_id / ip; exceeding the limit returns a standardized error code and records RATE_LIMITED; 4. Version compatibility: Supports api_version negotiation and dual-write comparison; obsolescence policies are implemented through announcement periods and canary rollouts. 5. Idempotency and Retry: Idempotency key window, deduplication caching and idempotency result replay; safe retry strategies and exponential backoff; 6. Interface Coverage: Exposing endpoints for authentication, data governance, matching and filtering, consent and identification, sandbox dialogue, RFI submission, scoring query, threshold determination results, takeover triggering, audit export, etc. 7. Secure transmission: Full-channel TLS; uploaded media are whitelisted by type and subject to size limits; static resources use signed URLs; 8. Observation and Alarming: Unified recording of REQUEST_LOG, ERROR_LOG, P95 latency and error rate; abnormal triggering of API_ALERT and linkage with degradation; 9. Output: access_token / refresh_token, api_version, list of standard error codes, psig_anchor_M17.

[0075] (iii) Description of computer-readable storage media This invention provides a computer-readable storage medium for storing a computer program. When executed by a processor, the program performs the following steps S0–S5: S0 Initializes anchor points and data collection; S1 Sets thresholds and pre-screens candidates; S2 Agrees on mutual consent and establishes a chat proxy sandbox; S3 AI-to-AI chat proxy and RFI completion; S4 Two-way scoring and threshold determination; S5 Threshold takeover and state switching. Real-person chat and external platform integration after takeover are not within the scope of this invention.

[0076] The program includes program instructions (corresponding to system modules M1–M17) for implementing the following functions: 1. Identity and Authentication Loading Instruction (corresponding to M1): Collect mobile phone number and device fingerprint, perform hierarchical authentication, generate user identifier, authentication level and badge, and initialize the consent bit Consent.ai_chat=OFF; 2. Field governance and privacy control instructions (corresponding to M2): Verify the legality of hard / soft information, manage version and control the granularity of display, and encrypt and store sensitive fields; 3. Personality Vector Generation and Update Command (corresponding to M3): Generate and dynamically update personality vectors, combining multimodal data (role, text, voice); 4. Multimodal feature processing instructions (corresponding to M4): Generate image / text / speech embeddings and perform authenticity verification to intercept security threats; 5. Matching and threshold compatible filtering instructions (corresponding to M5): Perform candidate filtering and soft sorting, and output candidate pool and discard statistics; 6. Consent and Identification Management Instructions (corresponding to M6): Collect mutual consent, set validity period and cooldown time, and forcibly enable the "AI Chatting" identifier; 7. Proxy Chat Sandbox and Orchestration Commands (corresponding to M7): Create a proxy chat sandbox, perform isolation and policy routing, and ensure encrypted hosting; 8. RFI Gap Analysis and Request Command (corresponding to M8): Identify data gaps, issue RFI requests, and perform merging processing; 9. Scoring and Interpretable Output Instructions (corresponding to M9): Used to calculate S_AB / S_BA and generate a decomposition report, outputting an evidence map; 10. Threshold state machine and takeover control command (corresponding to M10): Triggers the takeover mechanism and switches to a live conversation; 11. Security / Policy Gate and Anti-Fraud Directive (M11): Identify and address security threats and prevent minors and risky behaviors; 12. Audit and Evidence Preservation Instructions (corresponding to M12): Record the event chain, perform integrity verification, and export a compliance report; 13. Record Hosting and Encrypted Storage Commands (corresponding to M13): Encrypts and stores session records, supporting deletion / export and access logs; 14. Telemetry and SLO commands (corresponding to M14): Generate system performance metrics and provide alarms and rollback suggestions; 15. Role Review and Crowd Review Instructions (corresponding to M15): Automatic and manual review of DIY roles, management of blacklists; 16. Strategy Repository and Canary Release Instructions (corresponding to M16): Centrally manage strategy parameters and perform canary releases and rollbacks; 17. SDK / API Gateway Commands (corresponding to M17): Provides access endpoints and supports functions such as authentication, rate limiting, and version compatibility.

[0077] The aforementioned computer programs can be deployed on servers, edge nodes, or terminal devices, employing microservices / containerization / distributed deployment. Computer-readable storage media can be ROM, RAM, flash memory, solid-state drives, etc., and must meet security and compliance requirements. Program instructions are subject to access control, and audit events and policy fingerprints are stored in a chain-like manner throughout the entire process.

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

[0079] 3.1 Definition of Security Primitives Identity and session primitives: uid, device_id, session_id, sandbox_id, real_session_id, consent_flag, ai_label_state; Policy and parameter primitives: policy_ver, policy_hash, T, ΔT_max, λ, TTL, w1…w5, β_sens, α_sens_max, weights_digest; Encryption and evidence storage primitives: MEK / KEK, hash, event_hash, prev_hash, anchor_id, merkle_root; Visibility and domain primitives: domain_tag, visibility_level, record_state; Scoring and evidence primitives: S_AB, S_BA, evidence_map, risk_score; Idempotency and timing primitives: ts, nonce, idempotency_key, cooldown_*, consent_ttl.

[0080] 3.2 Service Invocation Structure (Request / Response Specification) Unified header: contains identity and session identifiers, and signature verification; Core API family: identity authentication, profile update, mutual consent, chat domain creation, rating calculation, record export, etc. Error and handling codes: BLOCK, DELAY, DEGRADE, QUARANTINE, RATE_LIMITED, etc.

[0081] 3.3 Boundary Protection and Mandatory Ticket Inspection (PEP) PEP-PLAN (Policy / Profile Change Pre-processing): Route planning and profile update verification; PEP-CHAT (Proxy Chat Domain Message In / Out): Proxy chat domain message processing, intercepting sensitive content; PEP-EXPORT (Record / Contact Information Release): Records and contact information are verified, requiring secondary consent; Minimal blocking domain: Intercept errors and return a minimal response; Domain isolation: One-way migration from SANDBOX to REAL, reverse operation is prohibited.

[0082] 3.4 Reverse bypass and downgrade / rollback Detour detection: Detects abnormal behavior, such as distorted contact information or strategy drift; Tiered handling: BLOCK, DELAY, DEGRADE, QUARANTINE, KILL_SWITCH; Policy rollback: Roll back to the stable version when SLO_BREACH is triggered.

[0083] 3.5 Compliance and Privacy Minimization Data minimization: Only hash + time series data is stored to avoid collecting sensitive information; Client-side encryption and hosting: Encrypt chat logs and destroy the key when deleted; Visibility gating: NONE if the two thresholds are not met, and open according to the level once they are met; Minor isolation: Minor users are prohibited from entering the matching and chat proxy processes; Sensitive weighting and fairness constraints: Imposing restrictions on sensitive data and supporting interpretable output.

[0084] 3.6 Critical Events and Alarms: Critical events include CONSENT_GRANTED, RFI_ISSUED, SCORE_UPDATED, TAKEOVER_INIT, etc., which are stored in the event chain and can be batch anchored to ensure that data and calls are controlled and auditable.

[0085] IV. Terminology Definitions and Identification Boundaries

[0086] 4.1 Terminology Definition 1. User: Any natural individual participating in matchmaking, denoted as A or B; 2. Identity Anchor Point: Unique user binding information formed by mobile phone number, device fingerprint, etc.; 3. Hard Data: Objective information such as age, education, income, and marital status; 4. Soft Data: Character description, interests and preferences, dialogue personality, etc. 5. Character / Personality: Pre-set or approved personality templates from the platform; 6. DIY Roles: Personalized roles submitted by users can be used for matching after review; 7. Personality Hybrid Vector (V_t): A fusion vector of hard information, role vector, and self-narrative semantics, dynamically updated; 8. Similarity function (RoleSim): A function that calculates the similarity between user personality vectors; 9. Overall score S_AB / S_BA: Matching score between users, including role similarity, interests, etc.; 10. Threshold (T): The minimum matching score set to trigger takeover; 11. AI-assisted chat: Machine-to-machine dialogue under the user's role; 12. Proxy Chat Sandbox (SANDBOX): An isolated session domain for AI proxy chat, encrypted and hosted by default; 13. Real Person Domain (REAL): The real person dialogue domain after threshold takeover; 14. Consent / Second Consent: Mutual consent before entering the chat service and re-consent to the visibility of chat records / release of contact information after taking over; 15. Record visibility level: The visibility level of a record is NONE, SUMMARY, EVIDENCE, FULL; 16. RFI (Request for Information): Request for information completion; 17. Behavioral signals: supplementing characteristics such as response delay and rejection rate; 18. Sensitive Features / Sensitive Weighting: Weight restrictions on sensitive data such as appearance and income.

[0087] 4.2 Boundary Identification Description 1. Scope endpoint: The method of this invention ends with "threshold takeover and state switching". Real-person chat after takeover is not within the scope of this invention. 2. Model and Embedding Neutrality: No specific large model vendor or algorithm implementation is required; equivalent technical capabilities are considered equivalent implementations. 3. Unrestricted rating and UI representation: Rating components and weights are configurable, and the presentation format of UI icons and avatar watermarks is not limited; 4. No device form factor limitation: Supports different device forms, such as mobile phones, tablets, computers, etc. 5. Record hosting neutrality: The goal is to achieve end-side encryption, hash / timestamp storage, and the ability to delete / export records; the specific implementation is not limited.

[0088] 4.3 Compliance and Privacy Boundaries 1. Minimize by default: Chat history is not visible until the two thresholds are reached; the platform only saves hashes and timestamps. 2. No Exchange: During the AI-assisted chat phase, the exchange of any contact information or identifiable information is prohibited. 3. Isolation of Minors: Minors or those who fail age verification will be directly blocked from the matching and chat process; 4. Sensitive Data Management: Sensitive data such as appearance and income are downgraded by default and can be explained; violations are handled according to their level.

[0089] 4.4 Equivalence Principle and Anti-Bending Instructions 1. Core components: including key technologies such as dynamic personality generation, two-way scoring, AI-assisted chat, and dual-threshold takeover; 2. Noun substitution and path variation: Noun substitution or step order adjustment does not affect the function and process positioning.

[0090] 4.5 Mathematics and Symbol Conventions 1. Fusion function and similarity metric: can be replaced with equivalent implementations to ensure dynamic updates and jitter suppression; 2. Inequality Relationships and Score Normalization: Inequalities are assumed to be closed intervals, and all scores are normalized to the interval [0, 100].

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

[0092] 5.1 Path Control Model and State Machine Control plane and data plane are separated: the data channel is only allowed after the session passes through the control channel for ticket verification; State machine: The state progresses from INIT → SANDBOX_ACTIVE → TAKEOVER_PENDING → REAL_ACTIVE → TERMINATED; Three mandatory ticket checks (PEP): (a) PEP-PLAN: Ticket verification before strategy / profile changes; (b) PEP-CHAT: Proxy chat domain message verification; (c) PEP-EXPORT: Record visibility and contact information before ticket release; Path control: Allowed paths include identity verification, data governance, mutual consent, proxy chat, rating and takeover; prohibited paths include skipping consent or directly entering proxy chat without meeting the two thresholds.

[0093] 5.2 Ticket Verification Elements and Tokens Token fields include: session_id, sandbox_id, policy_ver, consent_flag, ts, nonce, idempotency_key, domain_tag, etc. Consistency verification: Verify consistency of consent_flag=ON / ON, domain_tag consistency, time window, idempotency, etc. Threshold snapshot: Freezes relevant parameters during takeover to provide credentials for PEP-EXPORT.

[0094] 5.3 Anomaly and Detour Type Identification Detour identification: policy detour (such as spoofing policy_hash, threshold oscillation avoidance), consent detour (such as one-sided Consent, resuming sending after withdrawal), domain detour (such as writing back from REAL to SANDBOX), contact information transformation and content avoidance (such as QR code, image embedding, etc.). Blocking process: If a PEP fails, it is handled locally within the smallest blocking domain. Handling levels include BLOCK, DELAY, DEGRADE, QUARANTINE, and KILL_SWITCH. The event will be written to the PSIG chain.

[0095] 5.4 Timing, Idempotency, and Replay Control Time window control: Window request rejection; Idempotency keys and concurrency suppression: Critical calls use idempotency_key to avoid replaying requests; when concurrency from multiple endpoints exceeds the threshold, the request enters the QUARANTINE.

[0096] 5.5 Scoring and Path-Linked Protection Sensitive weighting and boundary critical delay: DEGRADE and recalculate scores immediately when sensitive data is not effective or over-specified; ensure stable threshold crossing and avoid "threshold jitter"; RFI Impact: If the RFI is not completed, the score will be deducted and detour will be prohibited.

[0097] 5.6 Record visibility and leakage prevention Dual gating and leakage detection: Reveal is only allowed after both thresholds are met and a second consent is obtained; leakage detection of contact information / external links, etc., is performed within the chat proxy domain; Domain barriers: After takeover, write-back to SANDBOX is prohibited.

[0098] 5.7 Strategy rollback and recovery mechanism SLO Triggering and Recovery: When SLO_BREACH is triggered, the system will revert to the stable version; after the user makes rectifications, the isolation will be lifted upon successful PEP verification. Black / Gray List Management: Repeated detours or high-risk behaviors will be added to the gray list, and those that reach a threshold will be transferred to the black list.

[0099] 5.8 Auditing and Exporting PSIG complete record and batch anchoring: Key events such as CONSENT_GRANTED and AI_CHAT_STARTED are recorded into the chain, and the event hash is aggregated to generate a Merkle root and submit a trusted timestamp; Compliance Export: Export the audit package without plaintext records to ensure compliance.

[0100] 5.9 Boundary Reaffirmation and Equivalence Method Boundaries: Path control and blocking are only applicable to processes before takeover; real-person interactions after takeover are not within the scope of this invention. Equivalent implementation: PEP name, handling action, and detection algorithm can be replaced, as long as the closed loop of "ticket verification - detection - handling - record keeping - rollback" is achieved.

[0101] VI. Beneficial Effects Compared with the prior art, the present invention has the following beneficial effects: 1. Dynamic Personality and Data Completion Closed Loop: Driven by RFI+TTL to continuously update V_t, solving the problem that static forms are difficult to depict real preferences; perform consistency checks on conflicting information and lower the confidence level to improve the credibility of the profile; 2. High-quality candidates and threshold consistency: Through threshold-compatible filtering and ΔT_max constraints, "low-scoring users with high thresholds" is eliminated, significantly reducing ineffective outreach and dialogue waste; 3. Clear AI Boundaries and Compliance-Friendly Design: A sandbox with mutual consent and prominent signage prohibits contact information / external links / PII by default, effectively reducing the risk of misleading and diverting traffic; records / contact information are only released after secondary consent, meeting privacy and transparency requirements; 4. Explanability and fairness: The scorer output is decomposed into dimensions, weighted fingerprints, and evidence mapping; sensitive components such as appearance / income are weighted less and have a contribution cap, reducing disputes and appeals caused by bias. 5. Stable triggering and anti-jitter: Introducing smoothing and hysteresis, the takeover is only triggered when the "double threshold" is met in consecutive windows, avoiding false takeover caused by critical jitter; 6. End-to-end auditability and minimal data retention: PSIG event chain and batch anchoring ensure the verifiability of the chain; chat logs are encrypted and hosted on the client side, and only hashes / timestamps are stored on the server, which can be used for evidence collection without exposing plaintext; 7. Anti-circuiting and risk control closed loop: Forced ticket verification at three points: PEP-PLAN / CHAT / EXPORT, covering key nodes of strategy / session / export; implementing BLOCK / DELAY / DEGRADE / QUARANTINE / KILL_SWITCH graded handling for contact information deformation, same-origin templates, abnormal similarity jumps, etc. 8. Engineering and Operability: The strategy repository centrally manages T, ΔT_max, λ, TTL, w1…w5, and supports canary deployments and automatic rollback; the SDK / API gateway provides authentication, rate limiting, idempotency, and version compatibility; the SLO panel measures conversion rate, RFI completion rate, fraud interception rate, scoring consistency, appeal rate, and other indicators, facilitating iterative optimization; 9. Model neutrality and substitutability: Multi-model collaborative architecture and embedding neutral design, without restrictions on vendors or model details; substitution is allowed under the premise of meeting the three hard requirements of irreversible vectors, interpretable scoring, and threshold takeover. 10. Clear Scope and Anti-Bypass: The core elements are a combination of "mutual consent + chat sandbox + dual threshold takeover + strong avatar / watermark cut-off + PSIG + encrypted hosting"; the absence of any key link does not constitute an equivalent implementation, thus enhancing the stability of the patent. Attached Figure Description

[0102] Figure 1 : Schematic diagram of the overall architecture of the method and system of this invention (S0–S5 × M1–M17).

[0103] Figure 2 Flowchart of S0–S1 Real Anchor Points and Data Collection → Initial Personality Vector V0 Generation and Threshold Setting Pre-screening.

[0104] Figure 3 S2 Sequence diagram of mutual consent and sandbox establishment.

[0105] Figure 4 S3 RFI Gap Analysis and Dynamic Personality Update Mechanism Diagram.

[0106] Figure 5 S4 scoring and interpretable output and dual threshold decision graph.

[0107] Figure 6 S5 threshold takeover and state switching 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: Dialogue-Driven Personality Hybrid Vector and RFI-TTL Completion Process: After generating V0=f(H0,R0,U0) in S0–S3, embedding and fusing the dialogue text and completion results in the chat sandbox according to a fixed evaluation window W_k, and executing V_t=(1-λ)·V_{t-1}+λ·f(dialogue corpus, ΔS_k, behavioral signal), where λ∈(0,1); RFI strategy: Gap identification generates RFI_k{field,TTL,priority}, with the default TTL∈{24h,48h}; if the gap is not filled by the deadline, it is written to RFI_EXPIRED and penalized in the "Information Sufficiency / Trust" component of the score. The threshold is not automatically lowered by default. Consistency: When there is a conflict between the completion and the history, output the conflict dimension and cause code, reduce the confidence of that dimension conf(V_t) and enter the review queue; Technical effects: The RFI-TTL mechanism improves profile coverage (cov(V_t)) and score confidence, and reduces cold start error; in equal-sized controls, it can significantly reduce "match failures due to insufficient data".

[0110] Example 2: Threshold-Compatible Filtering and Dual Threshold Triggering Pre-screening: After hard filtering, calculate S_AB for candidate b and apply the first threshold S_AB≥T_A; Compatibility determination: For those that meet the criteria, check if the second threshold |T_A-T_B|≤ΔT_max (issued from the policy repository, e.g., 10); if T_B is not set, record it as PENDING_TB; Triggering condition: After the chat is completed, the points are smoothly distributed (S). smooth _AB、S smooth _BA, determine S smooth _AB≥T_A ∧S smooth THRESHOLD_HIT_BOTH is triggered when _BA≥T_B; Technical effects: It blocks the "low score → high threshold" exposure path, reducing invalid touches; hysteresis suppresses critical jitter, reducing the false takeover rate.

[0111] Example 3: Two-way consent and chat proxy sandbox, secondary consent gating Agreed: Consent.ai_chat should be collected separately; sandboxes should not be built if ON / ON is not established; consent records should include ts / nonce / device_id / policy_hash. Sandbox: Creates a sandbox_id, enforces the "AI chat proxy" label, prohibits contact information / external links / PII, and records are "encrypted and hidden" by default; Secondary Consent: After THRESHOLD_HIT_BOTH, {SUMMARY / EVIDENCE / FULL} review and (optional) contact information exchange are only enabled if both parties agree again and select the consistency / compatibility level; Technical benefits: Ensures clear boundaries for AI intervention and minimizes privacy; no records are visible until the two thresholds are reached, reducing the risk of bias and leakage.

[0112] Example 4: Explainable Scoring and Sensitive Component Weighting / Fairness Constraints Rating formula: S = w1·RoleSim + w2·Interest + w3·Lifestyle + w4·DialogQ + w5·Trust-Penalties; Sensitive weighting: Set a weighting coefficient β_sens and a contribution cap α_sens_max for appearance / income, and output the sensitivity contribution degree sens_ratio; Explanation: Generate a decomposition report and evidence_map {dimension → segment ID / RFI fingerprint}; weight fingerprint weights_digest is added to the chain for evidence storage; Technical benefits: Provides verifiable matching criteria, constrains the impact of sensitive features, and reduces disputes and appeals.

[0113] Example 5: PSIG Chained Evidence Storage and End-Side Encrypted Custody Event chain: Key events are recorded by {seq, ts, type, actor, session_id, payload_digest, policy_hash, prev_hash, event_hash}; periodic aggregation is performed using Merkle roots and anchored with trusted timestamps; Minimal retention: Chat logs are encrypted with MEK on the client side, and only hash+ts is stored on the server; deletion destroys the key and ciphertext, but retains tombstone_hash; Technical effect: Achieves both "auditability, evidence-gathering capability, and immutability" and "server does not hold plaintext," thus meeting compliance requirements.

[0114] Example 6: Three PEP Mandatory Ticket Checks and Abnormal Detour Blockades PEP-PLAN: Verify the validity of agreement / version / policy before routing and profile changes; PEP-CHAT: Review each sandbox message for traffic redirection / monetary solicitation / external links / QR codes / variant contact information and PII. If a match is found, BLOCK / QUARANTINE / DEGRADE will be applied. PEP-EXPORT: Verify "dual thresholds + secondary consent + level matching" before reviewing records and releasing contact information; Technical effect: Provides on-site blocking for strategy bypass, consent bypass, domain bypass, and contact information transformation, improving risk control effectiveness.

[0115] Example 7: Implementation of a State Machine with Threshold Control and State Switching State: AI_ONLY → TAKEOVER_PENDING → REAL_ONLY; Entering REAL_ONLY is considered the end of the method; Switching: After the takeover is triggered, the "AI chat proxy" icon will be turned off, the avatar / watermark will be forcibly switched to "real person", the sandbox will be sealed and a real_session_id will be created; Domain isolation: REAL → SANDBOX write-back is prohibited; both review and release of contact information are subject to secondary consent gating; Technical effect: The "virtual to real" transition is engineered into a gate with clear boundaries and auditability.

[0116] Example 8: Strategy Repository and Canary / Rollback Parameter set: manages T, ΔT_max, λ, TTL, w1…w5, β_sens, α_sens_max, and generates policy_ver / policy_hash; Gray-scale and rollback: Gray-scale distribution by region / population, monitoring SLO out-of-bounds triggering POLICY_ROLLED_BACK, reconciliation and verification of the effective version on the terminal; Technical benefits: Rapid trial and error and safe rollback without compromising stability.

Claims

1. A multi-model collaborative AI-assisted matchmaking method for dating and matchmaking based on dynamic personality and threshold takeover, characterized in that, Includes the following steps: S0 Real Anchor Points and Data Collection (Initialization): Collect the user's mobile phone number, device fingerprint, liveness information and ID information to complete identity authentication, and collect the user's hard information and soft information. Construct the user's initial personality vector V0 based on multiple roles, multiple selections and percentage allocation. S1 Threshold setting and candidate pre-screening (threshold-compatible filtering): The user sets the matching threshold T and performs hard filtering, soft sorting and threshold-compatible filtering on all candidates. The candidate pool C is generated only when S_AB ≥ T_A and |T_A - T_B| ≤ ΔT_max. S2 Mutual Consent and Proxy Chat Sandbox Establishment: Provided that both User A and User B agree to AI proxy chat, a proxy chat sandbox domain is created, the AI ​​identifier is forcibly enabled, and contact information, external links, and identifiable information are blocked; S3 AI-to-AI Chatting and RFI Completion (Dynamic Personality): The AI ​​generates a completion request RFI based on the differences in the personality profile, sets a TTL, collects data to complete the completion within the validity period, and updates the dynamic personality vector V_t = (1-λ)V_{t-1} +λ·f(dialogue / completion / behavior) accordingly. S4 Two-way rating and threshold determination (interpretable): Calculate user A's rating S_AB for user B and user B's rating S_BA for user A, and apply weight reduction and fairness constraints to sensitive information. When S_AB ≥ T_A and S_BA ≥ T_B, it is determined as a double threshold hit. S5 Threshold Takeover and State Switching (Method Termination): After both thresholds are hit, the avatar / watermark is forcibly switched to a real person, the proxy chat sandbox is sealed, a real person session handle is created, and the method state is terminated at the takeover event.

2. The method according to claim 1, characterized in that, The hard information includes, but is not limited to: age, city / commuting radius, education level range, income level range, marital status, height, and occupation / industry; the soft information includes multiple role selection and their weights, DIY role description, self-narrated text or speech transcription.

3. The method according to claim 1, characterized in that, The threshold compatibility filtering in step S1 further includes: when a candidate user has not yet set the threshold T_B, placing him / her in the pending list PENDING_TB, and then making a judgment after he / she sets the threshold.

4. The method according to claim 1, characterized in that, In step S2, the chat proxy sandbox enables a permission whitelist mechanism, prohibiting the following behaviors: sending phone numbers, WeChat IDs, email addresses, QR codes, short links, external links, and any form of personally identifiable information.

5. The method according to claim 1, characterized in that, The data completion request (RFI) in step S3 includes the completion field, the time-to-live (TTL) period, and the priority. Completion not completed within the TTL period will be recorded as RFI_EXPIRED and a penalty will be imposed in the scoring.

6. The method according to claim 1, characterized in that, The scoring function S in step S4 includes the following dimensions: personality similarity, interest matching, lifestyle fit, dialogue quality score, trust and authentication score, and is weighted and summed, sensitive components are reduced in weight and fairness constraints are applied, and the decomposed explanation and evidence map are output.

7. The method according to claim 1, characterized in that, After the takeover status switch in step S5, the chat history can only be viewed and contact information can only be selectively exchanged according to the level {summary, evidence section, full text} when both parties have reached a second agreement and the visibility level is consistent; otherwise, the chat history will remain encrypted and hosted, and the server will only store the hash and timestamp.

8. A multi-model collaborative AI-assisted online dating and matchmaking system based on dynamic personality and threshold takeover, characterized in that, include: M1 Identity and Authentication Module: Used to complete mobile phone number binding, device fingerprint recognition, liveness detection and document authentication, and generate identity anchor points and authentication levels; M2 Field Governance and Privacy Minimization Module: Used for field dictionary management, field modification work orders, and display granularity control; M3 Role and Personality Vector Engine: Used to fuse hard information, multi-select results from the role library, DIY role descriptions, and self-narrative text to generate an initial personality vector, and dynamically update it under RFI drive; M4 Matching and Threshold Compatible Filtering Module: Used to perform candidate filtering, and perform bidirectional matching filtering and sorting based on user-defined thresholds; M5 Consent and Identification Management Module: Used to collect two-way consent from AI-assisted chat, and control chat identification, avatar watermarks, and permission isolation; M6 Scoring and Explainable Engine: Used to calculate bidirectional scores S_AB / S_BA and output score decomposition, sensitive weighted execution status and evidence binding mapping; M7 Threshold Takeover Control Module: Used to trigger a takeover event after a double threshold is hit, switch avatar / watermark, seal the proxy chat domain, create a real-person session handle, and end this method.

9. The system according to claim 8, characterized in that, Also includes: M8 Security and Compliance Module: Used to perform security checks on all session content, blocking inappropriate content such as external links, contact information, PII, pornography, and hate speech; M9 Audit and Evidence Preservation Module: Used to record key events in the event chain format {seq, ts, prev_hash, event_hash}, perform batch anchoring, and generate anchor_id; M10 Encrypted Hosting Module: Used to encrypt and host chat records on the client side using session keys. The server only stores the hash+ts, and users can apply to export or delete the records.

10. A computer-readable storage medium having a computer program stored thereon, the program, when executed on a processor, causing a device to perform the steps of the method as described in any one of claims 1-7, comprising: The process includes data collection and initial personality construction, threshold setting and compatibility filtering, two-way consent data collection and sandbox creation, data completion and dynamic profile update, score decomposition and threshold determination, takeover triggering and state switching, and finally takeover completion as the termination point of the process. The chat logs are encrypted and hosted on the client side, and the server does not save plaintext, only hash and timestamp.

Images