Multi-source information fusion-based dynamic verification system and method for qualification of online car-hailing drivers

Abstract

The application provides a multi-source information fusion-based dynamic verification system and method for the qualification of a network car driver. The system includes a multi-source information collection module for receiving relevant data submitted by the driver end and performing consistency verification using a person-certificate consistency detection algorithm to generate a first verification result; a data consistency comparison module for cross-certificate comparison to generate a second verification result; an automated audit decision module for outputting a driver qualification audit conclusion and conclusion identifier based on a pre-set city audit rule library and the second verification result; a training task management module for matching and assigning training course tasks to the target driver account based on the conclusion identifier, and receiving the training completion status; and a vehicle permission control module for opening or maintaining restrictions on the order receiving permission of the target driver account based on the conclusion identifier and the training completion status, and dynamically adjusting the order receiving permission. The application can achieve fast audit, automatic training distribution, data linkage, and real-time dynamic compliance control.

Description

Technical Field

[0001] This application relates to the field of Internet vehicle technology, and in particular to a dynamic verification system and method for ride-hailing driver qualifications based on multi-source information fusion. Background Technology

[0002] With the rapid development of the mobile transportation industry, ride-hailing platforms are aggregating social vehicles and drivers to increase capacity. While ensuring passenger safety and service quality, platforms must verify drivers' identities, driving qualifications, vehicle conditions, and compliance certificates before they go online, and complete training and registration according to city regulatory requirements. Therefore, efficiently completing driver registration and dynamic qualification management within a compliant framework has become a core technical requirement for platform operation and regulatory collaboration.

[0003] Existing ride-hailing platforms typically employ a sequential, manual process: "document upload—manual review—manual assignment of training tasks—activation of order-taking permissions after successful training." Drivers must submit multiple copies of their ID card, driver's license, vehicle registration certificate, and vehicle photos, with each round of review involving manual verification of document authenticity and consistency. After approval, operations staff manually provide drivers with training courses, which drivers must complete and pass an assessment before they can accept orders. Some platforms have introduced single-point technologies such as OCR or facial recognition to improve efficiency, but this still lacks an end-to-end automated closed loop and the ability to flexibly adapt to city-specific compliance strategies.

[0004] Therefore, existing technologies still have the following problems: the registration process is lengthy, requiring repeated submission of materials, resulting in excessive waiting time for drivers and potential loss of transportation capacity; manual review is inefficient and struggles to accurately identify forged documents, leading to high operational labor costs; training tasks need to be manually assigned, which can easily result in omissions or delays, affecting drivers' timely online participation; registration information, vehicle information, compliance information, and training records are fragmented, lacking data linkage and cross-verification mechanisms, making dynamic compliance monitoring impossible; existing solutions lack the ability to quickly configure and adapt to the access rules of different cities, making it difficult to meet the continuous iteration of regulatory requirements. Summary of the Invention

[0005] In view of this, the embodiments of this application provide a dynamic verification system and method for ride-hailing driver qualifications based on multi-source information fusion, in order to solve the problems of inefficient review, missed training and dispatch, information silos and lack of dynamic compliance in the existing technology.

[0006] The first aspect of this application provides a dynamic verification system for ride-hailing driver qualifications based on multi-source information fusion, comprising: a multi-source information acquisition module, used to receive identity information, driver's license information, vehicle registration information, and vehicle image data submitted by the driver, and to perform consistency verification using a person-document consistency detection algorithm to generate a first verification result; a data consistency comparison module, used to perform cross-document comparison of driver, driver's license, vehicle, and validity period fields based on the first verification result to generate a second verification result; and an automated review decision module, used to output driver qualification review results based on a preset city review rule base and the second verification result. The system includes: a conclusion and corresponding conclusion identifier; a training task management module, used to match and assign training course tasks to the target driver account based on the conclusion identifier when the driver qualification review conclusion is passed, and to receive the training completion status; a vehicle access control module, used to enable or restrict the order-taking permissions of the target driver account based on the conclusion identifier and training completion status, and to dynamically adjust the order-taking permissions when changes in the reservation status related to the vehicle are detected; and a compliance data storage module, used to hash the first verification result, the second verification result, the driver qualification review conclusion, the training completion status, and the permission adjustment record and write them into the blockchain ledger.

[0007] The second aspect of this application provides a method for dynamic verification of ride-hailing driver qualifications based on the system of the first aspect, including: receiving identity information, driver's license information, vehicle registration information, and vehicle image data submitted by the driver; calling a human-document consistency detection algorithm to perform liveness detection and facial fingerprint comparison to generate a first verification result; performing cross-document comparison on the driver, driver's license, vehicle, and validity period fields based on the first verification result to obtain a second verification result; performing automated verification using a preset city verification rule base and in combination with the second verification result, and outputting a driver qualification verification conclusion and a corresponding conclusion identifier; when the driver qualification verification conclusion is passed, according to the conclusion identifier... The system assigns training course tasks to the target driver account and obtains the training completion status; writes or maintains an order-accepting permission token for the target driver account based on the conclusion identifier and training completion status; continuously obtains at least one of the vehicle annual inspection status, vehicle insurance status, or traffic violation status, generates a status event stream, and determines whether a threshold is triggered. If triggered, it updates the order-accepting permission token and records the permission adjustment; it adds type tags and timestamps to the first verification result, second verification result, driver qualification review conclusion, training completion status, and permission adjustment record, performs salted hash operation, inserts it into a Merkle tree, and writes the calculated root hash into the consortium blockchain ledger through a smart contract.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0009] The system employs a multi-source information acquisition module to receive identity information, driver's license information, vehicle registration information, and vehicle image data submitted by the driver. It then uses a person-document consistency detection algorithm to perform consistency verification and generate a first verification result. A data consistency comparison module compares the driver, driver's license, vehicle, and validity period fields against the first verification result to generate a second verification result. An automated review and decision-making module outputs a driver qualification review conclusion and corresponding conclusion identifier based on a preset city review rule base and the second verification result. A training task management module matches and assigns training course tasks to the target driver account based on the conclusion identifier when the driver qualification review conclusion is passed, and receives the training completion status. A vehicle access control module enables or restricts the order-taking permissions of the target driver account based on the conclusion identifier and training completion status, and dynamically adjusts order-taking permissions when changes in vehicle-related reservation status are detected. A compliance data storage module hashes the first verification result, second verification result, driver qualification review conclusion, training completion status, and permission adjustment records and writes them to the blockchain ledger. This application enables rapid review, automated training and distribution, data linkage, and real-time dynamic compliance management. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the structural composition of the ride-hailing driver qualification dynamic verification system based on multi-source information fusion provided in the embodiments of this application;

[0012] Figure 2 This is a flowchart illustrating the dynamic verification method for ride-hailing driver qualifications provided in this application embodiment. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] As the demand for ride-hailing services increases, various ride-hailing platforms are expanding their capacity. The current driver registration process typically includes: driver registration, submission of personal information, driver's license, vehicle registration certificate, vehicle photos, etc. -> manual review -> after approval, the driver uploads compliant documents -> manual review -> manual assignment of training tasks -> after training, the driver can start driving. This process has the following problems:

[0015] 1) Long registration process and high threshold for driver registration: The driver registration process is long and time-consuming, requiring repeated supplementary materials, which can easily lead to driver turnover.

[0016] 2) Low review efficiency, poor user experience, and high labor costs: Manual review is time-consuming, drivers have long waiting times, it is difficult to verify the authenticity of information, and there is a risk of fraud.

[0017] 3) Training tasks rely on manual sending: Training tasks need to be manually sent to drivers who have passed the review, which can easily lead to missed sending, preventing drivers from participating in training and driving, thus affecting drivers' ability to drive and accept orders.

[0018] 4) Information silos: Registration information, vehicle information, compliance information, training information, and other information lack effective linkage and automatic verification mechanisms.

[0019] The aforementioned issues mean that drivers wishing to register and start driving need to submit materials according to platform rules. However, drivers must submit materials multiple times, and each submission requires review, resulting in a lengthy submission process and long waiting times. This can discourage drivers from registering, leading to a loss of transportation capacity. Furthermore, manual review requires multiple verifications of the submitted materials, and the authenticity is not easily guaranteed, posing a risk of fraud. Current technology lacks linkage and verification capabilities for driver information, thus contributing to the lengthy driver submission process and time-consuming manual review.

[0020] In view of the problems existing in the prior art, this application provides a dynamic verification system for ride-hailing drivers' qualifications based on multi-source information fusion. This system involves functions such as ride-hailing driver registration, automated verification using multi-source information, identification of driver authenticity, and dynamic vehicle binding. It aims to improve the timeliness of driver registration, reduce enterprise labor costs, increase enterprise capacity, and ensure driver compliance rates. This application overcomes the problems of cumbersome document submission, low review efficiency, poor training flexibility, and insufficient information verification in existing technologies. It provides an automated, intelligent, and highly flexible driver registration solution, enabling drivers to receive review results immediately after submitting their documents, automatically participate in training after passing the review, and automatically resume driving after completing training.

[0021] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, outlines the framework and functions of the dynamic verification system for ride-hailing driver qualifications based on multi-source information fusion provided in this application. Figure 1 This is a schematic diagram of the structural composition of the ride-hailing driver qualification dynamic verification system based on multi-source information fusion provided in the embodiments of this application, as shown below. Figure 1 As shown, the dynamic verification system for ride-hailing driver qualifications based on multi-source information fusion may specifically include the following modules:

[0022] The multi-source information acquisition module 101 is used to receive identity information, driver's license information, vehicle registration information and vehicle image data submitted by the driver, and to perform consistency verification using the identity verification algorithm to generate the first verification result.

[0023] The data consistency comparison module 102 is used to perform cross-document comparison of the driver, driver's license, vehicle and validity period fields based on the first verification result, and generate a second verification result.

[0024] The automated review decision module 103 is used to output the driver qualification review conclusion and the corresponding conclusion identifier based on the preset city review rule base and the second verification result;

[0025] The training task management module 104 is used to match and assign training course tasks to the target driver account based on the conclusion identifier when the driver qualification review conclusion is passed, and to receive the training completion status.

[0026] The vehicle access control module 105 is used to enable or restrict the order-accepting permissions of the target driver account based on the conclusion identifier and training completion status, and to dynamically adjust the order-accepting permissions when the scheduled status related to the vehicle is detected to change.

[0027] The compliance data storage module 106 is used to hash the first verification result, the second verification result, the driver qualification review conclusion, the training completion status and permission adjustment record and write them into the blockchain ledger.

[0028] In some embodiments, the multi-source information acquisition module further includes:

[0029] The OCR recognition submodule is used to extract text and structured fields from identity information, driver's license information, vehicle registration information and vehicle image data;

[0030] The External Authoritative Interface Call Submodule is used to synchronously call external authoritative data interfaces and insurance database interfaces based on structured fields, and return verification data.

[0031] Specifically, in this embodiment, the multi-source information acquisition module is deployed within the microservice cluster at the system backend and interacts with the driver-side application through a secure transmission channel. This multi-source information acquisition module is further subdivided into an OCR recognition submodule and an external authoritative interface call submodule. Their coordination in the business process is as follows:

[0032] First, the driver uploads images of their ID card, driver's license, vehicle registration certificate, and four views of the vehicle sequentially via the interactive interface. Upon completion of the upload, an event message is triggered, and the backend message bus pushes the message to the OCR recognition submodule. The OCR recognition submodule uses a pre-trained convolutional attention network model to perform layout analysis and text detection on the images, automatically extracting fields such as name, ID card number, driver's license number, vehicle model, vehicle identification number, license plate number, certificate issuance date, and certificate expiration date. These fields are then converted into a unified JSON structure according to a predefined field mapping specification. For the vehicle photo, this submodule also detects the license plate area using an image segmentation algorithm, performs license plate character recognition, and compares the recognition result with the license plate number in the vehicle registration certificate in real time. If discrepancies are found, a preliminary anomaly marker is added to the JSON structure.

[0033] Subsequently, the external authoritative interface call submodule receives the JSON structure output by the OCR recognition submodule and automatically matches the interface template according to the field type. For the ID card number and name fields, the submodule initiates a synchronous query to the population information interface; for the combination of driver's license number and ID card number, it queries the traffic management department's driver's license status interface for the permitted vehicle types and demerit point status; for the combination of vehicle identification number and license plate number, it queries the vehicle management office's vehicle registration information interface for vehicle registration information, annual inspection status, and mandatory scrapping date; for the insurance company code and license plate number, it queries the insurance database interface for the validity period of compulsory traffic accident liability insurance and commercial insurance. All external interface calls are authenticated and encrypted at the unified gateway layer, and the call results are written back to the external authoritative interface call submodule via asynchronous callbacks.

[0034] Furthermore, after receiving responses from various authoritative data sources, the external authoritative interface call submodule compares the consistency between the OCR recognition results and the authoritative return results according to the field mapping specifications. For fields that are completely consistent, a "verification passed" flag is written; for fields that differ, a "verification failed" flag is written along with a reason code for the difference. Finally, the submodule packages the structured data containing the OCR fields, authoritative fields, and consistency flags into the first verification result and pushes it to the data consistency comparison module to enter the subsequent cross-document comparison and risk assessment process.

[0035] Through the above specific embodiments, the OCR recognition submodule and the external authoritative interface call submodule have achieved a closed loop of image field extraction and multi-source authoritative data verification under the event-driven architecture, providing accurate and reliable original verification data for the system's subsequent automated review decisions.

[0036] In some embodiments, a consistency verification algorithm is used to generate a first verification result, including:

[0037] The driver's device simultaneously acquires RGB and near-infrared image sequences using a multispectral camera and randomly issues action commands to perform liveness detection.

[0038] In the target frame that passes the liveness detection, a three-dimensional temporal pose decoding network is used to extract the facial depth feature vector, and a multimodal depth feature fusion network is used to generate the first face fingerprint.

[0039] The same deep feature fusion network is used to generate a second facial fingerprint from the ID photo image in the identity information.

[0040] The first and second facial fingerprints are input into a bidirectional hash quantization encoder to obtain corresponding hash vectors, and the facial similarity score is calculated based on the hash vectors.

[0041] When the face similarity score is higher than the preset consistency threshold, a human identity consistency field containing a consistency flag is generated and written into the first verification result.

[0042] Specifically, in a preferred embodiment, after the driver initiates the registration process on the mobile device, the system first pushes random action instructions to the terminal via the liveness detection SDK, such as "turn your head to the left and blink" or "look up and open your mouth." The terminal's built-in multispectral camera simultaneously activates the visible light RGB sensor and the near-infrared sensor to synchronously acquire continuous image sequences; the server and the terminal verify each other through timestamps and random challenge codes to ensure that the action responses belong to the same session.

[0043] Once the terminal detects that a random action has been correctly executed, it aligns the near-infrared and RGB channels in the same frame and uploads it. The backend liveness detection module uses a 3D temporal pose decoding network to analyze the pose change trajectory of the face in the most recent three frames and estimate depth information, thereby eliminating the risk of headshot re-enactment and screen replay. The system only retains target frames that pass liveness detection and extracts the face region from those frames.

[0044] Within the face region, the algorithm first acquires apparent texture features through improved depthwise separable convolution, then incorporates point cloud data generated by a depth camera to encode the face geometry in the form of a three-dimensional dense pose field. Both are then input into a multimodal depth feature fusion network, outputting a 256-dimensional first face fingerprint. This fingerprint simultaneously contains texture distribution, depth gradient, and local curvature information, and is resistant to common lighting and pose interference.

[0045] The system then retrieves the ID card image uploaded by the corresponding driver in the background, and performs cropping, alignment, and Gamma correction on the ID photo. After processing by the same multimodal deep feature fusion network, a second facial fingerprint is generated. To maintain consistency with the first fingerprint, the ID photo undergoes color space mapping and pseudo-depth inference, enabling the algorithm to output a feature vector of uniform dimension even without real depth information.

[0046] In some examples, to reduce the risk of sensitive biometric data leakage, the system generates hash vectors for each of the two sets of fingerprints using a bidirectional hash quantization encoder. This encoder maps real-valued vectors to fixed bit strings based on the principle of locality-sensitive hashing, and embeds a dynamic key during the mapping process, thereby blocking the reverse reconstruction path of the vectors.

[0047] During the matching phase, the backend decodes two sets of hash vectors in secure memory and calculates the cosine similarity to obtain a face similarity score in the 0-1 range. The platform presets a consistency threshold of 0.85 based on the business security level. If the score is higher than the threshold, the system writes the field "face_match:true" and the actual score into the first verification result; if it is lower than the threshold, it writes "face_match:false" and appends an inconsistency reason code.

[0048] The initial verification result is returned to the data consistency comparison module in the form of a JSON object, simultaneously triggering subsequent cross-document comparison and city rule review processes. Through this embodiment, a seamless link is formed between multispectral liveness detection, 3D pose deep fusion, facial fingerprint hashing, and threshold comparison, ensuring that the driver is genuinely online and that the ID photo matches the real-time face, providing a reliable basis for the consistency of identity and document verification for overall automated review.

[0049] In some embodiments, a second verification result is generated by performing cross-document comparison on the driver, driver's license, vehicle, and validity period fields based on the first verification result, including:

[0050] Based on the field mapping table, the ID card number, name, driver's license number, vehicle identification number, license plate number, and validity period of each document from the first verification result are written into the heterogeneous entity relationship graph;

[0051] A dual-channel contrastive learning network is used to extract the graph embedding vectors of nodes with the same name in the heterogeneous entity relationship graph, and the similarity of node pairs is calculated by cosine distance to obtain the field consistency confidence matrix.

[0052] An adaptive time decay model is used to map the expiration time to a timeliness risk score for the validity period field, and then the score is fused with the field consistency confidence matrix according to a preset weight to generate a comprehensive consistency score.

[0053] When the overall consistency score is higher than the consistency threshold, the consistency flag is written into the second verification result; if it is lower than the consistency threshold, the conflict field and conflict type are recorded and an inconsistency flag is generated to form the second verification result.

[0054] Specifically, in this embodiment, the system immediately initiates the cross-document comparison process after generating the first verification result. First, the data consistency comparison module, based on a predefined field mapping table, writes the ID card number, name, driver's license number, vehicle identification number (VIN), license plate number, and corresponding document validity period fields from the first verification result into a heterogeneous entity relationship graph. This graph is modeled using "driver-document-vehicle" triples, where each node carries the original field value and a data source label, and edges identify the attribution or pointing relationship between fields. To avoid graph expansion, the system deduplicates the same field value, retaining only unique node instances.

[0055] Furthermore, after the graph construction is completed, the dual-channel contrastive learning network begins operation. One side of the network takes structured field features (such as character sequences, encoding rules, and length features) as input, while the other side takes contextual structure features (such as node position, in-degree, out-degree, and edge type) as input. Both sides output 128-dimensional local embedding vectors, which are concatenated into a 256-dimensional graph embedding vector through a shared projection layer. The system takes vectors from each pair of nodes within the graph marked as "same-name fields," calculates the cosine distance, and converts it into a similarity value in the 0-1 interval, thus obtaining a field consistency confidence matrix. Each row of the matrix corresponds to the matching degree of a field between different documents, and each column corresponds to the consistency degree of the target field between different sources.

[0056] Furthermore, for the validity period field of each document, the system introduces an adaptive time decay model for risk quantification. The model takes the difference between the current date and the expiration date as input and sets different risk decay curves based on the document type: linear decay for driver's licenses, piecewise gradient decay for vehicle registration certificates, and exponential decay for vehicle inspection certificates. The output is uniformly mapped to a time-related risk score in the range of 0-1, with higher values ​​indicating that the document is closer to expiration.

[0057] Subsequently, the module merges the field consistency confidence matrix and the timeliness risk score field by field according to preset weights to generate a comprehensive consistency score. For example, the system can assign a weight of 0.4 to the comparison of ID card number and driver's license number, a weight of 0.3 to the comparison of VIN and license plate number, and a weight of 0.3 to the timeliness risk score. The module normalizes all weights and adds them together to obtain a single score.

[0058] In some examples, the system sets 0.85 as the consistency threshold. When the overall consistency score is not lower than the threshold, the module writes the field "consistency:true" and the score to the second verification result; if the score is lower than the threshold, it records the list of conflicting fields and the conflict type, such as "VIN-plate mismatch" or "license_expired", and writes "consistency:false". The second verification result is finally pushed to the automated review and decision-making module in JSON format, providing a data foundation for subsequent city rule graph reasoning and risk scoring.

[0059] This embodiment constructs a heterogeneous entity relationship graph, introduces a dual-channel contrastive learning network and an adaptive time decay model, and performs unified vectorized comparison and timeliness risk quantification on multiple fields of people, certificates, and vehicles. This enables the system to instantly determine the authenticity, validity and timeliness of certificate information with a single comprehensive consistency score, thereby completing cross-certificate verification without human intervention, significantly improving verification accuracy and processing efficiency, and providing a high-confidence data foundation for subsequent automated review decisions.

[0060] In some embodiments, based on a preset city verification rule base and the second verification result, the driver qualification verification conclusion and corresponding conclusion identifier are output, including:

[0061] The second verification result is mapped into a multi-dimensional risk vector containing field consistency score, remaining validity period, traffic violation level and vehicle inspection status using a feature vectorization engine.

[0062] The compilerable rule graph generator for the city dimension is invoked to dynamically compile the city review rule base into a weighted directed graph. Then, graph traversal reasoning is performed on the weighted directed graph based on the multi-dimensional risk vector to obtain the initial review decision node.

[0063] The initial review decision node is matched with the historical data output by the deep contrastive learning model using cosine similarity through sample embedding vectors. If the similarity is lower than a preset threshold, the rule incremental learning unit is triggered to update the city review rule base.

[0064] When the initial review decision node meets the graph traversal confidence threshold, a driver qualification review conclusion is generated based on the node type: pass, fail, or require supplementary materials. At the same time, a unique conclusion identifier is generated by combining the city code, vehicle type code, and risk level.

[0065] Specifically, in this embodiment, the automated review decision module is located in the backend decision engine cluster. It works in conjunction with a stateless service and a Redis cache to ensure millisecond-level response even under high-concurrency registration scenarios. The overall implementation process of this embodiment is as follows:

[0066] First, the module receives the second verification result from the data consistency comparison module. The feature vectorization engine extracts risk factors according to predefined field definition specifications, including field consistency scores, remaining validity periods of each document, driver's traffic violation levels over the past three years, and vehicle inspection status. For the remaining validity period field, the system maps the number of days to a 0-1 range using logarithmic compression; for traffic violation levels and vehicle inspection status, the system uses a hierarchical mapping table to convert different severity levels into quantitative scores. Finally, the multidimensional risk factors are concatenated into a 64-bit risk vector and written to a Kafka topic for rapid retrieval by subsequent decision-making services.

[0067] Furthermore, once the risk control service consumes a risk vector, it retrieves the corresponding configuration from the city review rule base using the target city code as the key. The city review rule base is maintained in JSON-LD format, with fields including threshold conditions, weight parameters, and additional city regulatory requirements. A city-dimensional compilable rule graph generator dynamically compiles this JSON-LD file into a weighted directed graph, where nodes represent rule sets and edge weights represent matching priorities. The root node is "Registration Initial Review," and leaf nodes correspond to three final states: "Passed," "Failed," or "Supplementary Materials Required."

[0068] Furthermore, the system then performs top-down graph traversal reasoning on the weighted directed graph. During the traversal, the risk vector is multiplied by the set of node rules to obtain a matching score. If the score is higher than the node threshold, the system continues along the higher-weighted edge; otherwise, it proceeds along the lower-weighted edge to obtain supplementary materials or skips the branch. At the end of the traversal, the algorithm reaches a leaf node, forming the initial review decision node, along with a graph traversal confidence value.

[0069] In some examples, to prevent fixed rules from misjudging extreme samples, the system introduces a historical sample embedding library based on a deep contrastive learning model. The model first generates 512-dimensional embedding vectors from historical samples and indexes them using the Faiss engine. The system passes the risk vector through the same network to obtain the embedding to be reviewed, calculates the cosine similarity with the sample vectors in the library, and if the highest similarity is below the safety threshold of 0.65, the current sample is determined to have unknown risk characteristics, triggering a rule incremental learning unit. The incremental learning unit performs differential analysis on the current sample and its graph traversal path, automatically reducing the weight of conflicting rules or generating new rule nodes, and writes them back to the city review rule library. After the update is complete, the system re-executes the graph traversal inference to obtain the corrected review conclusion.

[0070] In some examples, when the graph traversal confidence value is higher than 0.9, the system outputs the driver qualification review conclusion based on the leaf node type and generates a unique conclusion identifier in the format of "city code + vehicle type code + three-digit risk level code + timestamp random number". For example, the conclusion identifier generated for a new energy ride-hailing vehicle in Beijing under the low-risk level could be "BJ-EV-001-1720001234". The review conclusion and conclusion identifier are pushed to the training task management module and the vehicle access control module, and simultaneously written to the driver profile collection in MongoDB, realizing the automatic connection of registration, training, and vehicle dispatch.

[0071] Through the above embodiments, the automated review decision-making module utilizes vectorized risk assessment, compilable rule graph reasoning, and a comparative learning-driven incremental self-learning mechanism to achieve online adaptation and self-iterative updates to compliance strategies in different cities. This significantly reduces manual intervention while maintaining high accuracy, ensuring a fast, stable, and easily traceable review process.

[0072] In some embodiments, the training task management module further includes:

[0073] The course library submodule is used to store training course metadata associated with city, vehicle type, and driver type;

[0074] The task scheduling submodule is used to call the course library submodule to generate training tasks based on the conclusion identifier;

[0075] The progress tracking submodule is used to receive training progress and assessment results from the driver's end via the application programming interface and generate a training completion status.

[0076] Specifically, in this embodiment, the training task management module is deployed in the platform's "Training and Compliance" service domain, forming a closed loop with the automated review and decision-making module and the vehicle access control module. This module is further subdivided into a course library submodule, a task scheduling submodule, and a progress tracking submodule, and the collaborative process of each submodule is as follows.

[0077] First, the course library submodule is implemented as a multi-tenant relational database. The core table structure uses city code, vehicle type code, and driver type as a composite index to store metadata such as course identifier, course duration, required course markers, exam question bank version, course validity period, and regulatory filing code. To cope with frequent updates to city policies, the submodule supports an incremental hot-loading mechanism: when the education commission or transportation management department pushes new course instructions, the database can be written in real-time through the metadata change interface without system downtime.

[0078] Furthermore, when the automated review and decision-making module outputs a "Review Passed" conclusion, it writes the conclusion identifier to a Kafka topic. The task scheduling submodule listens to this topic and parses the city code, vehicle type code, and risk level bit in the conclusion identifier. The submodule first queries the course library submodule for the list of required courses for the corresponding city and vehicle type; if the risk level is higher than a set threshold, it automatically adds a "Safety Education" or "Civilized Service" supplementary course. Subsequently, the submodule generates a unique training task number, writes it to the training task table, and sends the training list and completion deadline to the driver's app via the push gateway. To prevent drivers from missing notifications, the submodule sends push notifications through both the app's message center and SMS channels.

[0079] Furthermore, when the driver opens a training course, the progress tracking submodule exposes a REST interface that receives events such as "Start," "Chapter Completed," and "Exam Submitted." Each event includes a task number, course number, progress percentage, and a verifiable signature. The submodule temporarily stores the events in a Redis pipeline buffer, asynchronously writes them to the training progress table in PostgreSQL, and calculates the remaining course duration in real time. For exam submission events, the submodule calls the question bank grading engine to provide an instant score and writes the score and pass / fail flag back to the progress table.

[0080] In some examples, when all required courses under the same task reach 100% completion and all exam scores are above the 80-point threshold, the progress tracking submodule generates a training completion status object, which includes the task number, completion timestamp, and signature hash, and sends it to the vehicle access control module via the internal message bus. If the course is not completed before the deadline, the submodule automatically resets the deadline for the incomplete course and sends a reminder; if there are two consecutive overdue deadlines, the task scheduling submodule is invoked to reschedule the course and the risk level is increased by one level to ensure the seriousness of the training.

[0081] By adopting a three-layer architecture of "metadata-driven course library + event-driven task scheduling + real-time progress tracking", this embodiment realizes the ability to accurately distribute city-differentiated courses, make training progress visible in real time, and make up for lessons according to risk level. This ensures that drivers can quickly and accurately complete the required training after the review is approved, providing a reliable prerequisite for the safe release of subsequent order-taking permissions.

[0082] In some embodiments, the order-accepting permissions of the target driver account are enabled or restricted based on the conclusion identifier and training completion status, and the order-accepting permissions are dynamically adjusted when a change in the predetermined status related to the vehicle is detected, including:

[0083] When the training completion status indicates that the training course corresponding to the target driver account has been qualified and the conclusion indicator indicates that the review has been passed, write an order-accepting permission token to the target driver account.

[0084] Continuously acquire at least one of the vehicle annual inspection status, vehicle insurance status, or traffic violation status and generate a status event stream;

[0085] The status event stream is judged in real time according to the preset threshold rules, and the permission adjustment command is output when any vehicle status triggers the threshold.

[0086] According to the permission adjustment instruction, the order-accepting permission token is updated to a restricted order-accepting permission token or restored to an order-accepting permission token, and each permission adjustment record is encrypted and hashed before being written into the blockchain ledger.

[0087] Specifically, in this embodiment, the vehicle access control module is deployed in the platform's "real-time risk control" service domain, forming a closed-loop management system with the training task management module and the compliance data storage module through an event-driven architecture. The core of the module consists of four sub-components: an access token generator, a vehicle status listener, a threshold determination engine, and a blockchain writer. Its operation flow is as follows.

[0088] First, when the training completion status pushed by the progress tracking submodule indicates that the target driver account is qualified and the corresponding conclusion marker indicates that the review has been passed, the permission token generator immediately writes an order-accepting permission token for the driver account in the high-performance in-memory database. The token is generated by concatenating the fields "driver ID + city code + vehicle code + effective timestamp + expiration timestamp" and then hashing and encrypting them. The expiration timestamp is set to 180 days by default and is used for subsequent periodic refresh of permissions. At the same time, the token generator synchronizes the token fingerprint to the Redis cache for quick verification by the scheduling layer.

[0089] Furthermore, to continuously monitor the real-time compliance status of vehicles, the vehicle status listener acquires vehicle inspection, insurance, and traffic violation information through three data streams. The first stream is collected by a Bluetooth box installed at the vehicle's OBD interface, which gathers mileage and diagnostic data and uploads it via Bluetooth from a mobile phone. The second stream is pushed daily by the annual inspection and insurance status API, which interfaces with the vehicle management office. The third stream is pushed by the city's traffic enforcement platform via MQ to record the latest violation records. The listener merges these three streams and writes them into a Kafka topic, forming a status event stream.

[0090] Furthermore, the threshold determination engine, based on the Complex Event Processing (CEP) framework, performs real-time rule matching on the state event stream. The engine incorporates a two-level threshold model: the first level is an absolute threshold, such as triggering a warning if the remaining days for the annual vehicle inspection are less than 30 days or the remaining days for insurance are less than 15 days; the second level is a gradient threshold, such as triggering a high-risk freeze if a vehicle has committed three or more serious traffic violations in the past 30 days. When either threshold is triggered, the determination engine immediately outputs a permission adjustment command along with a reason code.

[0091] Furthermore, after receiving the permission adjustment instruction, the permission token scheduler invokes an atomic comparison and exchange operation to update the order-accepting permission token to a restricted order-accepting permission token. If the vehicle status is subsequently detected to have returned to a safe range, the restricted token is restored to an order-accepting token. To avoid frequent fluctuations, the system sets a limit on the number of permission switches for the same vehicle within 24 hours. If this limit is exceeded, automatic recovery is paused and manual review is notified. Each token status change generates a permission adjustment record, which includes the driver ID, vehicle ID, status before and after the adjustment, reason code, and timestamp.

[0092] Furthermore, the blockchain writer performs salted hashing on the permission adjustment records, constructs Merkle trees in batches, calculates the root hash, and then calls the consortium blockchain smart contract to write the latest block. Upon successful writing, the blockchain returns the block height and transaction hash, which the writer appends to the adjustment record, achieving immutable evidence storage.

[0093] Through the above embodiments, the system immediately issues order-accepting tokens upon successful training and achieves fine-grained dynamic control over drivers' order-accepting permissions by relying on multi-source vehicle status streams, real-time CEP determination, and atomic token switching; simultaneously, blockchain-based evidence storage ensures full traceability of permission changes. This solution minimizes manual intervention while ensuring compliance, improving capacity scheduling efficiency and platform risk control transparency.

[0094] In some embodiments, the first verification result, the second verification result, the driver qualification review conclusion, the training completion status, and the permission adjustment record are hashed and written into the blockchain ledger, including:

[0095] Add type tags and timestamps to the first verification result, the second verification result, the driver qualification review conclusion, the training completion status and permission adjustment record, and write them to the buffer queue.

[0096] When the preset submission trigger condition is met, a cryptographic hash operation is performed on each piece of data in the buffer queue using a random salt value combined with a high-entropy counter to generate a data hash entry.

[0097] Insert the data hash entries into the Merkle tree in the queue order and calculate the corresponding root hash;

[0098] The smart contract deployed on the consortium blockchain is invoked to submit the root hash along with the timestamp and type label index to the blockchain transaction pool;

[0099] After a transaction is confirmed by the blockchain consensus mechanism, a confirmation identifier is returned, and the confirmation identifier is associated with the corresponding data hash entry to complete the notarization.

[0100] Specifically, in this embodiment, the compliance data storage module runs on the system's "blockchain storage layer" and is interconnected with the multi-source information collection module, automated review and decision-making module, training task management module, and vehicle access control module via an event bus. Internally, it comprises four core units: a buffer queue manager, a cryptographic hash generator, a Merkle tree constructor, and an on-chain submitter. The specific workflow is as follows:

[0101] First, when the first verification result, the second verification result, the driver qualification review conclusion, the training completion status, or the permission adjustment record are generated in each business module, the event bus immediately pushes the data packet, data type label, and event timestamp to the buffer queue manager. The manager partitions the data according to the type label, writes it to a high-throughput message queue, and writes a uniform timestamp field in the message header for easy batch aggregation later.

[0102] Furthermore, the buffer queue manager continuously monitors the queue length and time window. When a single partition accumulates more than 500 data entries, or the earliest data entry has resided for more than 30 seconds, the preset commit trigger condition is met. The manager then triggers a batch processing signal, invoking the cryptographic hash generator to process each data entry in the current batch. The cryptographic hash generator first concatenates a 16-byte random salt value for each data entry, then introduces a high-entropy counter sequence number, and subsequently performs a SHA-3-512 hash operation to generate a data hash entry, retaining the salt value and counter for future verification.

[0103] Furthermore, the generated hash entries are kept in their original queue order and sequentially fed into the Merkle tree constructor. The constructor aggregates the entries from bottom to top using a binary leaf node approach until a single root hash is calculated. To reduce the cost of writing to the blockchain, only the root hash is submitted in the same batch, without submitting all leaf nodes. The leaf nodes, along with the salt value and counter, are stored locally in an encrypted manner, allowing for replaying of the computation chain for consistency verification during regulatory audits.

[0104] Furthermore, after receiving the root hash, the on-chain submitter invokes the notarization smart contract deployed on the consortium blockchain via a TLS tunnel. The submitted transaction includes the root hash, batch start timestamp, data type tag index, and caller signature. After the contract uses the PBFT consensus algorithm to confirm the transaction's validity, the node writes the root hash into the latest block and includes the block height and transaction hash as confirmation identifiers in the return value.

[0105] Furthermore, upon receiving the confirmation identifier, the on-chain submitter binds it to each local data hash entry, forming a complete evidence record and writing it to a read-only archive. Simultaneously, it sends a receipt to the calling business module, allowing it to display the "on-chain" status on the audit interface. When regulatory authorities require verification, they can index the corresponding block using the block height, extract the root hash, and compare it with the local recalculation result to confirm that the data has not been tampered with.

[0106] Random salt values ​​and high-entropy counters ensure that the hash of a single data entry is difficult to reverse using rainbow tables; Merkle tree batch aggregation reduces on-chain storage and consensus overhead; consortium blockchain smart contract writing provides cross-entity, tamper-proof third-party credentials; the entire process achieves full-volume trusted evidence storage of verification data, audit conclusions, training status, and permission changes, which not only meets regulatory traceability requirements but also ensures writing efficiency and data security under high concurrency.

[0107] In some embodiments, the system further includes an anomaly review module, which generates a manual review work order and receives the manual review result when the similarity output by the automated review decision module is lower than a preset threshold or the data consistency comparison module detects a field conflict, and uses the manual review result to overwrite the corresponding driver qualification review conclusion.

[0108] Specifically, in this embodiment, the anomaly review module is deployed in the system's "human-machine collaborative review" service domain. It consists of a trigger detection unit, a work order generation unit, a manual processing interface unit, and a result write-back unit, and maintains an event cascade relationship with the automated review decision module and the data consistency comparison module.

[0109] When the automated review decision module performs the initial review, if any of the following indicators—facial fingerprint cosine similarity, historical sample similarity, or graph traversal confidence—falls below the system-set security threshold of 0.65, or if the data consistency comparison module flags a cross-document field conflict (e.g., the ID card number and driver's license number are inconsistent), the trigger detection unit immediately captures the abnormal event. The trigger detection unit organizes the abnormal type, trigger reason code, driver basic information, and relevant verification screenshots into a structured abnormal data packet and writes it to the Kafka topic "exception.review".

[0110] The work order generation unit listens to the "exception.review" topic, generates a unique review work order number for each abnormal data packet according to the order of event arrival, and indexes it in the elastic search engine. The work order content includes the triggering module, threshold value, conflict fields, system-suggested measures, and attachment links. This unit pushes the work order to the to-do list of the corresponding city quality inspection team based on the role-based routing strategy, and sends review reminders via WeChat Work robot.

[0111] The manual processing interface is implemented as a low-code cloud-based webpage. After logging in, reviewers can view the complete verification process details, image comparison results, and discrepancies in authoritative data comparisons. It supports one-click zooming in on document images, frame-by-frame viewing of liveness videos, and re-initiating authoritative API queries. Reviewers can choose from three review conclusions on the interface: "Approved," "Rejected," or "Requires Supplementary Materials," and can add text descriptions. The system records the reviewer's identity and operation time through single sign-on and operation log middleware, ensuring traceability of responsibility.

[0112] After the reviewer submits their conclusion, the result write-back unit listens for work order status change events, writes the manual review result to the MongoDB manual review collection, and calls the write-back interface exposed by the automated review decision module to overwrite the original review conclusion. If the review conclusion is "passed," the system adds the risk level bit to the conclusion identifier and re-triggers the training task management module. If the review conclusion is "rejected" or "requires supplementary materials," the system automatically changes the driver's file status and sends SMS and App notifications, prompting the driver to submit supplementary materials or end the registration process. In addition, the result write-back unit also writes the review sample and its final label into the incremental training dataset of the deep contrastive learning model, providing new samples for subsequent model fine-tuning.

[0113] Finally, the anomaly review module provides real-time feedback to the reviewers on the driver's subsequent processing progress via WebSocket, avoiding multiple rounds of verification and improving the efficiency of human-machine collaboration.

[0114] Through the above embodiments, the system adds a refined manual review closed loop in addition to the intelligent review link, which can promptly intervene in manual judgment in scenarios with low confidence or field conflicts. This not only ensures the accuracy of the review, but also continuously injects new samples into the model, continuously improves the performance of automated review, and effectively reduces the false recognition rate and misplacement rate.

[0115] The above embodiments have described in detail the specific modules and functions of the dynamic verification system for ride-hailing driver qualifications based on multi-source information fusion of this application. The implementation process of the dynamic verification method for ride-hailing driver qualifications of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the dynamic verification method for ride-hailing driver qualifications provided in this application embodiment, as shown below. Figure 2 As shown, the method for dynamic verification of ride-hailing driver qualifications may specifically include the following steps:

[0116] S201: Receive the identity information, driver's license information, vehicle registration information and vehicle image data submitted by the driver, call the identity verification algorithm to perform liveness detection and facial fingerprint comparison, and generate the first verification result;

[0117] S202, based on the first verification result, perform cross-document comparison on the driver, driver's license, vehicle and validity period fields to obtain the second verification result;

[0118] S203: Utilizes a preset city review rule base and combines it with the second verification result to perform automated review, and outputs the driver qualification review conclusion and the corresponding conclusion identifier;

[0119] S204, when the driver qualification review result is passed, assign training course tasks to the target driver account according to the result identifier and obtain the training completion status;

[0120] S205, Write or maintain an order-accepting permission token for the target driver account based on the conclusion identifier and training completion status;

[0121] S206: Continuously obtain at least one of the vehicle annual inspection status, vehicle insurance status, or traffic violation status, generate a status event stream and determine whether the threshold is triggered. If triggered, update the order acceptance permission token and record the permission adjustment.

[0122] S207 adds type tags and timestamps to the first verification result, the second verification result, the driver qualification review conclusion, the training completion status and permission adjustment record, performs salted hash operation and inserts it into the Merkle tree, and writes the calculated root hash into the consortium blockchain ledger through a smart contract.

[0123] Specifically, in the embodiments of this application, the dynamic verification method for ride-hailing driver qualifications revolves around five major links: "multi-source information fusion - automated review - training closed loop - dynamic risk control - blockchain notarization". Each step is connected end-to-end under an event-driven architecture, and the specific implementation process is as follows:

[0124] In step S201, the system receives images of the driver's ID card, driver's license, vehicle registration certificate, and four views of the vehicle uploaded by the driver's terminal at once. The mobile multispectral camera simultaneously acquires RGB and near-infrared video streams, and the platform randomly issues action commands such as blinking and nodding to complete liveness detection. Keyframes that pass liveness detection are processed by a 3D temporal pose decoding network to extract depth features, which are then compared bidirectionally with the facial fingerprint generated from the ID card image using the same multimodal fusion network. If the similarity is higher than a threshold, it is written into the identity verification result as a "person-ID consistency" field.

[0125] In step S202, the data consistency comparison module writes the first verification result into the heterogeneous entity relationship graph of "driver-document-vehicle" based on the field mapping table, and then uses a dual-channel contrastive learning network to extract embedding vectors from nodes with the same name and calculate the confidence matrix. At the same time, an adaptive time decay model quantifies the risk of the remaining validity period of each document. The two results are fused according to weight to generate a comprehensive consistency score. If the score is higher than the threshold, it is recorded as consistent; otherwise, conflicting fields are recorded and the second verification result is output.

[0126] In step S203, the automated review and decision-making module first calls the feature vectorization engine to map the second verification result into a risk vector containing consistency score, document validity, traffic violation level, and annual inspection status. Then, it uses a compilable rule graph generator to compile the city's review rule base into a weighted directed graph in real time, and performs graph traversal reasoning on the risk vector to obtain the initial review and decision nodes. If the similarity between a node and a historically passed sample is lower than a set threshold, the incremental learning unit dynamically adjusts the rule graph and performs another reasoning, ultimately outputting a review conclusion of "pass," "fail," or "supplementary materials required," and generating a unique conclusion identifier.

[0127] In step S204, when the review conclusion is "passed," the training task management module parses the city code, vehicle type code, and risk level from the conclusion identifier, calls the course library submodule to generate a list of corresponding required and supplementary courses, and distributes them to the driver's end through the task scheduling submodule. The progress tracking submodule receives chapter completion and exam result events in real time, and generates a training completion status after all required courses are passed.

[0128] In step S205, after receiving the dual conditions of "approved review + qualified training", the vehicle access control module writes an order-accepting permission token to the target driver's account and sets the effective and expiration time. If the driver has not completed the training or the conclusion is marked as supplementary materials, the restriction status remains until the conditions are met.

[0129] In step S206, the vehicle status listener aggregates mileage and diagnostic data reported by OBD, annual inspection and insurance information pushed by the vehicle management office interface, and violation data from the traffic enforcement platform to form a status event stream. The complex event processing engine makes real-time judgments based on absolute and gradient thresholds. When any indicator triggers a threshold, a permission adjustment instruction is generated, and the permission scheduler atomically switches the token to a restricted or restored state, while simultaneously generating a permission adjustment record.

[0130] In step S207, the compliance data storage module adds type tags and timestamps to the first verification result, second verification result, audit conclusion, training completion status, and permission adjustment record, and then writes them to the buffer queue. When the batch processing conditions are met, the cryptographic hash generator adds a random salt value and a high-entropy counter to each data entry and calculates the SHA-3-512 hash, then constructs a Merkle tree in sequence to obtain the root hash. The on-chain submitter submits the root hash and index information to the consortium blockchain through a smart contract. After consensus is reached, the block height and transaction hash are returned and bound to the corresponding hash entry to form an immutable storage record.

[0131] Through the above series of steps, the platform enables drivers to complete authenticity verification, differentiated automatic review, precise training and dispatch, real-time vehicle compliance monitoring, and full-chain trusted evidence storage after submitting their information once, providing a high-efficiency, low-cost, and traceable dynamic qualification verification solution for ride-hailing businesses.

[0132] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0133] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A dynamic verification system for the qualification of a driver of a network car based on multi-source information fusion, characterized in that, The method comprises the following steps: A multi-source information collection module is used to receive identity information, driver's license information, vehicle registration information, and vehicle image data submitted by the driver side, and to perform consistency verification using a person-certificate consistency detection algorithm to generate a first verification result; A data consistency comparison module is used to compare the driver, driver's license, vehicle field, and validity period field based on the first verification result to generate a second verification result; An automated review decision module is used to output a driver qualification review conclusion and a corresponding conclusion identifier based on a pre-set city review rule library and the second verification result; A training task management module is used to match and assign a training course task to a target driver account based on the conclusion identifier when the driver qualification review conclusion is passed, and to receive a training completion status; A vehicle permission control module is used to open or restrict the order receiving permission of the target driver account based on the conclusion identifier and the training completion status, and to dynamically adjust the order receiving permission when a predetermined state related to the vehicle is detected to change; A compliance data storage module is used to hash the first verification result, the second verification result, the driver qualification review conclusion, the training completion status, and the permission adjustment record and write them into a blockchain ledger.

2. The system of claim 1, wherein, The multi-source information collection module further comprises: An OCR recognition sub-module is used to extract text and structured fields from the identity information, driver's license information, vehicle registration information, and vehicle image data; An external authority interface calling sub-module is used to synchronously call external authority data interfaces and insurance database interfaces based on the structured fields and return verification data.

3. The system of claim 1, wherein, The use of a person-certificate consistency detection algorithm for consistency verification to generate a first verification result comprises: A multi-spectral camera device is used to synchronously collect RGB images and near-infrared image sequences on the driver side and randomly issue action instructions to perform live detection; In the target frame where the live detection is passed, a three-dimensional time sequence posture decoding network is used to extract a face depth feature vector, and a multi-modal depth feature fusion network is used to generate a first face fingerprint; The same depth feature fusion network is used to generate a second face fingerprint from the certificate head portrait image in the identity information; The first face fingerprint and the second face fingerprint are input into a bidirectional hash quantization encoder to obtain a corresponding hash vector, and a face similarity score is calculated based on the hash vector; When the face similarity score is higher than a pre-set consistency threshold, a person-certificate consistency field containing a consistency flag is generated and written into the first verification result.

4. The system of claim 1, wherein, The comparison of the driver, driver's license, vehicle field, and validity period field based on the first verification result to generate a second verification result comprises: Based on a field mapping table, the identity card number, name, driver's license number, vehicle identification code, license plate number, and validity period field of each certificate in the first verification result are written into a heterogeneous entity relationship graph; A double-channel contrast learning network is used to extract a graph embedding vector for the same name node in the heterogeneous entity relationship graph, and a node pair similarity is calculated by cosine distance to obtain a field consistency confidence matrix; An adaptive time decay model is used on the validity period field to map the expiration time into a time risk score, and is fused with the field consistency confidence matrix according to a preset weight to generate a comprehensive consistency score; When the comprehensive consistency score is higher than a consistency threshold, a consistency flag bit is written into the second verification result; if it is lower than the consistency threshold, a conflict field and a conflict type are recorded and an inconsistency flag bit is generated to form the second verification result.

5. The system of claim 1, wherein, The driver qualification audit conclusion and the corresponding conclusion identifier are output according to the preset city audit rule library and the second verification result, including: The second verification result is mapped into a multi-dimensional risk vector containing field consistency score, validity period remaining time, traffic violation level and vehicle annual inspection state by using a feature vectorization engine; A city-oriented compilable rule graph generator is called to dynamically compile the city audit rule library into a weighted directed graph, and graph traversal reasoning is performed in the weighted directed graph according to the multi-dimensional risk vector to obtain an initial audit decision node; The initial audit decision node is matched with a historical passing sample embedding vector output by a deep contrast learning model in terms of cosine similarity, and if the similarity is lower than a preset threshold, a rule incremental learning unit is triggered to update the city audit rule library; When the initial audit decision node meets a graph traversal confidence threshold, a driver qualification audit conclusion of pass, fail or supplementary materials is generated according to the node type, and a unique conclusion identifier is generated according to the city code, vehicle model code and risk level combination.

6. The system of claim 1, wherein, The training task management module further includes: A course library sub-module for storing training course metadata associated with cities, vehicle models and driver types; A task scheduling sub-module for generating a training task by calling the course library sub-module according to the conclusion identifier; A progress tracking sub-module for receiving training progress and examination results returned by the driver end through an application programming interface and generating the training completion status.

7. The system of claim 1, wherein, The order receiving authority of a target driver account is opened or remains limited according to the conclusion identifier and the training completion status, and the order receiving authority is dynamically adjusted when a change in the scheduled state related to the vehicle is monitored, including: When the training completion status indicates that the target driver account corresponds to a qualified training course and the conclusion identifier indicates that the audit is passed, a token of order receiving authority is written for the target driver account; At least one of the vehicle annual inspection state, the vehicle insurance state or the traffic violation state is continuously acquired to generate a state event stream; The state event stream is determined in real time according to a preset threshold rule, and an authority adjustment instruction is output when any of the vehicle states triggers a threshold; According to the authority adjustment instruction, the order receiving authority token is updated to a limited order receiving authority token or restored to an order receiving authority token, and each time the authority adjustment record is encrypted and hashed and written into a blockchain ledger.

8. The system of claim 1, wherein, The first verification result, the second verification result, the driver qualification audit conclusion, the training completion status and the authority adjustment record are hashed and written into a blockchain ledger, including: The first verification result, the second verification result, the driver qualification review conclusion, the training completion state and the permission adjustment record are added with type tags and time stamps and written into a buffer queue; When a preset submission trigger condition is met, a random salt value is combined with a high-entropy counter to perform an encrypted hash operation on each piece of data in the buffer queue to generate a data hash entry; The data hash entry is inserted into a Merkle tree in order of the queue and a corresponding tree root hash is calculated; A smart contract deployed on a consortium blockchain is called to submit the tree root hash together with the time stamp and type tag index to a blockchain transaction pool; After the transaction is confirmed by a blockchain consensus mechanism, a confirmation identifier is returned and associated with the corresponding data hash entry to complete the evidence.

9. The system of claim 1, wherein, An abnormality review module is also included for generating a manual review work order and receiving a manual review result when the similarity output by the automated review decision module is below a preset threshold or the data consistency comparison module detects a field conflict, and the manual review result is used to overwrite the corresponding driver qualification review conclusion. 10.A method for dynamic verification of a driver qualification of a ride-hailing vehicle based on the system of any one of claims 1 to 9. The method comprises: Receiving identity information, driver's license information, vehicle license information and vehicle image data submitted by a driver, calling a person-certificate consistency detection algorithm to perform live body detection and face-fingerprint comparison, and generating a first verification result; According to the first verification result, cross-certificate comparison is performed on the driver, driver's license, vehicle field and validity period field to obtain a second verification result; Using a preset city review rule library and combining the second verification result, an automated review is performed to output a driver qualification review conclusion and a corresponding conclusion identifier; When the driver qualification review conclusion is passed, a training course task is assigned to a target driver account according to the conclusion identifier and a training completion state is obtained; According to the conclusion identifier and the training completion state, a token of permission to accept orders is written or kept for the target driver account; At least one of the vehicle annual inspection state, the vehicle insurance state or the traffic violation state is continuously obtained, a state event stream is generated and it is determined whether a threshold is triggered, and if so, the token of permission to accept orders is updated and a permission adjustment record is made; The first verification result, the second verification result, the driver qualification review conclusion, the training completion state and the permission adjustment record are added with type tags and time stamps, a salted hash operation is performed and a Merkle tree is inserted, and the calculated tree root hash is written into a consortium blockchain ledger through a smart contract.

Images