Automobile pledge supervision intelligent interaction system and method

Abstract

The application provides an automobile pledge supervision intelligent interaction system and method. It includes: obtaining supervision and constraint data, associating vehicles and supervision elements according to asset identification, and generating pledge asset supervision objects; correcting data time sequence and evaluating credibility, updating supervision state twin; converting constraint data into contract rule execution graph, determining risk state and uncertainty combined with state twin; when the supplement condition is met, determining the target action according to the expected information gain of the candidate supervision action and obtaining the supplementary data; updating the risk state according to the supplementary data, and constructing the time sequence supervision evidence graph; responding to the interaction request, extracting the associated information of the state twin, the contract rule execution graph and the time sequence supervision evidence graph, and generating the supervision interaction result; checking the operation authority, executing the operation that passes the check, and updating the state twin and the time sequence supervision evidence graph according to the feedback. The application can improve the accuracy of supervision data association, enhance the risk evidence identification ability, and improve the efficiency of supervision interaction disposal.

Description

Technical Field

[0001] This application relates to the fields of vehicle pledge supervision and intelligent interaction technology, and in particular to an intelligent interactive system and method for vehicle pledge supervision. Background Technology

[0002] With the development of inventory financing for auto dealerships, commercial banks, auto finance companies, and other financial institutions typically use dealership inventory vehicles as collateral. They mitigate the risk of unauthorized transfer, sale, or replacement of these vehicles through vehicle inventory checks, location monitoring, and certificate control. Current auto pledge supervision primarily employs two methods: periodic supervision and real-time supervision. Periodic supervision relies on RFID, handheld terminals, and on-site personnel to conduct periodic inventory checks of vehicles, certificates of conformity, and keys. Real-time supervision utilizes onboard monitoring devices to continuously collect vehicle location, operational status, and online equipment information, and uses a supervision platform to configure early warning rules, display supervision results, and assign verification tasks. Some supervision platforms also include mobile customer service or intelligent Q&A functions to provide vehicle inquiry, early warning inquiry, and business consultation services.

[0003] However, in existing technologies, different monitoring equipment, vehicle ownership certificates, keys, and on-site operation data are typically managed in a decentralized manner, lacking a dynamic correlation mechanism centered on the pledged vehicle. This makes them susceptible to distortions in monitoring status due to equipment replacement, mis-attached tags, or inconsistent data timing. Periodic and real-time monitoring are independent of each other, making it difficult to dynamically adjust the intensity of monitoring based on changes in risk. Many regulatory rules rely on manual configuration, and contractual constraints are difficult to directly translate into executable regulatory logic. Furthermore, existing systems typically trigger warnings based on single anomalies, making it difficult to distinguish between genuine risks and equipment malfunctions or data gaps, and failing to form a traceable multi-source evidence chain. Existing intelligent customer service primarily generates answers based on static knowledge bases, failing to combine real-time vehicle status, regulatory rules, and operational permissions to complete risk explanation, evidence collection, and a closed loop of regulatory tasks. Consequently, the accuracy of regulatory interaction and the efficiency of risk handling still need improvement. Summary of the Invention

[0004] In view of this, embodiments of this application provide an intelligent interactive system and method for supervising vehicle pledges, in order to solve the problems of inaccurate correlation of regulatory data, insufficient identification of risk evidence, and disconnect between regulatory interaction and disposal in the prior art.

[0005] The first aspect of this application provides an intelligent interactive system for vehicle pledge supervision, comprising: a supervision object construction module, used to acquire multi-source supervision data and supervision constraint data, establish the association between vehicle entities and supervision elements based on asset identifiers, and generate pledged asset supervision objects; a state twin module, used to perform time-series correction and credibility assessment on multi-source supervision data, and update the supervision state twin of the pledged asset supervision objects according to the association relationships; a rule analysis module, used to convert supervision constraint data into contract rule execution diagrams, and determine the vehicle risk status and status uncertainty based on the contract rule execution diagrams and the supervision state twin; and an active supplementation module. The data acquisition module is used to determine the target regulatory action based on the expected information gain of the candidate regulatory actions and acquire supplementary regulatory data when the uncertainty of the state meets the supplementary acquisition conditions. The evidence interaction module is used to update the vehicle risk status based on the supplementary regulatory data, construct a time-series regulatory evidence graph, and respond to regulatory interaction requests. It extracts related information from the regulatory state twin, contract rule execution graph, and time-series regulatory evidence graph to generate regulatory interaction results. The controlled execution module is used to verify the permissions of the regulatory operations in the regulatory interaction request, execute the regulatory operations that pass the permission verification, and update the regulatory state twin and time-series regulatory evidence graph based on the operation feedback.

[0006] The second aspect of this application provides an intelligent interactive method for vehicle pledge supervision based on the system of the first aspect, comprising: acquiring multi-source supervision data and supervision constraint data; establishing a relationship between vehicle entities and supervision elements based on asset identifiers to generate pledged asset supervision objects; performing time-series correction and credibility assessment on the multi-source supervision data; updating the supervision status twin of the pledged asset supervision objects according to the relationship; converting supervision constraint data into a contract rule execution graph; determining the vehicle risk status and status uncertainty based on the contract rule execution graph and the supervision status twin; when the status uncertainty meets the supplementary collection conditions, determining the target supervision action based on the expected information gain of the candidate supervision action, and acquiring supplementary supervision data; updating the vehicle risk status based on the supplementary supervision data and constructing a time-series supervision evidence graph; responding to supervision interaction requests; extracting related information from the supervision status twin, contract rule execution graph, and time-series supervision evidence graph to generate supervision interaction results; performing permission verification on the supervision operations in the supervision interaction request; executing the supervision operations that pass the permission verification; and updating the supervision status twin and time-series supervision evidence graph based on the operation feedback.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The system comprises several modules: a regulatory object construction module for acquiring multi-source regulatory data and regulatory constraint data, establishing relationships between vehicle entities and regulatory elements based on asset identifiers, and generating regulatory objects for pledged assets; a state twin module for performing time-series correction and credibility assessment on multi-source regulatory data, and updating the regulatory state twin of the pledged asset regulatory objects according to the relationships; a rule analysis module for converting regulatory constraint data into contract rule execution diagrams, determining vehicle risk status and status uncertainty based on the contract rule execution diagrams and regulatory state twins; an active supplementary data collection module for determining target regulatory actions based on the expected information gain of candidate regulatory actions and acquiring supplementary regulatory data when the status uncertainty meets the supplementary data collection conditions; an evidence interaction module for updating vehicle risk status based on supplementary regulatory data, constructing a time-series regulatory evidence diagram, responding to regulatory interaction requests, extracting related information from the regulatory state twin, contract rule execution diagram, and time-series regulatory evidence diagram, and generating regulatory interaction results; and a controlled execution module for verifying the permissions of regulatory operations in regulatory interaction requests, executing regulatory operations that pass the permission verification, and updating the regulatory state twin and time-series regulatory evidence diagram based on the operation feedback. This application can improve the accuracy of regulatory data correlation, enhance the ability to identify risk evidence, and improve the efficiency of regulatory interaction and processing. Attached Figure Description

[0008] 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.

[0009] Figure 1 This is a schematic diagram of the structural composition of the intelligent interactive system for supervising vehicle pledge provided in this application embodiment; Figure 2 This is a flowchart illustrating the intelligent interactive method for supervising vehicle pledges provided in this application embodiment. Detailed Implementation

[0010] 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.

[0011] Current vehicle pledge supervision typically employs a combination of periodic and real-time monitoring. Periodic monitoring primarily involves using RFID devices, handheld terminals, and on-site supervisors to conduct inventory checks of pledged vehicles, their documentation, and keys at agreed-upon intervals. Real-time monitoring mainly utilizes onboard monitoring devices to collect vehicle location, operational activity, and device online status, with the monitoring platform generating anomaly alerts based on preset rules. Some monitoring platforms also offer mobile query or intelligent customer service functions for handling vehicle status inquiries, alert queries, and regulatory business consultations.

[0012] However, in existing technologies, vehicle data, sensing device data, vehicle certificate data, and on-site operation data are typically managed in a fragmented manner. There is a lack of stable and verifiable dynamic correlation between vehicle entities and different regulatory elements, making it susceptible to distortions in regulatory status due to equipment replacement, mis-attached tags, data delays, or information inconsistencies. Existing regulatory rules largely rely on manual selection and configuration, making it difficult to directly translate the constraints in financing contracts and regulatory agreements into executable regulatory logic. Furthermore, existing systems often trigger alerts based on single data anomalies, making it difficult to distinguish between genuine pledge risks and equipment malfunctions, data gaps, or status conflicts, and also making it difficult to form a complete chain of evidence supporting risk conclusions. Existing intelligent customer service is disconnected from actual regulatory status and operations, failing to achieve a closed-loop linkage between risk interpretation, evidence collection, authorization verification, and regulatory action.

[0013] To address the aforementioned issues, this application acquires multi-source regulatory data and regulatory constraint data, establishes the correlation between vehicle entities and regulatory elements based on asset identifiers, and generates pledged asset regulatory objects. It performs time-series correction and credibility assessment on the multi-source regulatory data, and updates the regulatory status twin of the pledged asset regulatory objects accordingly. Furthermore, it converts the regulatory constraint data into a contract rule execution diagram, and combines the contract rule execution diagram and the regulatory status twin to determine the vehicle risk status and status uncertainty. When the status uncertainty meets the supplementary data collection conditions, it selects the target regulatory action based on the expected information gain of the candidate regulatory actions, and acquires supplementary regulatory data to update the vehicle risk status and construct a time-series regulatory evidence diagram.

[0014] During the regulatory interaction process, this application responds to regulatory interaction requests by extracting relevant information from the regulatory status twin, contract rule execution graph, and time-series regulatory evidence graph to generate a regulatory interaction result supported by evidence. When the regulatory interaction request includes a regulatory operation, the application verifies the permissions of the regulatory operation, executes the regulatory operation that has passed the permission verification, and updates the regulatory status twin and time-series regulatory evidence graph based on the operation feedback, thereby forming a closed-loop processing flow from data perception, risk identification, evidence supplementation, intelligent interaction to regulatory execution.

[0015] Through the above technical solutions, this application can improve the accuracy of data association between vehicle entities and regulatory elements, reduce risk misjudgment caused by data mismatch, state conflict and equipment abnormality; enhance the ability to identify risk status and trace evidence, and improve the credibility of regulatory conclusions; and connect regulatory interaction with actual regulatory operations to improve the efficiency of regulatory task execution and abnormal handling.

[0016] The specific components and functions of the intelligent interactive system for supervising vehicle pledge provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 This is a schematic diagram of the structural composition of the intelligent interactive system for vehicle pledge supervision provided in the embodiments of this application, as shown below. Figure 1 As shown, the system may specifically include the following components: The regulatory object construction module 101 is used to acquire multi-source regulatory data and regulatory constraint data, establish the association between vehicle entities and regulatory elements based on asset identification, and generate pledged asset regulatory objects. The state twin module 102 is used to perform time-series correction and credibility assessment on multi-source regulatory data and update the regulatory state twin of the pledged asset regulatory object according to the correlation relationship. The rule analysis module 103 is used to convert regulatory constraint data into a contract rule execution diagram, and determine the vehicle risk status and status uncertainty based on the contract rule execution diagram and the regulatory status twin. The active supplementary data acquisition module 104 is used to determine the target regulatory action based on the expected information gain of the candidate regulatory action and acquire supplementary regulatory data when the state uncertainty meets the supplementary data acquisition conditions. The evidence interaction module 105 is used to update the vehicle risk status based on supplementary regulatory data, construct a time-series regulatory evidence graph, and respond to regulatory interaction requests. It extracts related information from the regulatory status twin, the contract rule execution graph, and the time-series regulatory evidence graph to generate regulatory interaction results. The controlled execution module 106 is used to verify the permissions of the regulatory operations in the regulatory interaction request, execute the regulatory operations that have passed the permission verification, and update the regulatory status twin and the time-series regulatory evidence graph based on the operation feedback.

[0017] In some embodiments, multi-source regulatory data and regulatory constraint data are acquired, and the association between vehicle entities and regulatory elements is established based on asset identifiers to generate pledged asset regulatory objects, including: The raw data from the regulatory platform, sensing devices and field operation terminals are formatted and time-series aligned to generate regulatory events carrying source and time identifiers; Extract the scope and relationship constraints of asset supervision from regulatory constraint data; Based on vehicle identity information, an asset identifier is generated, and a dynamic association with a valid time period is established with regulatory events and regulatory elements corresponding to the same vehicle according to relational constraints. Conflicting relationships are identified based on consistency and data credibility, and dynamic relationships that pass consistency verification and corresponding regulatory events are encapsulated as pledged asset regulatory objects.

[0018] Specifically, a unified event model can be configured first for data accessed from the regulatory platform, sensing devices, and on-site operations. Regulatory platform data can include vehicle entry, financing disbursement, vehicle redemption, exit authorization, and regulatory task records. Sensing device data can include RFID tag reading results, location and operating status transmitted by onboard monitoring devices, and on-site operation data can include inventory time, operator location, vehicle identification number (VIN) scanning results, vehicle images, and document verification results. After receiving the raw data, the system maps different field names to asset identification fields, event type fields, event occurrence time, event reception time, data source, and event payload. It also converts coordinates, equipment status codes, and operation results into a unified code to form standard regulatory events.

[0019] For example, a dealer's inventory vehicle has the vehicle identification number (VIN) LVA12345678900001. The monitoring platform records that this vehicle entered a pledged state at 10:00 AM on July 1, 2026. The RFID reader collected the corresponding tag at 10:05 AM, the on-board monitoring device transmitted the warehouse coordinates at 10:04 AM, and the on-site operation terminal uploaded the VIN scanning result at 10:08 AM. The system uses the platform clock as a reference, corrects the event occurrence time based on the historical clock offset of each data source, and retains the original time, the corrected time, and the receiving time.

[0020] When the vehicle-mounted monitoring device exhibits a consistent 12-second deviation, the transmission time is uniformly shifted forward by 12 seconds. When the deviation fluctuates randomly beyond the allowable range, only the time reliability is reduced, without directly rewriting the original time. After processing, each regulatory event enters the same event sequence according to the correction time. To avoid duplicate uploads causing status overlap, event fingerprints can be generated based on source identifier, device identifier, event type, correction time, and event payload summary. Events with identical fingerprints only retain the version with higher reliability; events with missing key fields or inconsistent checksums are placed in an isolation queue and associated with the original data address for verification.

[0021] Regulatory constraint data can be derived from financing contracts, regulatory agreements, and financial institution configuration rules. The system segments the constraint content into clauses, extracting applicable dealers, vehicle scope, regulatory period, permitted bound device types, certificate custody relationships, key custody relationships, and device replacement conditions to generate asset regulatory scope and relationship constraints. For example, if the contract stipulates that during the pledge period, the vehicle, on-board monitoring device, RFID tag, certificate of conformity, and key must maintain a one-to-one correspondence, and device replacement must be authorized with no overlap between old and new binding relationships exceeding 30 minutes, the system will then generate binding base constraints, validity period constraints, and replacement transition constraints accordingly.

[0022] The system uses the vehicle identification number (VIN) as the primary identity information, combined with the dealer number and financing contract number to generate an asset identifier, such as A01-D003-LVA12345678900001. For each regulatory element, a dynamic association edge with start and end times is established. This association edge records the element identifier, relationship type, establishment basis, creation time, expiration time, and association reliability. Upon initial warehousing, the RFID tag R1008, on-board monitoring device O3021, certificate of conformity C7786, and key K5562 are associated with this asset identifier. When the on-board monitoring device is subsequently replaced, the old association edge expires at the authorized time, and the new association edge becomes effective upon successful installation and verification, thus avoiding the use of permanent static binding.

[0023] Consistency verification can be performed from four dimensions: identity consistency, time validity, spatial consistency, and attribute consistency. If the vehicle monitoring device O3021 continues to transmit data after failure, or if the same RFID tag is simultaneously associated with two valid pledged vehicles, a conflict association is generated. The system further calculates the association credibility by combining the reliability of the data source, the validity period of the device binding, the continuity of the vehicle location, the on-site scanning results, and the operator's permissions. When the location transmitted by the new device is consistent with the on-site installation location, and the on-site scanning record, authorization record, and vehicle identification code match, the new association is confirmed to be valid; if there is only a single device transmission without authorization and on-site credentials, the association is marked as pending verification and is not written into the formal state chain.

[0024] Furthermore, after verification, the system encapsulates effective dynamic relationships, related elements, regulatory events, regulatory scope, relationship constraints, and their respective credibility into a unified pledged asset regulatory object, and establishes a current status index and a historical relationship index for the object. The current status index is used to quickly query the vehicle's currently active equipment, vouchers, and regulatory tasks, while the historical relationship index is used to trace equipment replacement, voucher handover, and abnormal events. This ensures the temporal consistency of the relationship between the vehicle entity and regulatory elements even when there are delays, misbindings, or replacements in multi-source data, providing a reliable data foundation for subsequent regulatory status twin updates, risk identification, and regulatory interaction.

[0025] In some embodiments, time-series correction and credibility assessment are performed on multi-source regulatory data, and the regulatory status twin of the pledged asset regulatory object is updated according to the correlation, including: A unified regulatory timeline is established based on the occurrence and reception times of each regulatory event, and time corrections are performed for regulatory events with clock deviations. Event credibility is generated based on data source reliability, data completeness, correlation matching degree, and timeliness; Based on the correlation, regulatory events are mapped to the corresponding pledged asset regulatory objects, and the status changes reflected by each regulatory event are extracted; Update the regulatory status twin based on changes in the fusion status of event credibility and regulatory timeline. When there are conflicts in the state changes corresponding to different regulatory events, candidate states are retained and state conflict identifiers and corresponding state uncertainties are generated.

[0026] Specifically, an independent event timeline and status slot can be established for each pledged asset under supervision. The event timeline uses the time synchronization of the supervision platform as a benchmark, and converts the data uploaded by sensing devices, on-site operation terminals, and business systems into three types of time stamps: occurrence time, reception time, and processing time. The system first calculates the clock offset based on the device's most recent heartbeat records, and then corrects the occurrence time by combining it with the estimated network transmission delay.

[0027] For example, if the on-board monitoring device for a vehicle lags behind the platform time by 18 to 22 seconds for five consecutive heartbeats, the occurrence time of the current event can be shifted forward by 20 seconds. If the delay fluctuation exceeds the allowable threshold, the original time is retained, and the time correction confidence level is reduced. For on-site inventory data, the validity of the time can be verified based on the chronological relationship between the terminal positioning time, image generation time, and upload time, thereby forming a unified regulatory time sequence arranged according to the correction occurrence time.

[0028] Event credibility can be determined by a combination of data source reliability, data completeness, correlation matching degree, and timeliness. Data source reliability is generated based on device authentication status, historical failure rate, and valid operator permissions; data completeness is determined by whether required fields, verification codes, attachments, and continuous sampling segments are complete; correlation matching degree is calculated based on the consistency between the vehicle identification code, device identifier, and dynamic correlation relationship carried by the event; and timeliness is attenuated based on the interval between the event occurrence time and the current time. Each indicator can be normalized to 0 to 1 and weighted and aggregated according to the regulatory scenario. For example, if the source reliability of a vehicle monitoring device location event is 0.92, completeness is 0.95, correlation matching degree is 0.98, and timeliness is 0.90, the calculated event credibility is 0.94; if the same event lacks device power status and the upload delay exceeds 10 minutes, the completeness and timeliness are reduced accordingly.

[0029] The system maps regulatory events to corresponding pledged asset regulatory objects according to effective correlations and extracts status changes from the event payload. Status slots can include in-warehouse status, location status, operational status, document status, key status, and regulatory task status. For example, if an RFID tag is read at the warehouse entrance, the system can extract the physical status change of a vehicle entering the warehouse; if the vehicle-mounted monitoring device continuously transmits coordinates outside the warehouse and the ignition is on, the system can extract the vehicle leaving and operational status changes; if the on-site operation terminal uploads the certificate verification result, the system can extract the document's controlled status change. Each status change is associated with the event source, occurrence time, event credibility, and original data anchor point.

[0030] During state fusion, the system processes state changes item by item according to a unified regulatory time sequence. For late events, the system inserts them into historical positions based on the corrected occurrence time and recalculates the state trajectory within the affected time window to avoid state reversal caused by simply following the receiving order. For the same state slot, the system prioritizes states with more recent occurrence times and higher event confidence; when consecutive events can form consistent state trajectories, the confidence of the corresponding state is increased. For example, if the vehicle monitoring device transmits three consecutive data points indicating that the vehicle is in the storage area, and the RF inventory results are consistent, the location status is updated to "in the storage area," and the state confidence is increased. For low-confidence events, the current state is not directly overwritten but is temporarily stored as candidate evidence; a decision on whether to update is made after subsequent high-confidence events arrive.

[0031] When different regulatory events yield contradictory results for the same state slot, the system retains multiple candidate states and generates a state conflict flag. For example, an RFID device reads a vehicle tag at 14:02, an on-board monitoring device reports the vehicle is located on a road outside the warehouse at 14:03, and an on-site inventory records the vehicle is in the warehouse at 14:05. The system calculates the support strength for each candidate state and determines the degree of conflict by considering temporal proximity, source independence, spatial continuity, and correlation effectiveness. If the on-board trajectory is continuous, the device binding is effective, and the on-site inventory image was generated before the task time, the "outside warehouse" state receives high support, and the "in-warehouse" state is marked as suspicious. State uncertainty can be generated based on the number of candidate states, differences in support strength, degree of missing evidence, and duration of conflict; the closer the candidate states are and the more missing evidence, the higher the uncertainty.

[0032] Ultimately, the regulatory status twin simultaneously stores the current preferred status, candidate statuses, status confidence levels, status conflict identifiers, and status uncertainties, while also preserving the event chain corresponding to each status. When subsequent supplementary inventory checks, equipment reconnection, or on-site verification results arrive, the candidate statuses and conflict results are then corrected along the event timeline. Through this process, we can avoid single late or low-reliability data directly overwriting the true vehicle status, improving the continuity and traceability of multi-source regulatory status fusion.

[0033] In some embodiments, regulatory constraint data is converted into a contract rule execution graph, and the vehicle risk status and status uncertainty are determined based on the contract rule execution graph and regulatory status twin, including: Extract applicable conditions, status constraints, evidence requirements, and disposal rules from regulatory constraint data to generate executable rule units; The executable rule units are connected according to the rule triggering relationship and the handling dependency relationship to construct the contract rule execution graph, and the rule conflict and execution integrity are verified. The current state in the regulatory state twin is matched with the contract rule execution graph to identify abnormal states that violate state constraints and corresponding evidence. The vehicle risk status is generated based on the degree of rule violation and the credibility of evidence in the abnormal state, and the state uncertainty is generated based on the degree of evidence missing, the degree of state conflict and the timeliness of data.

[0034] Specifically, the system can first perform structured parsing of financing contracts, regulatory agreements, and financial institution allocation instructions. The system segments regulatory constraint data according to clause number, applicable object, and effective period, and uses clause semantic templates to identify the subject of the condition, triggering conditions, constraint status, evidentiary threshold, and disposal result. For example, a contract might stipulate that during the period of outstanding financing balance, vehicles should be parked in designated areas and may not leave without authorization; if a vehicle leaves the area for more than 15 minutes and there is no valid exit approval, a high-risk warning should be generated and on-site verification should be initiated. Based on this, the system generates an executable rule unit with the applicable conditions being valid financing status, the status constraint being the vehicle being located in the designated area, the evidentiary requirement being continuous location trajectory and authorization record verification, and the disposal rule being warning escalation and verification task assignment.

[0035] Each executable rule unit can include a rule identifier, input status, judgment conditions, evidence threshold, output status, action, and priority. For clauses with ambiguous time or range in natural language, they can be completed into a calculable interval by combining contract appendices and institutional parameter tables; clauses that cannot be determined enter the manual confirmation queue and do not directly participate in automatic execution. The system can also include vehicle type, dealer risk level, and regulatory stage in the applicable conditions, allowing different vehicles under the same contract to be matched with different rules. For example, exhibition vehicles are allowed to move short distances within the authorized period, while ordinary inventory vehicles are not allowed to leave the storage area, thus forming differentiated rule units.

[0036] After a rule unit is generated, the system establishes trigger edges based on the relationship that the next judgment is triggered when a condition is met, and establishes dependency edges based on the relationship that the result of the previous action serves as a prerequisite for the next action. For example, an abnormal location rule triggers an authorization verification rule; if the authorization verification fails, a risk escalation rule is triggered; and only after the risk escalation is completed can an on-site verification task be generated. Each rule node, trigger edge, and dependency edge together constitutes the contract rule execution graph. The system performs closed-loop detection, priority detection, and precondition detection on the execution graph to avoid situations with no terminating nodes, mutually looping triggers, or missing preconditions for action. If the same vehicle simultaneously triggers both the "allow authorized movement" and "prohibit any movement" rules, the applicable scope, authorization period, and rule priority are compared; if the conflict cannot be resolved, a rule conflict flag is generated and automatic action is suspended.

[0037] During operation, the system reads the current financing status, location status, operational status, authorization status, and corresponding time information from the regulatory status twin. It then maps each status to the input nodes of the execution graph and matches them layer by layer. For example, if a vehicle leaves the electronic fence at 2:10 PM and is still outside the warehouse at 2:28 PM, and no exit authorization effective around 2:00 PM is found, the location anomaly lasts for more than 15 minutes, and the location constraint node and authorization verification node are hit sequentially. The system associates continuous positioning trajectories, fence crossing events, ignition status, and authorization query results as evidence of anomalies and records the corresponding event credibility and original data anchor points. If the positioning trajectory contains only a single drift point, or the device is in a weak signal state, it is not directly considered a violation of constraints, but rather an anomaly awaiting verification is retained.

[0038] Vehicle risk status is generated jointly based on the degree of rule violation, duration of the anomaly, handling level, and credibility of evidence. The degree of rule violation is determined by the deviation of the anomaly status from the constraint boundary; for example, the longer the departure time and the farther the distance from the storage area, the higher the degree of violation. The credibility of evidence is obtained by aggregating the regulatory events supporting the anomaly after deduplication and source independence correction. The system maps these two to risk statuses such as normal, attention, warning, and high risk, and associates them with the hit rule paths. If the same anomaly is hit by multiple rules, the system merges them according to the degree of overlap of evidence paths, retaining the highest handling level and recording the contributions of the other rules.

[0039] State uncertainty is calculated independently of risk state. The system generates the degree of evidence missing based on whether the necessary evidence is complete, the degree of state conflict based on the difference in the support strength of candidate states, and the data timeliness decay value based on the interval between the key event and the current time. For example, if a vehicle is suspected of leaving the site but lacks radio frequency inventory results, and the on-board monitoring device and the on-site records contradict each other, then even if the risk value is high, the state uncertainty will still remain at a high level.

[0040] To ensure the reproducibility of the judgment results, the system can also permanently save the execution graph version, status snapshot, and matching path for each risk calculation. When contract terms or institutional parameters are adjusted, the updated rule version is only used for the newly effective period, while historical events are still replayed using the original version, preventing existing risk conclusions from being rewritten without basis due to rule changes. The system can thus distinguish between high-risk situations with sufficient evidence, high-risk situations requiring verification, and low-risk situations with outdated data, providing clear evidence for subsequent proactive data collection and regulatory interaction.

[0041] In some embodiments, when the state uncertainty meets the supplementary data acquisition condition, the target regulatory action is determined based on the expected information gain of the candidate regulatory action, and supplementary regulatory data is acquired, including: Based on the missing evidence items and conflicting state items corresponding to the state uncertainty, the regulatory state to be verified is determined, and candidate regulatory actions matching the regulatory state to be verified are extracted from the contract rule execution diagram. Based on the expected reduction of missing evidence and conflicting states by each candidate regulatory action, the corresponding expected information gain is determined. Based on the expected information gain, action execution constraints and regulatory timeliness requirements, the utility of each candidate regulatory action is evaluated, and the candidate regulatory action that meets the selection criteria is determined as the target regulatory action. Send the target regulatory action to the corresponding regulatory authority, receive the action execution results, and generate supplementary regulatory data according to asset identification and execution sequence.

[0042] Specifically, a supplementary data collection decision instance can be established for each vehicle with high uncertainty. This instance records the asset identifier, pending regulatory status, missing evidence, conflicting statuses, candidate regulatory actions, and the validity period of those actions. When the uncertainty of the status reaches a preset supplementary data collection threshold, the system reads the corresponding risk assessment process, distinguishing between uncertainty caused by a lack of key evidence and uncertainty caused by contradictory results from multiple sources. For example, if a vehicle's location track appears outside the warehouse at 14:10, but the radio frequency device still reads its in-warehouse tag at 14:12, and the on-site inventory record stops at 13:50, the system determines the vehicle's actual location as pending regulatory verification, identifies the lack of real-time on-site images and the lack of the latest vehicle identification number scan results as missing evidence, and identifies the inconsistency between the vehicle positioning result and the radio frequency in-warehouse result as a conflicting status.

[0043] The system executes action nodes associated with vehicle departure, equipment malfunction, and on-site verification according to contract rules, generating candidate regulatory actions. These actions may include increasing the sampling frequency of the on-board monitoring device, rereading RFID tags, calling the on-site work terminal to perform targeted inventory checks, collecting vehicle identification numbers and environmental images, and verifying outbound authorization records. Candidate actions are not a fixed list but are dynamically generated based on the regulatory status to be verified, the currently available regulatory terminals, and the permitted range of the rules. If the on-board monitoring device is offline, continuous positioning actions are not generated; if on-site personnel are far from the target warehouse area and the contract requires confirmation within 10 minutes, the immediate availability of on-site verification actions is reduced.

[0044] The expected information gain can be determined based on the expected change in the candidate state distribution after the action is executed. The system reads the success rate of various actions in evidence completion and conflict resolution from similar historical events, and combines this with the current online status of equipment, personnel location, and network quality to predict the set of possible results obtained by the action. For example, rereading the RFID tag can confirm whether the tag is still in the storage area, but cannot rule out the possibility of the tag separating from the vehicle; its expected reduction in location conflict is 0.35. High-frequency sampling by the vehicle monitoring device can verify the continuity of the trajectory; its expected reduction is 0.58. Scanning the vehicle identification code on-site and uploading a real-time image with positioning information can simultaneously confirm the vehicle entity, location, and tag binding relationship; its expected reduction is 0.86. The system further normalizes the decrease in state entropy that the action result may cause, forming the corresponding expected information gain.

[0045] During the utility assessment phase, the system jointly calculates the expected information gain with action execution constraints, response time limits, and resource consumption. Action execution constraints may include the online status of the regulatory end, operating permissions, contractually allowed frequency, personnel accessibility, and vehicle safety boundaries; regulatory timeliness requirements are determined by risk level and rule processing time limits. For example, for high-risk departure events requiring supplementary evidence within 5 minutes, even if on-site verification has the highest information gain, it may not be the first choice due to an expected arrival time of 20 minutes. The system can use information gain as a positive indicator and expected latency, execution cost, and failure probability as negative indicators to generate action utility values ​​and verify whether there are sequential dependencies between actions. If a single action is insufficient to eliminate conflict, complementary action combinations can be selected, such as first increasing the location sampling frequency and then triggering the nearest radio frequency repeater; when the combined utility is higher than that of a single action and meets resource constraints, the action combination is determined as the target regulatory action.

[0046] Furthermore, once the target regulatory action is determined, the system generates a structured instruction containing a task identifier, asset identifier, action type, execution parameters, effective time period, target evidence items, and feedback format, and sends it to the corresponding regulatory end. For example, a location acquisition instruction is sent to the vehicle-mounted monitoring device for 3 minutes, sampling once every 10 seconds, while a targeted repeat instruction for the target tag is sent to the RFID reader in the warehouse area. After execution, the regulatory end returns the sampling trajectory, reading results, execution time, equipment status, and integrity verification information. The system verifies the task identifier and feedback signature, discards results that exceed the effective time period or do not match the target asset, and aligns the results returned from multiple ends according to the execution sequence.

[0047] When high-frequency positioning shows that a vehicle remains outside the warehouse, and radio frequency repeating only detects the tag without detecting any evidence of the vehicle's physical association, the system treats the potential separation of the tag and the vehicle as a new fact. If the on-site operator subsequently uploads the vehicle identification code scan result and confirms that the vehicle is outside the warehouse, the conflict is resolved. The system encapsulates the verified action execution result into a supplementary regulatory event, linking it to the asset identifier, the original pending verification status, the target regulatory action, and the original risk assessment path, generating supplementary regulatory data. The supplementary regulatory data is written into the regulatory status twin and the time-series regulatory evidence graph for recalculating the status uncertainty and vehicle risk status. If supplementary data collection fails or is still insufficient to distinguish candidate statuses, unresolved evidence items are retained, and supplementary data collection continues according to the next priority action, thus forming a regulatory closed loop that gradually reduces uncertainty.

[0048] In some embodiments, the vehicle risk status is updated based on supplementary regulatory data, a time-series regulatory evidence graph is constructed, and in response to regulatory interaction requests, relevant information is extracted from the regulatory status twin, the contract rule execution graph, and the time-series regulatory evidence graph to generate regulatory interaction results, including: The supplementary regulatory data will be matched with the regulatory status to be verified, the status uncertainty will be corrected, and the regulatory status twin and vehicle risk status will be updated. Using regulatory objects, regulatory status, rule units, and regulatory events as evidence nodes, evidence association edges are established according to asset association, event sequence, and rule triggering relationships to generate a time-series regulatory evidence graph. Analyze regulatory interaction requests, identify the target regulatory object and interaction intent, extract the current state from the regulatory state twin, and retrieve the corresponding rules and evidence paths along the contract rule execution graph and the time-series regulatory evidence graph; Based on the current status, corresponding rules, and evidence paths, regulatory conclusions are generated, and the reference relationship between regulatory conclusions and evidence nodes is established to form regulatory interaction results.

[0049] Specifically, upon receiving supplementary regulatory data, the system first matches the supplementary regulatory data with the corresponding regulatory status to be verified, based on asset identification, target regulatory action, and supplementary data collection task identification. During matching, it verifies whether the generation time of the supplementary data falls within the valid task period, whether the transmitting entity has the corresponding collection authority, and whether the data content covers missing or conflicting items in the original evidence. For example, if a vehicle is suspected of abnormally leaving the depot, in the original state, the onboard monitoring device continuously transmits the trajectory outside the depot, while the RFID tag is still being read within the depot area. Based on this, the system retains two candidate states: vehicle in the depot and vehicle out of the depot. Subsequently, the on-site operation terminal uploads the vehicle identification code scan results with location information, real-time images, and inventory results. Since the collection location is on a road outside the depot, the system maps the supplementary data to the vehicle out of the depot candidate state, increasing the support strength of this candidate state while reducing the proving ability of the RFID in-depot event for the vehicle's physical location.

[0050] The uncertainty of the vehicle's status can be recalculated based on the completeness of evidence before and after supplementary data collection, the number of candidate statuses, the differences in support between candidate statuses, and the timeliness of the data. If the supplementary data completes the vehicle's physical location, the identity of the operator, and the collection time, and corroborates the vehicle's trajectory, the candidate status of the vehicle being in the warehouse is deleted, the location status is updated to "outside the warehouse," and the uncertainty of the status is reduced from 0.76 to 0.18. The system then inputs the updated current status into the contract rule execution graph to rematch the departure duration, authorization status, and disposal conditions. When the vehicle's departure exceeds the contractually allowed duration and there is no valid authorization, the vehicle's risk status is updated from pending verification warning to high risk; if the supplementary data proves that the vehicle is in the warehouse but the on-board device has been removed, the vehicle's location risk is eliminated, and an equipment anomaly risk is generated.

[0051] When constructing a time-series regulatory evidence graph, pledged vehicles, monitoring equipment, vehicle certificates, and monitoring tasks can be used as regulatory object nodes; in-warehouse / out-of-warehouse, equipment offline, and authorization valid can be used as regulatory status nodes; contract conditions, evidence thresholds, and disposal rules can be used as rule unit nodes; and location feedback, RFID reading, on-site inventory, and supplementary data collection results can be used as regulatory event nodes. The system establishes asset association edges based on the ownership of the same asset, event time-series edges based on the order of events, and rule triggering edges based on the fulfillment of rule conditions in the status. Each edge records the valid time period, source credibility, and original data anchor point. For example, the vehicle node sequentially connects to the fence crossing event at 14:10, the RFID reading event at 14:12, and the on-site verification event at 14:18. The fence crossing event and the on-site verification event then jointly point to the out-of-warehouse status node, which further triggers the unauthorized departure rule node, forming a complete evidence path.

[0052] When a financial institution user submits a regulatory interaction request via mobile device to explain why a target vehicle has been deemed high-risk, the system first analyzes the user's identity, vehicle identification information, query time range, and risk interpretation intent to determine the target regulatory object. Then, it retrieves the current location, operational status, authorization status, risk status, and status uncertainty from the regulatory status twin. Starting from the current risk status, it searches backward in the contract rule execution graph for matching status constraints and evidence requirements, and then retrieves regulatory events supporting the corresponding rules along the time-series regulatory evidence graph. The search process can limit the search scope based on asset identifiers, filter irrelevant historical nodes based on event time, and sort candidate evidence paths according to evidence credibility and path completeness.

[0053] When generating regulatory conclusions, the system combines the current status, rule matching results, and evidence paths into a structured result. For example, a regulatory conclusion might indicate that the target vehicle left the designated storage area at 2:10 PM, the departure time exceeded the allowable threshold, no valid exit authorization was found, and the on-site verification results were consistent with the continuous positioning trajectory; therefore, it is currently classified as high-risk. For reverse evidence where the RFID tag is still in the storage area, the system simultaneously marks it as potentially separated from the vehicle and does not use it as a basis for determining the vehicle's presence in the storage area. Each conclusion is associated with a corresponding status node, rule node, and event node, and retains access anchors for the original trajectory, on-site images, authorization query records, and supplementary data collection results.

[0054] Ultimately, the system encapsulates the regulatory conclusion, risk level, status uncertainty, rule basis, key evidence path, reverse evidence, and recommended actions into a regulatory interaction result. For cases with insufficient evidence, it outputs the status to be verified and the missing evidence, without generating a definitive conclusion; for requests with insufficient permissions, it only returns a status summary that is allowed to be viewed. By establishing a step-by-step referencing relationship between the interaction content and evidence nodes, users can trace back from the conclusion to the status formation process and the original regulatory event, improving the accuracy and traceability of regulatory interpretation.

[0055] In some embodiments, the regulatory operation in the regulatory interaction request is subject to permission verification, the regulatory operation that passes the permission verification is executed, and the regulatory status twin and the time-series regulatory evidence graph are updated based on the operation feedback, including: Analyze regulatory operations to determine the targets, types, and conditions for execution. Based on the identity and permissions of the requesting entity, the authorization rules in the contract rule execution diagram, the vehicle risk status, and the operating status of the regulatory end, an operation authorization context is generated, and the operation authorization context is matched with the execution conditions to generate an authorization verification result. For supervisory operations that pass permission verification, an execution instruction carrying a task identifier and integrity verification information is generated and sent to the corresponding supervisory terminal; Receive operational feedback from the regulatory authority, associate the operational feedback with the regulatory operation based on the task identifier, and verify the consistency between the operational execution result and the expected state change; The regulatory status twin is updated based on the verified operation feedback, and the regulatory operation, permission verification result, and operation execution result are written into the time-series regulatory evidence graph.

[0056] Specifically, when the regulatory interaction result includes an operation request, an independent operation instance can be created for each regulatory operation. The system extracts the asset identifier, target regulatory end, operation type, expected status, execution time limit, and additional conditions from the request content, and confirms the requesting subject based on the current session identity. For example, if a risk specialist from a financial institution initiates an on-site inspection and high-frequency sampling operation for a high-risk vehicle using an on-board monitoring device, the system identifies the vehicle as the operation target, the on-site inventory and trajectory supplementation as the operation type, and confirming the vehicle's actual location, verifying the vehicle identification code, and confirming the device binding status as the execution conditions. If the request content only expresses the need to inspect a vehicle but does not specify the target vehicle, the system does not generate an execution instruction, but instead returns information on the object to be supplemented based on the session context and the authorized vehicle range.

[0057] Permission verification can employ dynamic strategy matching based on attributes and rule paths. The system gathers the requesting entity's organization, role, data access scope, and current login credibility. It reads the authorizing entity, triggering conditions, approval level, and time limit for the corresponding operation in the contract rule execution graph. Then, it combines the vehicle's risk status, status uncertainty, online status of the regulatory end, and executable capabilities to generate an operation authorization context.

[0058] For example, ordinary query personnel only have the authority to view risk evidence and cannot assign on-site tasks; risk specialists can initiate supplementary data collection after a vehicle reaches a warning state, but high-impact operations that restrict vehicle disposal still require review personnel approval. If the vehicle is in a high-risk state, the on-site operation terminal is online, the task has not exceeded the daily assignment limit, and the requesting entity has the corresponding dealer's regulatory authority, then the strategy matching will be successful; if the personnel's authority is invalid, the vehicle has been released from pledge, or the regulatory terminal is offline, then a rejection or manual approval result will be generated.

[0059] For operations requiring multi-level authorization, the system can associate the initial request, review comments, and final authorization with the same operation instance, and verify the approval order and validity period. After passing the permission verification, the system generates a unique task identifier, and combines the asset identifier, operation parameters, target monitoring terminal, instruction generation time, expiration time, and expected feedback fields into an instruction payload. A digest is calculated for the instruction payload, and a digital signature and random check value are attached. Upon receiving the payload, the monitoring terminal verifies the signature, task identifier, and validity period to prevent instruction tampering, repeated execution, or cross-vehicle invocation. For example, a high-frequency sampling instruction limits location feedback to once every 10 seconds within 3 minutes, while an on-site verification instruction requires uploading vehicle identification code scan results, real-time positioning, vehicle images, and operator identification information.

[0060] Furthermore, after the regulatory end completes the operation, it returns the execution status, start time, end time, collection results, device status, and reason for the anomaly according to the task identifier. The system first verifies the consistency between the feedback signature, task identifier, and asset identifier, and then checks whether the execution time is within the authorized window, whether the returned fields are complete, and whether the operation parameters meet the instruction requirements. For duplicate feedback, duplicates are removed according to the result summary; for data returned after timeout or with mismatched identities, it is only saved as an anomaly record and the vehicle status is not directly updated.

[0061] In some examples, if the on-site operation terminal reports that the vehicle is outside the warehouse and the vehicle identification number matches, and the on-board monitoring device simultaneously generates a continuous trajectory outside the warehouse, then the operation feedback is consistent with the expected verification target. If the task shows successful execution but the vehicle identification number is not uploaded, or the reported location is far from the operator's location, then the execution result is considered incomplete, an abnormal feedback flag is generated, and a re-verification is triggered.

[0062] The system further compares the operation execution result with the expected state change set before the operation. Expected state changes may include the resolution of state conflicts, the completion of missing evidence, the restoration of equipment status, or the completion of risk disposal tasks. If the feedback supports a unique candidate state, the state uncertainty is reduced and the regulatory state twin is updated; if the feedback proves that the original anomaly originated from equipment failure, the normal vehicle status is retained, and the equipment reliability is updated; if the feedback further supports unauthorized departure, the vehicle risk level is increased and subsequent disposal rules are triggered. For operations that do not achieve the expected change, the system records the reason for incompleteness but does not forcibly overwrite the original state.

[0063] After verification, the system treats the regulatory operation as an operation node, the permission verification result as an authorization node, and the execution instruction and operation feedback as event nodes. These are written into a time-series regulatory evidence graph according to the chronological order of request, authorization, execution, feedback, and status update, and associated with the requesting entity, target vehicle, corresponding rule node, and original data anchor. A regulatory status twin synchronously stores the most recent operation status, execution result, risk changes, and unfinished items. This enables full control over the regulatory operation process from interactive request to actual execution, and ensures traceability of each authorization basis, instruction content, feedback result, and status change, reducing the risks of unauthorized operations, erroneous execution, and distorted feedback.

[0064] In some embodiments, the system further includes a group risk analysis module, used for: The corresponding pledged asset supervision objects are associated with the identification of the operating entity, and a supervision relationship diagram of the operating entity is constructed based on the dynamic relationship between each pledged asset supervision object and the supervision elements; Within the preset analysis window, cross-object synchronous anomalies and regulatory element reuse conflicts are extracted from the regulatory relationship diagram of business entities. The associated risk propagation path is determined by combining the temporal correlation and event credibility of the corresponding regulatory events. The risk status of the business entity is generated based on the coverage, intensity, and rule violation of the associated risk propagation path, and the risk status of the associated vehicles and the uncertainty of the status are corrected using the risk status of the business entity.

[0065] Specifically, an entity identifier can be established for each distributor, warehouse operator, or other business entity. Based on financing contracts, regulatory agreements, and asset ownership records, the corresponding pledged assets are grouped into the same analytical domain. The system uses the business entity as the central node and pledged vehicles, monitoring equipment, RFID tags, vehicle certificates, keys, warehouse areas, on-site personnel, and monitoring tasks as associated nodes. Based on dynamic relationships, it establishes asset ownership edges, equipment binding edges, certificate custody edges, personnel operation edges, and shared space edges. For each associated edge, the system records its effective date, expiration date, relationship source, and association credibility, forming a business entity monitoring relationship diagram.

[0066] For example, dealer D003 has 40 pledged vehicles, of which vehicles A, B, and C are each bound to different on-board monitoring devices. However, all three vehicles experienced location data transmission interruptions between 2 PM and 3 PM on the same day, and their corresponding RFID tags were continuously read in the same storage area. The system uses a preset analysis window of 60 minutes and updates the window in 10-minute increments. It aggregates the status of each node and regulatory events within the window, removes duplicate reports based on event fingerprints, and identifies the time of anomaly occurrence, anomaly type, number of involved objects, and common related elements. Overlapping events in the window are retained only once to avoid duplication and amplification. If multiple vehicles simultaneously experience device offline, sudden location changes, changes in voucher status, or failed on-site inventory within a similar timeframe, it is identified as a cross-object synchronous anomaly. If the same RFID tag, on-board monitoring device, vehicle voucher number, key number, or work account is simultaneously associated with multiple vehicles within a valid time period, it is identified as a regulatory element reuse conflict.

[0067] The identification of cross-object synchronization anomalies can be determined by combining temporal proximity, spatial proximity, and anomaly type consistency. For example, if the on-board monitoring devices of vehicles A, B, and C go offline successively within 8 minutes, and their last locations before going offline are all near the same entrance / exit, and the associated work account performed a centralized inventory before the anomaly occurred, then the system connects the three anomaly events into a synchronization anomaly cluster. For reuse conflicts, the system further checks whether there is an authorized equipment replacement transition period or batch inventory sharing relationship. If the conflict can be explained by valid authorization, the conflict level is reduced; if the same tag is read continuously in two warehouse areas, or the same voucher number is declared and used by different vehicles simultaneously, the conflict credibility is increased.

[0068] The system can use abnormal events as a starting point to trace shared equipment, personnel, storage areas, and tasks along the regulatory relationship diagram of operating entities, forming candidate risk propagation paths. Adjacent events in the path must meet a preset time interval, and the path validity is calculated based on event credibility, related edge credibility, and consistency of the abnormal direction. For example, if a work account modifies the equipment binding relationships of three vehicles, and subsequently the related devices go offline, and the on-site inventory is submitted by the same account, a propagation path can be formed: work account, binding change, equipment offline, and abnormal inventory results. If only low-credibility single-point data exists in the path, it is not considered a valid propagation path but is retained as a pending verification association.

[0069] The risk status of an operating entity can be generated based on the proportion of vehicles covered by the effective propagation path, the number of regulatory elements involved, the duration of cross-object anomalies, and the hit rule level. The larger the coverage, the more propagation nodes, and the more sufficient the evidence supporting the path, the higher the propagation intensity. If the path simultaneously violates rules such as unique device binding, vehicle in-warehouse status, and the authenticity of on-site operations, the degree of rule violation will increase accordingly. The system normalizes and weights the various indicators to form the risk status of the operating entity as normal, watchful, warning, or high-risk, and saves the main propagation paths and contributing objects.

[0070] When adjusting individual risks, the system does not directly equate the risk of the operating entity with the risk of all vehicles. Instead, it makes differentiated adjustments based on the strength of the association between each vehicle and the propagation path. Vehicles directly on the effective propagation path have their risk status increased and their dependence on a single normal event reduced. Vehicles that share equipment, personnel, or storage areas with high-risk nodes but have no direct anomalies have their status uncertainty increased and are included in the scope of key supplementary data collection. Vehicles with no effective association with the propagation path and with complete evidence maintain their original risk status.

[0071] For example, if vehicle D is currently in a normal state but shares the same operating account and entrance / exit with a high-risk vehicle, the system can maintain its vehicle risk status as "watchful," while simultaneously increasing the uncertainty of its status and triggering a targeted inventory check. Through this process, risks such as bulk transfers, centralized equipment removal, and reuse of regulatory elements that are difficult to detect with single-vehicle rules can be identified, improving the risk detection capabilities at the operational level and the accuracy of related vehicle assessments.

[0072] In some embodiments, the system further includes a regulatory policy adjustment module, used for: The regulatory intensity of the target vehicle is determined based on the vehicle's risk status, status uncertainty, and contract rule execution diagram; Obtain the execution capabilities and historical regulatory responses of available regulatory authorities, and generate candidate regulatory strategies that include the frequency of regulatory data collection, the triggering conditions for regulatory actions, and the collaborative relationships between regulatory authorities within the regulatory boundaries defined by the contract rule execution graph; Based on a joint assessment of the risk coverage, uncertainty reduction, and regulatory resource utilization of each candidate regulatory strategy, a target regulatory strategy is determined, and the collection methods of multi-source regulatory data and corresponding regulatory actions are adjusted in accordance with the target regulatory strategy.

[0073] Specifically, a regulatory strategy status table can be established for each pledged asset under supervision, continuously recording the vehicle's risk status, status uncertainty, current regulatory intensity, recent regulatory events, available regulatory terminals, and resource usage. The system first reads the minimum regulatory requirements, maximum data collection frequency, allowed regulatory actions, and prohibited execution conditions that match the target vehicle from the contract rule execution diagram, and then determines the basic regulatory intensity by combining the vehicle's risk status and status uncertainty.

[0074] For example, vehicles with normal status and complete evidence can be subject to low-intensity supervision, vehicles under warning status can be subject to high-intensity supervision, and vehicles with low risk levels but high uncertainty of status can be subject to enhanced supervision that favors supplementary evidence collection. The intensity of supervision can be generated by weighting risk level score, uncertainty score, urgency of rule handling, and risk correction amount of the operating entity, and mapped to four levels: basic, enhanced, key, and emergency.

[0075] The system acquires the execution capabilities of each regulatory end, including the online status, positioning accuracy, remaining battery power, and adjustable sampling cycle of vehicle-mounted monitoring devices; the coverage, concurrent reading capacity, and current load of RF readers; the personnel location, executable task types, and estimated response time of on-site operators; and the message distribution capacity and task concurrency limit of the regulatory platform. It also statistically analyzes historical regulatory responses, such as the successful re-collection rate, average response time, invalid feedback rate, and resource consumption of different regulatory ends for similar anomalies. If a vehicle-mounted monitoring device frequently goes offline recently, the reliability of the corresponding regulatory end is reduced; if an on-site operator in a warehouse can complete a targeted inventory within 5 minutes, the feasibility of on-site verification actions is improved.

[0076] Within the regulatory boundaries defined by the contract rule execution diagram, the system generates multiple sets of candidate regulatory strategies. Each set of candidate regulatory strategies includes at least the data collection frequency, action triggering conditions, and regulatory collaboration relationships. For example, for vehicles under watch with low uncertainty, a strategy can be generated that collects location data every 5 minutes, continuously samples for 3 minutes after a fence crossing, and triggers RF rereading after two consecutive anomalies. For high-risk vehicles with obvious evidence conflicts, a strategy can be generated that collects location data every 10 seconds, triggers on-site verification upon a single fence crossing, and allows parallel evidence collection by the vehicle-mounted monitoring device and the on-site operation terminal. If the contract stipulates that low-power devices should not be frequently woken up in non-high-risk states, the system limits the sampling frequency to prevent candidate strategies from exceeding the rule boundaries.

[0077] The risk coverage level can be determined based on the types of risks that candidate regulatory strategies can monitor, the proportion of key status slots, and rule nodes; the uncertainty reduction level can be estimated based on the missing evidence items that the strategy can fill, the verifiable status conflicts, and historical success rates; the regulatory resource consumption level can be calculated based on communication traffic, equipment energy consumption, manpower hours, and task concurrency. The system normalizes these three types of indicators, increasing the risk coverage weight in high-risk scenarios, increasing the uncertainty reduction weight in high-uncertainty scenarios, and increasing the resource consumption constraint weight when regulatory resources are scarce. For example, if candidate strategy A has a risk coverage of 0.92, an uncertainty reduction of 0.78, and a resource consumption of 0.84, while candidate strategy B has corresponding indicators of 0.86, 0.74, and 0.46, then strategy A can be selected when resources are sufficient, and strategy B can be selected when resources are scarce.

[0078] Once the target monitoring strategy is determined, the system breaks it down into executable parameters and distributes them to the corresponding monitoring terminals. For vehicle-mounted monitoring devices, the positioning sampling cycle, heartbeat frequency, and anomaly caching method are adjusted; for radio frequency (RF) readers, the directional reading cycle and anomaly tag verification conditions are adjusted; for field operation terminals, task priority, verification scope, and feedback fields are adjusted; and for the monitoring platform, the early warning trigger threshold and task coordination order are updated. Different monitoring terminals can be configured to operate sequentially or in parallel. For example, the vehicle-mounted monitoring device can perform high-frequency sampling first, and if the trajectory is still abnormal, RF rereading and on-site inventory can be triggered simultaneously.

[0079] After the strategy is executed, the system continuously records the actual risk hit rate, changes in uncertainty, response time, and resource consumption, and compares these with the strategy evaluation results. When vehicle risk decreases and evidence stabilizes, the frequency of data collection and the probability of triggering on-site tasks are gradually reduced; when risk continues to rise, supplementary data collection is ineffective, or equipment capacity declines, candidate regulatory strategies are regenerated.

[0080] To avoid frequent shifts in regulatory intensity, a hysteresis mechanism can be set up to allow for immediate upgrades and delayed downgrades, with limits on the magnitude of single parameter adjustments. When the target strategy fails to be implemented or key regulatory endpoints become unavailable, the system reverts to a safety strategy that meets the minimum regulatory requirements, simultaneously generating a regulatory capacity insufficiency event to prevent regulatory gaps caused by strategy switching. Through these measures, regulatory intensity can dynamically change with vehicle risk and evidence status, balancing risk coverage, evidence completeness, and resource utilization efficiency while meeting contract regulatory boundaries.

[0081] The above embodiments have described in detail the specific components and functions of the intelligent interactive system for automobile pledge supervision of this application. The implementation process of the intelligent interactive method for automobile pledge supervision of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the intelligent interactive method for vehicle pledge supervision provided in an embodiment of this application, as shown below. Figure 2 As shown, the method may specifically include the following steps: S201: Obtain multi-source regulatory data and regulatory constraint data, establish the association between vehicle entities and regulatory elements based on asset identification, and generate pledged asset regulatory objects; S202, perform time-series correction and credibility assessment on multi-source regulatory data, and update the regulatory status twin of the pledged asset regulatory object according to the relationship; S203 converts regulatory constraint data into a contract rule execution diagram, and determines the vehicle risk status and status uncertainty based on the contract rule execution diagram and regulatory status twin. S204, When the state uncertainty meets the supplementary data collection conditions, the target regulatory action is determined based on the expected information gain of the candidate regulatory action, and supplementary regulatory data is obtained; S205, update vehicle risk status based on supplementary regulatory data and construct a time-series regulatory evidence graph; S206, in response to regulatory interaction requests, extract relevant information from the regulatory status twin, contract rule execution graph, and time-series regulatory evidence graph, and generate regulatory interaction results; S207, perform permission verification on the regulatory operation in the regulatory interaction request, execute the regulatory operation that has passed the permission verification, and update the regulatory status twin and the time-series regulatory evidence graph based on the operation feedback.

[0082] Specifically, in step S201, the system acquires multi-source regulatory data from the regulatory platform, vehicle monitoring devices, radio frequency reading equipment, and on-site operation terminals, including vehicle financing, equipment binding, location trajectory, inventory verification, vehicle certificates, and regulatory tasks. Simultaneously, it acquires regulatory constraint data formed by financing contracts, regulatory agreements, and institutional configurations. For data from different sources, the system performs field mapping, format normalization, time stamping, and duplicate data removal to generate regulatory events with source and time identifiers.

[0083] Subsequently, based on the vehicle identification number, an asset identifier is generated by combining the operating entity number and the financing contract number. Following the binding scope, binding quantity, and validity period specified in the regulatory constraints, a dynamic association is established between the vehicle entity and the on-board monitoring device, RFID tag, vehicle certificate, key, and regulatory tasks. For scenarios involving equipment replacement or certificate transfer, the expiration time of the original association and the effective time of the new association are recorded. The system identifies conflicts such as misbinding and duplicate binding through identity matching, time overlap, and association credibility verification, and encapsulates valid associations and corresponding regulatory events as pledged asset regulatory objects.

[0084] In step S202, the system establishes a unified monitoring timeline based on the occurrence and reception times of the monitoring events. For devices with fixed clock deviations, the offset is calculated based on historical heartbeat information, and the event occurrence time is corrected. For events with large network latency fluctuations, the original time is retained, but the time reliability is reduced. The system further calculates the event reliability based on data source reliability, field completeness, asset association matching degree, and data timeliness.

[0085] Subsequently, regulatory events are mapped to corresponding pledged asset regulatory objects according to dynamic correlations. Changes in vehicle location, operational status, inventory status, voucher status, and task status are extracted and merged according to chronological order and event credibility to update the regulatory status twin. When different sources provide contradictory results for the same status, the system does not directly overwrite the original status but retains multiple candidate statuses, generates status conflict identifiers, and calculates status uncertainty based on differences in evidence, degree of missing evidence, and data freshness.

[0086] In step S203, the system segments and parses the regulatory constraint data into clauses, extracting applicable conditions, state constraints, evidence requirements, and handling rules. For example, the clause prohibiting vehicles from leaving designated storage areas without authorization during periods of outstanding financing can be converted into applicable conditions for vehicles, storage area location constraints, continuous location evidence requirements, and rules for handling abnormal departures. Each constraint is converted into executable rule units, which are then connected according to the triggering order and handling dependencies to form a contract rule execution graph.

[0087] Furthermore, the system performs loop triggering, condition missing, and rule conflict checks on the rule execution graph, and inputs the current state in the regulatory status twin into the corresponding rule node for matching. If the vehicle leaves the designated area, the on-board equipment goes offline, or the certificate status is abnormal, the corresponding abnormal state and supporting evidence are determined. The system generates the vehicle risk status based on the degree of rule violation, the duration of the abnormality, and the credibility of the evidence, and calculates the state uncertainty based on the lack of evidence, state conflicts, and data timeliness.

[0088] In step S204, when the state uncertainty reaches the supplementary sampling threshold, the system analyzes the missing evidence and state conflict items causing the uncertainty to determine the vehicle state that needs to be verified. For example, when the vehicle positioning system shows that the vehicle is outside the warehouse, but the RFID tag is still being read in the warehouse area, the actual location of the vehicle and the tag binding status can be determined as the regulatory state to be verified. The system extracts candidate regulatory actions that can verify this state from the contract rule execution diagram, including increasing the positioning sampling frequency, performing RFID repeat reading, or initiating on-site inventory.

[0089] For each candidate regulatory action, the system estimates the degree to which the action reduces missing evidence and state conflicts based on historical execution success rates and current equipment status, generating expected information gain. Then, it conducts a utility evaluation by considering action response time, equipment capabilities, personnel accessibility, and resource consumption, selecting the target regulatory action with higher utility that meets the rule boundaries. The target regulatory action is converted into an instruction containing task identifier, asset identifier, execution parameters, and effective time period and sent to the corresponding regulatory end. The execution result returned by the regulatory end is verified for identity, time, and completeness to form supplementary regulatory data.

[0090] In step S205, the system matches the supplementary regulatory data with the original regulatory status to be verified and recalculates the support strength of the candidate statuses. For example, after the on-site operation terminal uploads the vehicle identification code scan result with location information and real-time image, it can confirm whether the vehicle entity is located in the warehouse area. Based on this, the system eliminates invalid candidate statuses, corrects status uncertainty, and updates the regulatory status twin and vehicle risk status. At the same time, using vehicles, regulatory equipment, and certificates as regulatory object nodes, location status, equipment status, and risk status as regulatory status nodes, rule conditions and disposal requirements as rule nodes, and location feedback, radio frequency reading, on-site inventory, and supplementary collection results as regulatory event nodes, a correlation edge is established according to asset ownership, event sequence, and rule triggering relationship to form a time-series regulatory evidence graph. Each node and correlation edge records time, credibility, and original data anchor point to support the traceability of risk conclusions.

[0091] In step S206, the system responds to the regulatory interaction request initiated by the user through the regulatory platform or mobile terminal, and parses the requesting subject, target vehicle, query time range, and interaction intent. The system extracts the current vehicle status and risk status from the regulatory status twin, retrieves the regulatory rules matching the current status from the contract rule execution graph, and searches for event paths supporting the rule judgment along the time-series regulatory evidence graph.

[0092] For example, in response to a request regarding why a vehicle was deemed high-risk, the system can extract information such as the vehicle leaving the storage area, the abnormal duration exceeding the rule threshold, the lack of valid outbound authorization, and on-site verification confirming departure. Subsequently, based on the current status, rule basis, and evidence path, a regulatory conclusion is generated, and the various judgments in the conclusion are linked to the corresponding status nodes, rule nodes, and event nodes to form a regulatory interaction result that includes risk level, judgment basis, key evidence, and status uncertainty.

[0093] In step S207, when the regulatory interaction request includes task assignment, supplementary collection control, or equipment operation, the system parses the operation object, operation type, and execution conditions, and generates an operation authorization context based on the requesting entity's identity and permissions, the authorization conditions in the contract rule execution diagram, the vehicle risk status, and the regulatory terminal's operating status. The system performs policy matching between the operation authorization context and the execution conditions to obtain a permission verification result of allowing execution, denying execution, or requiring review.

[0094] For verified regulatory operations, the system generates an execution instruction carrying task identifier, asset identifier, valid time period, and integrity verification information, and sends it to the corresponding regulatory end. After the regulatory end returns operation feedback, the system establishes a correlation between the operation request, execution instruction, and operation feedback based on the task identifier, and verifies whether the actual execution result achieves the expected state change. The verified operation feedback is used to update the regulatory state twin, and the regulatory operation, permission verification result, execution process, and feedback result are written into the time-series regulatory evidence graph, thereby forming a closed-loop regulatory process from regulatory data acquisition, risk identification, proactive supplementary data collection, intelligent interaction to controlled execution.

[0095] 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.

[0096] 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 smart interactive system for supervising vehicle pledges, characterized in that, include: The regulatory object construction module is used to acquire multi-source regulatory data and regulatory constraint data, establish the association between vehicle entities and regulatory elements based on asset identification, and generate pledged asset regulatory objects. The state twin module is used to perform time-series correction and credibility assessment on the multi-source regulatory data, and update the regulatory state twin of the pledged asset regulatory object according to the correlation relationship. The rule analysis module is used to convert the regulatory constraint data into a contract rule execution graph, and determine the vehicle risk status and status uncertainty based on the contract rule execution graph and the regulatory status twin. The active data acquisition module is used to determine the target regulatory action based on the expected information gain of the candidate regulatory actions and acquire supplementary regulatory data when the state uncertainty meets the data acquisition conditions. The evidence interaction module is used to update the vehicle risk status based on the supplementary regulatory data, construct a time-series regulatory evidence graph, and respond to regulatory interaction requests. It extracts related information from the regulatory status twin, the contract rule execution graph, and the time-series regulatory evidence graph to generate regulatory interaction results. The controlled execution module is used to verify the permissions of the regulatory operations in the regulatory interaction request, execute the regulatory operations that pass the permission verification, and update the regulatory status twin and the time-series regulatory evidence graph according to the operation feedback.

2. The system according to claim 1, characterized in that, The acquisition of multi-source regulatory data and regulatory constraint data, establishing the association between vehicle entities and regulatory elements based on asset identification, and generating pledged asset regulatory objects include: The raw data from the regulatory platform, sensing devices and field operation terminals are formatted and time-series aligned to generate regulatory events carrying source and time identifiers; Extract the scope of asset supervision and relationship constraints from the aforementioned regulatory constraint data; The asset identifier is generated based on the vehicle identity information, and a dynamic association with a valid time period is established with the regulatory events and regulatory elements corresponding to the same vehicle according to the relationship constraints. Conflicting associations are identified based on consistency and data credibility, and the dynamic associations that pass consistency verification and the corresponding regulatory events are encapsulated as the pledged asset regulatory objects.

3. The system according to claim 1, characterized in that, The step of performing time-series correction and credibility assessment on the multi-source regulatory data, and updating the regulatory status twin of the pledged asset regulatory object according to the correlation, includes: A unified regulatory timeline is established based on the occurrence and reception times of each regulatory event, and time corrections are performed for regulatory events with clock deviations. Event credibility is generated based on data source reliability, data completeness, correlation matching degree, and timeliness; Based on the aforementioned relationships, regulatory events are mapped to the corresponding pledged asset regulatory objects, and the status changes reflected by each regulatory event are extracted. The regulatory state twin is updated by fusing the state changes based on the event credibility and regulatory timeline. When there are conflicts in the state changes corresponding to different regulatory events, candidate states are retained and state conflict identifiers and corresponding state uncertainties are generated.

4. The system according to claim 1, characterized in that, The step of converting the regulatory constraint data into a contract rule execution graph, and determining the vehicle risk status and status uncertainty based on the contract rule execution graph and the regulatory status twin, includes: Extract applicable conditions, status constraints, evidence requirements, and disposal rules from the regulatory constraint data to generate executable rule units; The executable rule units are connected according to the rule triggering relationship and the handling dependency relationship to construct the contract rule execution graph, and the rule conflict and execution integrity are verified. The current state in the regulatory state twin is matched with the contract rule execution graph to determine the abnormal state that violates the state constraint and the corresponding evidence. The vehicle risk status is generated based on the degree of rule violation and the credibility of the evidence in the abnormal state, and the state uncertainty is generated based on the degree of evidence missing, the degree of state conflict and the timeliness of the data.

5. The system according to claim 1, characterized in that, When the state uncertainty meets the supplementary data acquisition condition, the target regulatory action is determined based on the expected information gain of the candidate regulatory action, and supplementary regulatory data is acquired, including: Based on the missing evidence items and conflicting state items corresponding to the state uncertainty, the regulatory state to be verified is determined, and candidate regulatory actions matching the regulatory state to be verified are extracted from the contract rule execution diagram. Based on the expected reduction of the missing evidence items and state conflict items by each candidate regulatory action, the corresponding expected information gain is determined. Based on the expected information gain, action execution constraints, and regulatory timeliness requirements, the utility of each candidate regulatory action is evaluated, and the candidate regulatory action whose utility evaluation results meet the selection criteria is determined as the target regulatory action. The target regulatory action is sent to the corresponding regulatory authority, the action execution result is received, and the supplementary regulatory data is generated according to the asset identifier and execution sequence.

6. The system according to claim 1, characterized in that, The process involves updating the vehicle risk status based on the supplementary regulatory data, constructing a time-series regulatory evidence graph, and responding to regulatory interaction requests. It extracts relevant information from the regulatory status twin, the contract rule execution graph, and the time-series regulatory evidence graph to generate regulatory interaction results, including: The supplementary regulatory data is matched with the regulatory status to be verified, the status uncertainty is corrected, and the regulatory status twin and the vehicle risk status are updated. Using regulatory objects, regulatory status, rule units, and regulatory events as evidence nodes, evidence association edges are established according to asset association, event sequence, and rule triggering relationship to generate the time-series regulatory evidence graph; The regulatory interaction request is analyzed to determine the target regulatory object and the interaction intent. The current state is extracted from the regulatory state twin, and the corresponding rules and evidence paths are retrieved along the contract rule execution graph and the time-series regulatory evidence graph. Based on the current state, corresponding rules, and evidence path, a regulatory conclusion is generated, and a reference relationship between the regulatory conclusion and the evidence node is established to form the regulatory interaction result.

7. The system according to claim 1, characterized in that, The step of verifying the permissions of the regulatory operations in the regulatory interaction request, executing the regulatory operations that pass the permission verification, and updating the regulatory status twin and the time-series regulatory evidence graph based on the operation feedback includes: Analyze the regulatory operation to determine the target, type, and execution conditions; Based on the identity and permissions of the requesting subject, the authorization rules in the contract rule execution diagram, the vehicle risk status, and the operating status of the regulatory terminal, an operation authorization context is generated, and the operation authorization context is matched with the execution conditions to generate an authorization verification result. For supervisory operations that pass permission verification, an execution instruction carrying a task identifier and integrity verification information is generated and sent to the corresponding supervisory terminal; Receive operation feedback returned by the regulatory end, associate the operation feedback with the regulatory operation according to the task identifier, and verify the consistency between the operation execution result and the expected state change; The regulatory status twin is updated based on the verified operation feedback, and the regulatory operation, permission verification result, and operation execution result are written into the time-series regulatory evidence graph.

8. The system according to claim 1, characterized in that, The system also includes a group risk analysis module, used for: The corresponding pledged asset supervision objects are associated with the identification of the operating entity, and a supervision relationship diagram of the operating entity is constructed based on the dynamic relationship between each pledged asset supervision object and the supervision elements; Within the preset analysis window, cross-object synchronization anomalies and regulatory element reuse conflicts are extracted from the regulatory relationship diagram of the business entities. The associated risk propagation path is determined by combining the temporal correlation and event credibility of the corresponding regulatory events. The risk status of the business entity is generated based on the coverage, intensity, and rule violation degree of the associated risk propagation path, and the risk status of the associated vehicles and the uncertainty of the status are corrected using the risk status of the business entity.

9. The system according to claim 1, characterized in that, The system also includes a regulatory policy adjustment module, used for: The regulatory intensity of the target vehicle is determined based on the vehicle risk status, the status uncertainty, and the contract rule execution diagram; Obtain the execution capabilities and historical regulatory responses of available regulatory agencies, and within the regulatory boundaries defined by the contract rule execution graph, generate candidate regulatory strategies that include the frequency of regulatory data collection, the triggering conditions for regulatory actions, and the collaborative relationships of regulatory agencies. Based on a joint assessment of the risk coverage, uncertainty reduction, and regulatory resource utilization of each candidate regulatory strategy, a target regulatory strategy is determined, and the collection method of the multi-source regulatory data and corresponding regulatory actions are adjusted in accordance with the target regulatory strategy.

10. A smart interactive method for supervising vehicle pledge based on the system described in any one of claims 1 to 9, characterized in that, include: Acquire multi-source regulatory data and regulatory constraint data, establish the association between vehicle entities and regulatory elements based on asset identification, and generate pledged asset regulatory objects; The multi-source regulatory data is subjected to time-series correction and credibility assessment, and the regulatory status twin of the pledged asset regulatory object is updated according to the correlation. The regulatory constraint data is converted into a contract rule execution graph, and the vehicle risk status and status uncertainty are determined based on the contract rule execution graph and the regulatory status twin. When the state uncertainty meets the supplementary data acquisition conditions, the target regulatory action is determined based on the expected information gain of the candidate regulatory action, and supplementary regulatory data is acquired. The vehicle risk status is updated based on the supplementary regulatory data, and a time-series regulatory evidence graph is constructed. In response to regulatory interaction requests, relevant information is extracted from the regulatory status twin, the contract rule execution graph, and the time-series regulatory evidence graph to generate regulatory interaction results; The regulatory operation in the regulatory interaction request is subject to permission verification. The regulatory operation that passes the permission verification is executed, and the regulatory status twin and the time-series regulatory evidence graph are updated based on the operation feedback.

Images