Security management method based on face recognition

Abstract

The present application relates to the technical field of computer vision security, and discloses a security management method based on face recognition, which is used to solve the technical problem that it is difficult to stabilize the association of the same person's face identity in the multi-camera cross-point and cross-time monitoring of the traditional method, which is affected by light, posture, shielding and fluctuation; the method first constructs the passing relationship of the camera point and unifies the time reference, collects the snapshot image and generates the collection condition label, executes idempotent deduplication and sequential rearrangement on the warehouse data; based on the state dictionary and hierarchical mapping table, the snapshot record is quality graded, and multiple observation sequences are organized according to the observation window rule; under the constraint of the compatible rules of the association time window and the collection condition, the candidate association pair is generated and the evidence package is converged, and after the hierarchical confirmation and conflict shunting, it is written into the versioned identity relationship graph, the incremental association is executed according to the latest effective version, and the invalidation rule is set for the records to be reviewed, which realizes the continuous and traceable security management of the cross-point identity chain.

Description

Technical Field

[0001] This invention relates to the field of computer vision security technology, specifically a security management method based on facial recognition. Background Technology

[0002] With the increasing demand for access control and video surveillance in parks, communities, campuses and key locations, facial recognition-based security management technology is widely used in access control, visitor verification, key personnel early warning and post-event tracing. Existing systems typically acquire facial images of people through cameras, extract facial features and compare them with a facial image database, and execute actions such as granting access, issuing alarms or recording and archiving based on the comparison results, thereby achieving automated identification and management of personnel.

[0003] For example, the published invention patent application CN107784724A proposes a security management method based on face recognition, which realizes the identification and management of personnel identity through face information registration and database, comparison and verification, and management process configuration; another example is the published invention patent application CN110795963A, which proposes a monitoring method based on face recognition, which realizes the prompting and handling of abnormal objects by performing face recognition on the monitoring screen and combining trusted objects and alarm strategies. These existing technologies can complete identification and alarm in a single entrance or single monitoring screen, but their technical focus is mostly on single-point comparison, rule triggering and result output. They usually treat the face recognition results collected by different cameras as independent recognition events, and lack a stable identity association mechanism for continuous monitoring of multiple cameras across points and time.

[0004] In real-world security management scenarios, the same person often enters the field of view of multiple cameras at different locations and times, and the acquisition conditions vary significantly. These factors include changes in lighting intensity, backlighting and backlighting, differences in posture and angle, blurring caused by movement, obstruction from masks and helmets, differences in camera image quality and focal length, and obstruction and interference caused by dense crowds. These factors can cause the distribution of the same person's appearance features to drift under different cameras, resulting in the same person being split into multiple identities and different people being mistakenly associated with the same identity. This makes it difficult to guarantee the continuity of the trajectory across locations, and the personnel identity chain on which event handling and tracing depend is prone to breakage or cross-connection, ultimately affecting the accuracy and usability of security management.

[0005] Therefore, there is an urgent need for a security management method based on facial recognition that can stably and consistently associate the facial identity of the same person across multiple cameras, locations, and time periods, even under the influence of complex and fluctuating acquisition conditions, so as to achieve the goal of continuous and traceable management of personnel identity. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a security management method based on facial recognition, which solves the technical problem in traditional methods where multiple cameras monitoring across locations and times are difficult to stably associate the facial identity of the same person due to fluctuations in lighting, posture, and occlusion.

[0007] To achieve the goal of continuous traceability of personnel identity mentioned in the background section, the present invention provides the following technical solution:

[0008] Security management methods based on facial recognition include:

[0009] S1: Establish the camera location topology and unify the time base, and configure cross-location association time windows and access event types;

[0010] S2: Each location captures a face image when a passage event is triggered, and records the device identifier, timestamp, and collection condition label;

[0011] S3: Classify the quality of the captured data and organize a multi-frame observation sequence according to time windows;

[0012] S4: Generate cross-location candidate association pairs based on location topology and associated time windows, and aggregate multi-frame observation sequences and acquisition condition labels into an evidence package;

[0013] S5: Perform hierarchical confirmation and conflict diversion on candidate association pairs, transfer conflict records to secondary confirmation and register conflict types;

[0014] S6: Confirm the relationship and write it into the versioned identity relationship graph. Subsequent records will be associated incrementally according to the latest version. Unconfirmed records will be entered into the pending review and invalidation conditions will be set.

[0015] In a preferred embodiment, a camera location topology is established and a unified time base is implemented. Cross-location associated time windows and access event types are configured, including:

[0016] Establish point files and set point roles, construct point access relationships, record branch and area / floor adjacency, generate relationship versions and duration baseline versions, and derive associated time window template versions;

[0017] The platform clock calibration maintains the offset effect record, time health and retransmission sequence mark, and the original timestamp, normalized timestamp and offset identifier are recorded in the database.

[0018] The strategy package is issued based on the event type and subject to the role of the location. After the event record is marked, it is reported into the database.

[0019] In a preferred embodiment, each location captures a facial image when a passage event is triggered, and records the device identifier, timestamp, and acquisition condition tags, including:

[0020] Access control or turnstile locations are merged into events according to the controller state sequence and key frames or candidate frames are output. Open areas are continuously tracked and triggered by targets and their events are merged.

[0021] The snapshot record is written with the location number, event type, image index and sequence mark, and the database is written with double timestamps, offset identifiers and deduplication and rearrangement.

[0022] The data collection condition labels are converted into platform-unified fields and values ​​according to a preset comparison relationship, and the records and images are stored separately.

[0023] Output frame metadata; for a single-frame device, it is padded by the buffer of adjacent frames at the edge.

[0024] In a preferred embodiment, the quality classification of the captured data includes:

[0025] Read the acquisition condition label, frame set metadata and image detection status, determine the quality level of the capture record based on the status enumeration dictionary and the hierarchical mapping table, and write the quality level, hierarchical basis field and source tag into the record;

[0026] Frames corresponding to unavailable records are treated as placeholder frames and included in the passage event timeline.

[0027] In a preferred embodiment, organizing a multi-frame observation sequence according to time windows includes:

[0028] The captured records are queued by location and event type and sorted by unified timestamp. Multiple frames are merged by observation window and platform event number.

[0029] When an event number is missing, it is combined with the trigger source, target tracking, channel direction, and scene label;

[0030] The frame retention rules are written to the primary and secondary indexes, the sequence tags are aggregated and the source is retained, the sequence number is generated, the platform event number and the device event instance identifier are associated, and the rule version is written.

[0031] In a preferred embodiment, generating cross-location candidate association pairs based on location topology and associated time windows includes:

[0032] For the observation sequence, determine the location and direction of travel, extract reachable points based on the path range rule entries and travel relationship versions, and divide the upstream candidate set and the downstream candidate set;

[0033] For retransmission sequences or sequences with time health anomalies, candidate matching is performed based on the time correction field and the order correction field, and the source of correction is recorded.

[0034] Semantic filtering is performed on the mapping entries based on event type constraints. If the directions are inconsistent, no candidates are generated and an audit record is registered.

[0035] In a preferred embodiment, multiple observation sequences and acquisition condition labels are aggregated into an evidence package, including:

[0036] Candidate sequence pairs are retrieved in the upstream and downstream queues based on the associated time window template entries, and time matching tightness markers and corresponding template entries and passage duration baseline entries are written.

[0037] Based on the rules for compatibility with the acquisition conditions, candidate sequence pairs are retained, down-weighted, or eliminated, and the rule references are recorded.

[0038] The evidence package is generated by aggregating the sequence identifiers from both ends, location and event type, time interval, primary and secondary evidence indexes, tag set, path reference and context source identifier, and is layered according to preset sorting items.

[0039] In a preferred embodiment, hierarchical confirmation and conflict triage are performed on candidate association pairs, including:

[0040] The evidence packages of candidate association pairs are sequentially verified for time consistency, travel path and direction, event type constraint hit, quality availability, and consistency of collection conditions and processing. During the verification, the associated time window template entries, travel duration baseline entries, travel relationship version, and constraint mapping entries are included.

[0041] For re-transmissions or records with time health anomalies, the time source reference is normalized and written to the verification status, cause category, hit entry reference, and evidence field index.

[0042] In a preferred embodiment, transferring the conflict record to secondary confirmation and registering the conflict type includes:

[0043] Candidates are aggregated using the same upstream or downstream sequence to generate a competitive set identifier, which is then combined with verification records to determine whether the sequence is directly confirmed, pending confirmation, or not confirmed.

[0044] The person directly confirming the information registers the confirmation record with the evidence package number and locks the verification and rule reference;

[0045] The entity awaiting confirmation registers the conflict type and associates it with the triggering item, evidence index, competition set identifier, mapping table version, and display template for secondary confirmation;

[0046] Unconfirmed entries are registered for audit purposes.

[0047] In a preferred embodiment, the confirmation relationship is written into a versioned identity relationship graph, and subsequent records are associated incrementally according to the latest version. Unconfirmed records are entered into a pending review stage and invalidation conditions are set, including:

[0048] The confirmed relationships are summarized into change sets in batches and appended to the generated effective version after consistency verification, and associated with the versions of the access relationships, time windows, and event type rules;

[0049] Establish or expand chains based on sequence ownership status; relationships with competition or merger risks are transferred to secondary confirmation.

[0050] New sequences are added incrementally according to the effective version, and unconfirmed relationships are entered into the pending review pool according to the evidence package number and handled according to the invalidation rules.

[0051] Compared with existing technologies, the present invention provides a security management method based on facial recognition, which has the following beneficial effects:

[0052] 1. This invention models point topology and traffic relationships, and establishes a unified time benchmark, offset maintenance, and time health management, enabling multi-camera traffic events to be aligned and traceable on the same timeline. It maps acquisition condition labels with a unified standard, and, in conjunction with idempotent deduplication, order rearrangement, and adjacent frame buffering for image capture, stabilizes cross-point observation input. Furthermore, it performs verifiable quality grading of capture records based on a state enumeration dictionary and hierarchical mapping table, and organizes multi-frame observation sequences containing primary and secondary evidence frames according to observation window rules. Under the constraints of associated time windows and acquisition condition compatibility rules, it generates candidate association pairs and aggregates evidence packages. Combined with consistency verification, hierarchical confirmation and conflict diversion of competing sets, and incremental writing and pending verification failure management of versioned identity relationship graphs, it reduces identity splitting and misassociation under complex lighting, pose, and occlusion fluctuations, ensuring the continuity and traceability of cross-point identity chains. This solves the technical problem in traditional methods where, in multi-camera cross-point and cross-time monitoring, fluctuations in lighting, pose, and occlusion make it difficult to stably associate the same person's face identity.

[0053] 2. This invention manages the key processing parameters for cross-location identity association by configuring them and binding them to version numbers. The platform integrates access relationships, event type constraints, associated time window templates, quality grading rules, observation window rules, and frame retention rules into an auditable rule base. This ensures that candidate generation, verification, grading confirmation, and relationship writing can all locate the corresponding rule entries and evidence package numbers. When multiple candidate competition, out-of-order retransmission, time health anomalies, or collection condition conflicts occur, the platform registers the conflict type and transfers it to secondary confirmation based on the rule hit record, disposal mark, context source identifier, and grading basis fields in the evidence package. At the same time, it performs closed-loop management and error correction updates for unconfirmed relationships through the retention, substitution, and path failure rules in the pending review pool. Ultimately, this improves the interpretability and maintainability of identity association decisions in complex park scenarios. Attached Figure Description

[0054] Figure 1 This is a schematic diagram of the security management method based on facial recognition according to the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] Example 1: Figure 1 A security management method based on facial recognition is presented, including:

[0057] S1: Establish the camera location topology and unify the time base, and configure cross-location association time windows and access event types;

[0058] S2: Each location captures a face image when a passage event is triggered, and records the device identifier, timestamp, and collection condition label;

[0059] S3: Classify the quality of the captured data and organize a multi-frame observation sequence according to time windows;

[0060] S4: Generate cross-location candidate association pairs based on location topology and associated time windows, and aggregate multi-frame observation sequences and acquisition condition labels into an evidence package;

[0061] S5: Perform hierarchical confirmation and conflict diversion on candidate association pairs, transfer conflict records to secondary confirmation and register conflict types;

[0062] S6: Confirm the relationship and write it into the versioned identity relationship graph. Subsequent records will be associated incrementally according to the latest version. Unconfirmed records will be entered into the pending review and invalidation conditions will be set.

[0063] S1: Establish the camera location topology and unify the time base, configure cross-location associated time windows and access event types, and implement the following:

[0064] In the context of park security management, the platform establishes unified files for monitoring points such as park entrances and exits, building lobbies, corridors, elevator halls, and parking lot gates during the system deployment phase, forming a point archive database for cross-point association. The platform assigns a unique point number to each camera and registers the installation location, orientation coverage, main coverage channel, channel direction attribute, and associated access facility identifiers in the point archive, giving the points basic identifiers that are locatable, traceable, and maintainable on the platform side. The platform sets a point role field in the point archive to characterize the business attributes of the point in the park's access links. The point role field at least distinguishes between entrance and exit points, indoor transition points, vertical transportation points, and vehicular access points, and serves as a unified basis for event type mapping, candidate point filtering, associated time window template selection, and access direction consistency verification.

[0065] After the location data is established, the platform performs structured modeling of the park's access paths, solidifying the reachability relationships between locations into a location access relationship diagram and creating a searchable relationship index. The location access relationship diagram is expressed using locations as nodes and reachability relationships as connections. The platform configures access direction attributes and access constraints for each connection. Access constraints are used to limit the applicable boundaries of the connection, specifying at least the applicable access scenarios, allowed access directions, and preconditions for the relationship to be established, avoiding the incorrect inclusion of locations that are only spatially adjacent but do not constitute continuous access in business operations. For traffic splitting scenarios where the same node leads to multiple nodes, the platform registers multi-branch access relationships and records the differential constraints of each branch. These differential constraints include at least the applicable personnel type, access vehicle type, or entry / exit direction type, enabling different branches to be distinguished during subsequent candidate generation. For continuous coverage scenarios of corridor-type locations, the platform organizes adjacent relationships by region and floor. The system forms regionally convergent relationship segments, which can be pruned by region or floor when generating candidate ranges to reduce invalid candidates. The platform further registers the applicable scope and conditions of the passage duration constraint for each connection relationship, which describes the reasonable passage rhythm boundary of the connection relationship under different operating modes, and allows switching of constraint configuration by time period or scenario, so that the relationship constraints under peak passage, night lighting mode or temporary control mode can be consistently effective on the platform side. In addition, the passage duration constraint is generated into a configuration baseline based on the survey results of the passage path between points, the park passage organization rules and historical passage event logs. The platform implements version management of the configuration baseline, records the effective conditions, applicable scope and change scope, and generates a new baseline version for retrospective when the configuration is adjusted. After the point passage relationship diagram is configured, the platform generates a relationship version identifier and maintains a version index for unified reference and management of relationship status, so that the candidate generation and subsequent confirmation process can use the relationship version as a stable constraint entry point.

[0066] To ensure that events across different locations are aligned on the same timeline, the platform establishes a unified time reference and time normalization mechanism. The platform uses its own time as the master clock to establish the time reference and sends time calibration commands to the camera or edge node to form a calibration link. Upon receiving the time calibration command, the device generates a calibration record and reports the offset between its local time and the platform's master clock. The calibration record is associated with the device identifier and the calibration time, enabling the platform to continuously monitor the correspondence between device time and platform time. The platform maintains a record of the currently effective offset for each location and sets an effective range and historical retention mechanism for the offset records. When a new calibration record is received, the platform updates the effective offset record and retains historical records. When a captured event is entered into the database, the platform completes time normalization based on the effective offset record corresponding to the event timestamp. Simultaneously, it writes the original device timestamp, the platform normalized timestamp, and the offset record identifier used into the event record, ensuring that the normalization basis can still be traced even if the same event experiences retransmission, link jitter, or device clock drift.

[0067] For locations with retransmission scenarios, the platform synchronously retains retransmission order markers or trigger order markers in the event logs. This enables the platform to perform consistency processing on out-of-order data under a unified time benchmark during candidate generation, avoiding time window matching deviations caused by changes in the entry order. The platform also maintains time health status markers for locations, judging whether there is a risk of time drift based on the offset stability and continuity of multiple time calibration records. The time health status markers distinguish between at least two states: normal and abnormal. When the time health status marker is abnormal, the platform implements stricter time consistency management rules for subsequent time window matching involving that location. These time consistency management rules include at least tightening the time window matching boundaries for abnormal locations, requiring candidate evidence records to carry offset record identifiers and retransmission order markers as verification criteria, and limiting the priority of related candidates for that location during the candidate pool generation stage. This ensures that the location is not used as the main decision-making basis for cross-location associations until it returns to normal, thereby confining the risk of erroneous associations caused by time drift within a controllable range.

[0068] After configuring access relationships at various points and establishing a unified time base, the platform establishes an access event type system and sets constraint mappings between event types and point role fields. The platform defines access event types as an enumerable set of business semantics and establishes trigger source mapping rules for each type of event. This is used to uniformly convert trigger signals from different sources, such as access control door opening, turnstile opening, door magnetic status changes, area entry, and crossing of warning lines, into corresponding event type identifiers, ensuring consistency of event semantics during the data entry phase. Based on the event type and point role fields, the platform limits the applicable scope of event types at different points. This applicable scope specifies the types of points where a particular event type can occur and the connections it can form with adjacent event types. The platform optimizes the combination of access links to reduce candidate interference caused by misuse of event types when they do not match the roles of the points. Based on this, the platform configures a set of candidate points and an associated time window template for each event type to facilitate cross-point association. The candidate point set is determined by the reachability relationship and direction constraints between points, while the associated time window template is derived from the configuration baseline of the access duration constraint. Different templates are allowed for different event types to match the differences in access links. The associated time window template generates a template version identifier and establishes an association with the point access relationship version, enabling the platform to reference the currently effective version as a constraint basis during subsequent candidate generation and confirmation, and to perform backtracking based on version after policy changes.

[0069] The platform encapsulates the location files and location role information, the access relationship versions between locations, the access duration constraint configuration baseline, the associated time window templates and their version relationships, as well as the platform's time base, offset maintenance rules, time health status rules, and event type mapping rules into a unified policy package and distributes it to the edge nodes or device side. The policy package contains a version identifier and an activation identifier. The device side uniformly marks the access events according to the policy package and reports them after binding them with the capture records. When the platform receives the data, it writes fields such as location number, event type, and unified timestamp based on this identifier.

[0070] S2: Each location captures a facial image when a passage event is triggered, and records the device identifier, timestamp, and collection condition label. The specific implementation is as follows:

[0071] Based on the aforementioned rule configuration, the system enters the stage of triggering capture and recording generation based on access events; each point takes the access event as the starting point for capture, and binds the capture result with the event type field for output, so that different points form an aligned event flow; access control points and turnstile points are mainly triggered by access events on the controller side, while points in open areas such as corridors and lobbies are mainly triggered by access events on the video side. The triggering criteria and event merging criteria for both types of points are executed according to the unified rules that have been issued.

[0072] At access control points or turnstile locations, the capture trigger signal is output by the access control controller, turnstile controller, or their linked peripherals. Upon receiving changes in door magnetic state, turnstile opening state, infrared beam state, and passage events output by the controller, the device side determines and merges the events according to the pre-configured trigger preconditions and event merging rules in the strategy package. The device side uses the ordered changes in the door or turnstile state sequence as the basis for determining the trigger link, merging continuous state changes belonging to the same passage process into the same event instance to avoid door rebound, personnel turning back, controller retransmission, or superposition of multiple signal sources causing the same passage to be split into multiple event instances. After trigger confirmation, the device side activates the trigger around the event instance. Image frames near the event time are extracted to form a candidate frame set, and key frames are output according to the key frame selection rules configured in the strategy package. The key frame selection rules are based on the face localization status, pose indication, occlusion indication, and sharpness indication that can be directly obtained from the device side. Frames with a pose closer to frontal, less occlusion, and higher sharpness are selected as output frames. When there are no frames in the candidate frame set that meet the key frame selection rules, the device side retains a multi-frame candidate set and binds it to the event instance for reporting, which is used for subsequent quality grading and multi-frame organization processing. The device side also records the trigger source category and state sequence summary, enabling the platform side to trace the trigger link and state evolution of the event instance for subsequent conflict explanation and review processing.

[0073] In open areas such as corridors and lobbies, snapshots are triggered by passage event detection on the video side. The device side sets virtual warning lines, area entry boundaries, or channel direction constraints according to the strategy package. When a target enters the detection area and meets the continuous tracking consistency constraint, snapshots are triggered. The continuous tracking consistency constraint is described by a combination of observable conditions, with at least the following criteria: the target tracking identifier remains valid, the triggering order of the entry boundary is consistent, and the channel direction remains continuous. The criteria are matched with the location role and channel direction attributes to avoid momentary false triggers caused by brief occlusion, camera shake, or shadow disturbances. For multiple triggers caused by the same target staying in the area, the device side merges the events according to the target tracking identifier, combining multiple triggers that can be regarded as the same passage process into the same event record. The keyframe and the necessary candidate frame set are output under this event record, so that the open area locations and access control locations are consistent in event record structure, snapshot output method, and field caliber, which facilitates subsequent cross-location time window retrieval and unified processing.

[0074] After each snapshot is triggered, the device generates a snapshot record and establishes a binding relationship with the captured image. The snapshot record is output using structured fields, including at least the location number, device identifier, event type, event instance identifier, trigger timestamp, image index information, and trigger source marker. The event instance identifier is generated by the device and reported along with the record. When the platform receives the data, it writes the original timestamp of the device, the platform-normalized timestamp, and the corresponding offset record identifier according to the aforementioned unified time base mechanism, and generates a platform-side event number for the event. At the same time, it establishes a correspondence between the platform-side event number and the event instance identifier, so that the event can be compared, sorted, and traced on the global timeline. To ensure the idempotency and global consistency of the data entry, the platform uses the combination of location number, device identifier, event instance identifier, and image index information as the idempotency merging basis. It performs unified mapping and merging on duplicate reports caused by retransmission and retries, ensuring that the same event instance corresponds to only one platform-side event number and avoiding duplicate records from entering the subsequent candidate generation process.

[0075] To ensure stable input for cross-location identity association under complex acquisition conditions, the system adds acquisition condition tags to each capture record, and the device and platform sides collaboratively generate a complete tag set. The device side generates real-time tags based on the captured image and target status. These real-time tags use enumerated semantics to describe the acquisition environment, covering categories such as lighting conditions, clarity, occlusion, motion, and congestion. For each type of tag, the system predefines a unified set of values ​​and generation rules, ensuring that different devices output consistent enumerated values ​​with the same meaning. The platform side then supplements scene tags by combining location files and operational status. Scene tags include indoor or outdoor attributes, lighting mode status, camera model or lens setting information, location role attributes, and traffic direction attributes, so that the tag set reflects both the device's real-time status and the scene's long-term attributes. The platform side maintains a tag dictionary, standardizing and mapping the original tags reported by the devices, converting manufacturer-defined fields into platform-unified fields, and retaining the original fields for auditing and compatibility expansion. This allows subsequent processing stages to directly perform consistency checks, candidate range pruning, and conflict reason explanations based on tag semantics.

[0076] During the process of storing captured images in the database, the system saves event records and image files separately and associates them through a unified index. Captured images are stored in object storage or edge cache, while captured images are stored in a structured database or event stream storage. The two are linked by location number, platform event number, and image index to facilitate end-to-end traceability. Considering network jitter or location offline situations, a cache queue is set up on the device side or edge node side: when the link is unstable, the captured images and their image indexes are cached first, and then retransmitted in the order of triggering after the link recovers. The retransmitted data carries both a trigger order marker and a retransmission batch marker. When the platform stores the data, it uses this to rearrange and merge the data according to the trigger order, avoiding omissions or disordered sequences in cross-location time window retrieval due to out-of-order storage, and retaining the retransmission link information to support subsequent audit traceability.

[0077] To facilitate subsequent quality grading and multi-frame observation organization, the device outputs frame set metadata corresponding to the event instance simultaneously when generating the capture record. The frame set metadata includes at least frame range markers, frame quantity markers, frame time coverage markers, and basic quality indicators for each frame. Based on this, the platform can directly organize the capture output into subsequent observation inputs without having to extract it from the original video. For devices that only support single-frame capture, the system enables an adjacent frame buffering mechanism at the edge nodes, briefly retaining video frames near the trigger time of the passage event and establishing an index association with the event instance identifier. In the subsequent processing stage, the platform can retrieve adjacent frames according to the event instance identifier, complete the candidate frame set, and form multi-frame observation inputs, thus maintaining a consistent data processing flow under the deployment conditions of heterogeneous devices.

[0078] Therefore, the captured records and images reported by each location are aggregated into a unified traffic event data stream on the platform side. This data stream contains event type information, normalized time information, acquisition condition labels, and frame set metadata, which facilitates subsequent quality classification of captured records and organization of multi-frame observation data.

[0079] S3: The captured data is graded for quality, and multiple observation sequences are organized according to time windows. The specific implementation is as follows:

[0080] After the captured events are entered into the database, the platform enters the quality grading and multi-frame observation sequence organization stage. The platform gives a quality level and corresponding basis fields for each captured record, and organizes related frames into multi-frame observation sequences with time boundaries according to the same common event, so that they can be retrieved and verified by sequence number later.

[0081] After receiving the captured data, the platform reads the acquisition condition label, frame set metadata, and image and detection status fields as input for quality assessment. The acquisition condition label reflects the acquisition environment and location scene conditions, while the image and detection status fields reflect observable states such as whether the face region is localizable, whether key parts are complete, whether occlusion and blurring are significant, and whether the pose is usable. The platform uses ordered enumeration of quality levels to classify the captured data, with at least four categories: high availability, medium availability, low availability, and unavailable. High availability is defined as a record where the pose is frontal or near-frontal with clear details, low occlusion, and stable lighting. Records that are considered acceptable if they are slightly blurred or have a deflected pose but still retain valid identification information; records that are considered acceptable if they have heavy occlusion, significant backlighting, or a small face area but still retain some usable information; records that are not acceptable if the face area cannot be stably located or the image is severely distorted; to ensure that different locations and different time periods use consistent criteria, the platform does not use a single numerical threshold for adjudication, but instead uses a state enumeration dictionary and a graded mapping table to make the judgment; the state enumeration dictionary is used to define the set of values ​​and semantic boundaries of each state field, and the graded mapping table is used to define the correspondence between state field combinations and quality levels, so that the graded conclusions are verifiable and reproducible;

[0082] To facilitate the review of quality grading results and support subsequent conflict explanations, the platform simultaneously writes the grading basis field when writing the quality grade and establishes a unique association with the corresponding capture record. The grading basis field records the key factors affecting usability and their discrete states in a structured state, including at least the face frame state, key point integrity state, occlusion state, blur state, brightness and backlight state, pose deflection state, and target motion state, and retains the source markers for each state field. Subsequently, when there is competition or controversy among candidates, the platform can use this to trace the specific reasons why the record was judged as low availability or unavailable. For records judged as unavailable, the platform still includes them in the timeline of the corresponding passable event, writes them into the sequence metadata in the form of placeholder frames when generating the observation sequence, only marks the unavailable state and does not include them in the main evidence frame set, so as to maintain the continuity of the event timeline and avoid the timeline break caused by deleting the record, which would affect the subsequent evidence alignment and supplementary frame extraction based on time boundaries.

[0083] After quality grading is completed, the platform manages the captured records in a queue according to location and event type, and sorts them into the corresponding time series queue according to the platform's unified timestamp. The platform then organizes multi-frame observation sequences according to the sequence observation window configuration table. The sequence observation window is used to define the observation range and frame retention criteria for the same passage event on the platform side, so that multiple frames of evidence for the same event can converge into a verifiable sequence. Correspondingly, the cross-location association time window is used for candidate matching between different locations. The candidate generation stage is carried out in this time window for retrieval and pruning. The sequence observation window configuration table configures the observation range and frame organization criteria with location role, event type and trigger source as retrieval conditions, and is consistent with the merging criteria of event instances, so that the sequence structure output by the same passage event under different device capabilities is consistent.

[0084] The platform employs a hierarchical merging rule when organizing observation sequences. First, using the platform-side event number as the primary key, capture records and their frame sets under the same event number are grouped into the same sequence. Second, when a capture record provides only a single keyframe or only a few frame indexes, the platform supplements adjacent frames or adjacent capture records within the range specified by the sequence observation window based on the frame set metadata and cached index fields, and merges and saves them with the sequence corresponding to that event. When the event number is missing or incomplete, the platform merges records according to location, event type, and sequence observation window rules, and uses trigger source markers, target tracking identifiers, channel direction attributes, and scene labels as consistency conditions to avoid misclassifying the brief entry of different personnel into the same sequence. For records already grouped into the same sequence, the platform retains the original index reference relationship, so that any frame in the sequence can be traced back to the corresponding capture record, image index, and label source.

[0085] During sequence construction, the platform employs a layered frame organization approach for different quality levels to enhance the stability of sequence evidence under complex acquisition conditions. Based on a frame retention rule table, the platform divides sequence frames into primary evidence frames and secondary evidence frames, and writes the indexes of both types of frames into the sequence metadata as structured fields. For highly available records, a small number of primary evidence frames are used as the main evidence, and redundant frames are restricted from entering the sequence. For moderately available records, adjacent frames are added as secondary evidence to the primary evidence frames to cover information gaps caused by attitude changes or temporary blurring. For low-availability records, frames before and after occlusion, changes in illumination, or changes in motion state are prioritized as secondary evidence, ensuring the sequence includes different observation states for subsequent comparison and conflict interpretation. For unavailable records, placeholder frames are written into the sequence timeline and marked as unavailable, maintaining timeline continuity and not included in the primary evidence frame set. This frame organization method does not rely on ambiguous descriptions of length or quantity, but rather follows the retention criteria and index writing criteria specified in the rule table, thus ensuring a unified and verifiable framework for the composition of primary and secondary evidence.

[0086] After generating a multi-frame observation sequence, the platform assigns a unique sequence number to each sequence and establishes a correspondence between this sequence number and the event number on the platform side and the event instance identifier on the device side, facilitating accurate location during cross-site retrieval, evidence package aggregation, and verification. The platform stores the sequence metadata in a structured database, with fields including at least the site number, event type, sequence start and end time markers, frame index list, frame time marker list, quality level and statistical information for each frame, main evidence frame index, auxiliary evidence frame index, and a collection condition label set. The collection condition label set is generated according to sequence-level aggregation rules, that is, merging and deduplicating the instant labels of each frame and the scene labels on the platform side, and retaining the source mark and retrospective reference for each type of label to support subsequent rapid trimming and conflict interpretation. The platform also saves the keyframe index, which is selected from the main evidence frame and auxiliary evidence frame according to priority, and is used to quickly extract the main and auxiliary evidence combination when aggregating the evidence package, avoiding traversing the entire frame set again.

[0087] To ensure the traceability and reproducibility of hierarchical and sequence organization standards, the platform incorporates the state enumeration dictionary, hierarchical mapping table, sequence observation window configuration table, and frame retention rule table into the strategy package as configuration entries, and sets a version number for the strategy package. When generating and writing sequence numbers, the platform simultaneously writes rule version references, so that each sequence can correspond to the hierarchical rules, observation boundary rules, and frame organization rules used when it was generated. When the strategy package version is updated and the standards are adjusted, newly generated sequences reference the new version, while existing sequences retain the original version. Subsequent candidate generation and review can be carried out by repeatedly searching for the same standards or comparing differences according to the version reference, in order to support long-term interpretation and auditing.

[0088] Therefore, the platform generates multi-frame observation sequences that can be queued and retrieved by location and event type, and provides the sequence number and its metadata to the next stage for filtering matching sequences and aggregating evidence packages within the cross-location associated time window.

[0089] S4: Generate cross-location candidate association pairs based on location topology and associated time windows, and aggregate multi-frame observation sequences and acquisition condition labels into an evidence package. The specific implementation is as follows:

[0090] After the multi-frame observation sequence was entered into the database in the previous step, the platform entered the process of generating cross-site candidate association pairs. Based on the configuration of site access relationships, event type constraint mapping, cross-site association time window template and acquisition condition compatibility rules, candidate sequence pairs were selected for each observation sequence. Subsequently, the platform aggregated the primary evidence index and secondary evidence index, time matching mark, access path reference information and rule hit records at both ends of the candidate sequence pairs into a unified evidence package.

[0091] The platform first completes the location and direction marking of newly added observation sequences. The platform reads the location number, event type, time interval, quality level distribution, collection condition label set, and main evidence frame index and auxiliary evidence frame index from the sequence metadata. Combined with the channel direction attribute and event type direction semantics in the location file, the platform generates a direction marking to represent the directional relationship of the sequence in the passage. Candidate retrieval and sorting use the platform's normalized time field as the unified time standard. For sequences with supplementary transmission markings or time health anomaly markings, the platform participates in matching based on the time correction field and the order correction field, and writes the supplementary transmission information, time health status, and correction source marking into the candidate pair metadata and evidence package as the basis for subsequent explanation of the reasons for candidate formation and the source of uncertainty.

[0092] The platform generates a candidate point range according to path range rules. These rules are fixed in the form of enumerated entries, used to limit the allowed path categories and reachable range categories for candidate expansion, and to clarify the corresponding accessibility retrieval criteria. Based on these rule entries, the platform extracts reachable points from the point accessibility configuration, forming a candidate point set. This candidate point set is then divided into an upstream candidate point set and a downstream candidate point set, based on the accessibility direction markers. The upstream set retrieves sequences that appear before the current sequence and are reachable from the current point, while the downstream set retrieves sequences that appear after the current sequence and are reachable from the current point. If the accessibility direction markers are inconsistent with the direction constraints in the accessibility configuration, the platform does not generate a candidate set for that direction and records the reason for the inconsistency in the audit log to exclude opposite-direction access behaviors from entering the candidate range. The platform also records the path range rule entry number, the accessibility configuration version reference, and the current candidate range identifier as a reference for candidate generation, facilitating subsequent verification of the candidate range's source.

[0093] After the candidate point range is determined, the platform performs semantic compatibility filtering on the candidate points based on the event type constraint mapping table. The event type constraint mapping table is maintained in the form of configuration entries, which is used to limit the range of points that can participate in candidate generation under different point roles and traffic directions for each event type. The platform performs filtering on the upstream candidate point set and the downstream candidate point set respectively, removes points that do not match the current event type, and writes the matching mapping entry number and filtering result mark into the reference information of the candidate pair, which is convenient for subsequent tracing of the basis for limiting the candidate range and explaining the risk of cross-regional cross-traffic.

[0094] After the candidate point set is determined, the platform enters the cross-point association time window retrieval stage. Using the time interval of the current observation sequence as a benchmark, the platform calls the cross-point association time window template to generate retrieval time boundaries and retrieves time-matching candidate sequences from the sequence queues corresponding to the upstream and downstream candidate points, thus forming candidate association pairs. The platform writes a time-matching tightness enumeration flag for each candidate association pair. This enumeration flag is derived from both the time window template entry and the travel duration constraint baseline entry, and is used to characterize the degree of fit between the candidate pair's time interval and the travel link's time caliber. The platform also records the time window template entry number, the travel duration baseline entry number, and the landing point category of the candidate pair's time interval referenced by the tightness enumeration flag, so that the same time caliber can be reused to replay the retrieval process during subsequent sorting, confirmation, and verification, and to explain whether the candidate pair belongs to a typical link candidate or a boundary link candidate.

[0095] When generating candidate pairs, the platform performs collection condition compatibility verification and direction consistency verification on the sequences at both ends of the candidate pair to constrain the candidate range and form a traceable pruning basis. The collection condition compatibility verification is driven by a compatibility rule entry table. The rule entries are fixed by the trigger conditions and disposal types of the tag combinations. The disposal types include at least retention, deweighting, and elimination. The platform verifies the collection condition tag set of the sequences at both ends of the candidate pair. When a rule entry is matched, a compatibility tag is generated, and the triggered rule entry number and disposal type are recorded in the candidate pair metadata and evidence package. For deweighting disposal, the platform reflects the deweighting result at least in the stratification or sorting of the candidate pool. The platform records the reason for the downgrade; for removal, it records the reason for removal and retains the audit entry so that the rule basis for the candidate pair not entering the candidate pool can be traced later; the direction consistency verification is based on the direction constraints in the configuration of the travel direction mark and the reachability relationship of the point. When the direction of the candidate path does not meet the direction relationship of the two-end sequence, the platform does not generate the candidate pair and retains the audit entry for the reason for not generating it, so as to avoid the point round trip or reverse travel being mistakenly connected as a continuous link; for the candidate pairs that are still retained but have the risk of conflict in the collection conditions, the platform writes the source of the conflict risk into the evidence package in the form of a mark, so that it can be directly referenced and the conflict type can be registered in the subsequent hierarchical confirmation;

[0096] When a candidate sequence simultaneously satisfies the constraints of travel relationship, event type, associated time window, and collection condition compatibility, the platform generates candidate association pairs for the two end sequences and generates corresponding evidence packages. The evidence package is stored using a unified field structure, including the candidate pair number, the sequence numbers of both ends, the point numbers of both ends, the event types of both ends, the time intervals of both ends, the main evidence frame index and the auxiliary evidence frame index, the quality level distribution, the collection condition label set, the time matching tightness enumeration flag and its reference entries, the compatibility flag and its trigger rule entries and disposal type, as well as the travel path description and rule reference list. The travel path description is used to identify the path category and direction source between the two end points, making it easy to trace why the candidate pair was included in the candidate range during review. The rule reference list is used to record the path range rule entries, event type constraint mapping entries, time window template entries, travel duration baseline entries, and compatibility rule entries, enabling the evidence package to directly locate the rule system on which the candidate generation is based during offline review or rule backtracking.

[0097] To adapt to external uncertainties in real-world scenarios, the platform allows the attachment of contextual evidence information to the evidence package. This contextual evidence information records the environment and operational status at the time of candidate pair generation, including at least dense crowd markers, congested passage markers, equipment malfunction markers, retransmission markers, time health markers, and maintenance annotation markers. It also identifies the source of each record to distinguish between location-side reporting, platform-side statistics, and maintenance-side annotations. This contextual evidence information is used to explain that candidate uncertainty may stem from factors such as dense crowd obstruction, equipment malfunction, time drift, or out-of-order retransmission when multiple candidate competition or misassociation disputes occur. It also provides a citationable basis for conflict type registration and verification during conflict triage.

[0098] After the evidence package enters the candidate pool, the platform sorts and stratifies the candidate pairs according to the type of travel path, the tightness of time matching, the quality combination characteristics, and the compatibility handling results. The platform then delivers the stratified candidate pool to the next stage for graded confirmation and conflict diversion, and retains the sorting basis and handling marks for review and explanation.

[0099] S5: Perform hierarchical confirmation and conflict triage on candidate association pairs, transferring conflict records to secondary confirmation and registering conflict types. The specific implementation is as follows:

[0100] After the candidate pool and evidence package are generated, the platform conducts hierarchical confirmation and conflict diversion of candidate associations. It adopts a process of first screening according to rules and then reviewing and assigning, resulting in three types of output: confirmed results, pending confirmation results, and unconfirmed results. The conflict type and corresponding supplementary evidence category are recorded simultaneously for pending confirmation results for subsequent review, retrieval, and processing.

[0101] The platform first performs a consistency check on each evidence package in the candidate pool. The consistency check is based on the references to the travel path relationships and their direction constraints, time matching references, event type constraint hit information, quality evidence index information, and collection condition handling marks recorded in the evidence package. No external inference is introduced during the check. The time consistency check is used to determine whether the time interval between the two sequences of the candidate pair falls within the time boundary defined by the associated time window template. The platform reads the time window template entries and travel duration constraint baseline entries referenced in the evidence package, and combines them with the time matching tightness enumeration marks of the candidate pair and their reference relationships to form a consistency check. Verification conclusions: When evidence package records are re-uploaded or time health anomalies are marked, the platform synchronously writes a time-normalized source reference into the verification record to avoid verification deviations caused by mixing different reference time fields; the travel path consistency verification is used to determine whether there is a travel path relationship between the two ends of the candidate pair that is consistent with the directional relationship of the candidate pair. The platform verifies whether the travel path category and directional constraint reference recorded in the evidence package are still valid, and checks the compatibility between the travel relationship configuration version referenced and the version referenced when the candidate was generated, to prevent the candidate from being misjudged as reachable after the travel relationship configuration version is switched or the point role is adjusted and the invalid path is still used.

[0102] Event type consistency verification is used to determine whether the event types at both ends constitute a connectable semantic link in the event type constraint mapping. The platform verifies the constraint hit entries recorded in the evidence package, the event direction markers at both ends, and the point role adaptation markers to avoid events with opposite directions or incompatible semantics being spliced ​​into the same link. Quality availability consistency verification is used to determine whether the sequences at both ends of the candidate pair have evidence that can be used for judgment. The platform reads the keyframe index and quality level distribution of the sequences at both ends, where the main evidence frame is directly indicated by the keyframe index field. When both ends have main evidence frames, the quality availability verification is marked as passed and proceeds to subsequent grading. When one end is missing a main evidence frame, it is only used when it has a set of replaceable auxiliary evidence frames that have not been covered by the elimination class collection condition processing. In certain circumstances, the quality availability verification is marked as requiring attention and proceeds to subsequent grading. The substitutability of the supporting evidence frame set is determined by the rule entries and the reference of the hit entries is written into the verification record. The supporting evidence set must be non-empty and contain at least one available frame. When both ends lack available frames or both ends are covered by the elimination class, resulting in unusable evidence, the quality availability verification is marked as failing and directly proceeds to the non-confirmation process. The platform writes all the above verification results into the verification record field. The verification record field uses an enumeration method to express the three states of verification pass, verification fail, and verification requiring attention. It also records the reason category for triggering the state, the reference relationship of the hit rule entries, and the corresponding evidence field index, so that subsequent processing and review can be completed without reinterpreting the verification basis.

[0103] After completing the consistency verification, the platform performs tiered confirmation on candidate association pairs that have passed verification or are marked as requiring attention. Tiered confirmation, based on evidence stability and candidate competition, categorizes candidate association pairs into direct confirmation, pending confirmation, and non-confirmation levels, generating an executable disposal queue. The platform first establishes candidate competition relationships, aggregating candidate sets corresponding to the same upstream or downstream observation sequence within the associated time window, and generating a competition set identifier for each candidate set. The platform then writes the competition set identifier, along with the candidate pool stratification results, ranking key references, and verification records, into the tiered record, ensuring that candidates entering secondary confirmation are disposed of as a whole competition set, rather than individually. Individual candidates are processed in isolation. The platform adopts a rule of exclusion followed by judgment to determine the direct confirmation level: when a candidate association pair does not have a competing set, does not hit the downgraded or attention-required collection condition handling flag, and its time matching tightness and travel path category are in the priority level of the candidate pool, and both ends of the observation sequence have main evidence frames with usable or higher evidence as the main body, and the compatibility handling result does not trigger high-risk conflict flags such as occlusion or backlighting, the candidate association pair is judged to be of the direct confirmation level; the direct confirmation level emphasizes that the candidate is consistent in travel path relationship, time matching, quality evidence and collection condition handling, and there is no ambiguity caused by competing candidates, thus entering the subsequent registration process;

[0104] When a candidate pair has a competing set or insufficient evidence stability, the platform classifies the candidate pair into the pending confirmation level and enters the conflict diversion process. The competing set refers to the same upstream sequence corresponding to multiple downstream sequences within the associated time range, or the same downstream sequence corresponding to multiple upstream sequences, and each candidate pair is difficult to form a clear advantage in terms of time matching tightness or common path relationship category. Insufficient evidence stability includes asymmetrical quality distribution at both ends, low availability frames accounting for the majority, missing main evidence frames or mainly relying on auxiliary evidence frames, collection condition processing results of downgrading or needing attention, collection condition labels indicating occlusion or backlighting in a high-risk state, and contextual evidence indicating dense or crowded personnel occlusion leading to increased uncertainty. When the platform completes the pending confirmation level determination, it writes the competing set identifier, the verification record entries that trigger uncertainty, the candidate pool layering mark, and the ranking key item reference into the diversion record so that the secondary confirmation is based on the overall selection of the competing set, avoiding the initial confirmation of a single candidate and subsequent regression after supplementary evidence is added, which may cause identity confusion.

[0105] When a candidate pair has an unacceptable hard conflict, the platform classifies it as unconfirmed and does not include it in the secondary confirmation queue. Hard conflicts include: invalid references to the travel path relationship between the two ends of the candidate pair or inconsistent travel direction constraints; invalid time matching references for the candidate pair and their time intervals do not fall within the boundaries of the associated time window; unmatched constraint mappings of the event types at both ends or conflicting travel semantic directions; both sequences lack available frames or are covered by the rejection-type collection conditions, resulting in unusable evidence. The platform retains audit records for unconfirmed candidate objects. The audit records include the evidence package number, the failed verification items and their reason categories, the reference relationships of the hit rule entries, and the corresponding evidence field indexes. These records are used for subsequent rule optimization and post-event traceability, but the candidate pair is not included in the input set for subsequent identity relationship writing.

[0106] For candidates at the direct confirmation level, the platform performs registration processing. The platform uses the evidence package number as a unique index to write the same identity association of the candidate pair into the confirmation result table, and at the same time writes the corresponding verification conclusion, hierarchical mark, candidate competition set identifier, and candidate pool stratification and sorting basis reference, so that the subsequent identity relationship writing process can directly retrieve the confirmation result by evidence package number without having to traverse the candidate pool again. After registration, the platform marks the candidate pair as processed in the candidate pool and solidifies and locks its verification record and rule reference information to avoid duplicate entry into the database or changes in the judgment criteria for the same candidate due to policy version adjustments.

[0107] For candidates awaiting confirmation, the platform performs conflict triage and includes them in the secondary confirmation queue. Conflict triage is based on the typological characterization of the source of uncertainty. The platform registers the conflict type upon enqueueing and simultaneously associates the verification record entries and corresponding evidence field indexes that trigger that conflict type, enabling the source of the conflict to be directly located and displayed. Conflict types are described using an enumerable and configurable set of types, covering situations such as multi-candidate competition, insufficient quality, high risk of occlusion, high risk of backlighting, congestion and occlusion, equipment time drift or abnormal retransmission order, and inconsistent handling of collection conditions. The platform maintains the correspondence between conflict types and supplementary evidence categories through a configurable mapping table, and limits the scope of application according to location role, event type, and travel path category. Each adjustment to the mapping table generates a new version and records the reason for the change, ensuring that the handling criteria for secondary confirmation can continuously evolve and be traceable. Currently, the platform binds supplementary evidence category lists and evidence display scope templates for different conflict types. When entering the review stage after secondary confirmation, the corresponding evidence supplementation interface is called according to the registered type, and the display content is organized according to the template, eliminating the need to temporarily define the evidence scope during the review stage. Supplementary evidence categories include at least extending the time range to obtain supplementary frames, retrieving auxiliary sequences from adjacent points to complete the access link, reading the access event logs of access control or gate controllers as external corroboration, and reading the status logs of point devices to explain anomalies such as time drift or out-of-order transmission. When registering for entry, the platform only fixes the conflict type, supplementary evidence category list, competition set identifier, verification record item reference, and evidence display scope template reference, so that subsequent review can directly locate the main evidence frame, auxiliary evidence frame, quality basis field, and context evidence field, and complete the review process under a unified standard.

[0108] Through the aforementioned tiered confirmation and conflict triage, the platform outputs three types of processing results: a confirmed result set that can be directly used for subsequent identity relationship writing, a pending confirmation result set transferred to the secondary confirmation queue, and a non-confirmed result set used for auditing and rule optimization. Each result item is associated with an evidence package number and records the tiered label or conflict type label and its corresponding rule entry reference information. The above processing results serve as the input basis for the next stage of identity relationship writing and incremental association, enabling subsequent processing to be traced and reviewed based on a unified evidence structure and rule reference relationship.

[0109] S6: Confirmed relationships are written into the versioned identity relationship graph. Subsequent records are associated incrementally according to the latest version. Unconfirmed records are entered into a pending review phase and invalidation conditions are set. The specific implementation is as follows:

[0110] After completing the hierarchical confirmation, the platform only includes the confirmed relationships in the writing scope and summarizes them into batches according to the confirmation results to form change sets to be written. The platform first performs a pre-write consistency check on the change sets to be written. Change sets that pass the check are submitted to the database and a new graph version number is generated as the current effective version. Change sets that fail the check or fail to write are not included in the effective version and are not available for external query. The effective version is uniformly bound to the version of the referenced access path relationship configuration, the version of the associated time window template, and the version of the event type mapping. At the same time, the batch boundary and the evidence package range are recorded for subsequent backtracking and positioning.

[0111] The identity relationship graph uses a unified data structure to express the attribution relationship between personnel identities and observation sequences, and records the basis for the formation of this attribution relationship. Personnel identity nodes are used to carry unified identity identifiers across locations and time periods, have unique identifiers, and maintain an operational status field, which indicates whether the identity is in use, at risk of merging, or pending review. Observation sequence nodes use sequence numbers as unique identifiers and store location numbers, event types, start and end timestamps, quality grading results, collection condition label sets, and evidence package reference information associated with the sequence. The platform only sets attribution edges in the graph to express the factual relationship that the observation sequence belongs to a certain personnel identity, ensuring that the attribution semantics are described using a single caliber. At the same time, evidence reference edges are set to record the evidence package number, confirmation level, confirmation source mark, confirmation timestamp, and corresponding rule entry reference information on which this attribution establishment or link extension is based. Evidence reference edges are only used to carry the basis for formation and are not used to express attribution semantics, thereby avoiding the repetition of the same semantics and causing interpretation ambiguity. The platform uses a unified traceable field set for attribution edges and evidence reference edges, so that any write relationship can be traced back to the corresponding evidence package, rule entry, and its version context at the time of formation.

[0112] When a candidate association is confirmed as a writable relationship, the platform first reads the attribution status of both observation sequences in the current effective version and performs write processing according to the attribution status to distinguish between chain establishment, chain expansion, and potential merging risks. If neither observation sequence belongs to any identity node, the platform creates a new identity node and establishes the attribution relationship between this identity node and the nodes of both observation sequences, while simultaneously writing the evidence citation relationship to record the basis for the establishment of the identity chain. When creating a new identity node, the initial status field of the identity node is written synchronously to distinguish between newly created identities and continuously maintained identities. If only one observation sequence belongs to an identity node while the other does not, the platform does not directly attach the unattributed sequence, but first performs an identity node competition check: the platform combines the confirmation result with the existing relationships in the current effective version to extract the set of candidate identities related to the unattributed sequence and their conflict markers. When an unattributed sequence points to only a single identity node under the same processing caliber and there are no registered competition or merging risk markers, the platform will assign the unattributed sequence to a new identity node. The platform attaches the sequence to the identity node and writes the corresponding evidence reference relationship. When an unassigned sequence points to multiple identity nodes, or points to a single identity node but is marked as a conflict requiring review, the platform does not perform the attachment. Instead, it registers it as an identity node competition conflict and transfers it to the secondary confirmation queue. The registration information includes at least the identity node set identifier, the evidence package number that triggered the conflict, the conflict type marker, and the rule entry reference information to support subsequent overall review by competition set. If the two observed sequences belong to different identity nodes, the platform does not perform identity node merging or migrate existing attribution relationships at this stage. Instead, it registers it as an identity merging conflict and transfers it to the secondary confirmation queue. The registration information includes at least the two identity node identifiers, the evidence package number that triggered the conflict, the conflict type marker, and the rule entry reference information to avoid the identity chain being incorrectly merged due to a single confirmation error. The platform records the above processing process and writes the previous state category and processing branch marker so that it can be clearly identified during subsequent backtracking as the attribution relationship was generated in the case of chain establishment, chain expansion, or conflict isolation.

[0113] To ensure the version generation process is transparent, fully implemented, and feasible, the platform performs consistency checks on the change set to be submitted before generating the effective version, and solidifies each check item into configurable and traceable rule entries. The platform performs at least the following checks: sequence uniqueness check to confirm that the same sequence node corresponds to only one ownership relationship within the same effective version; reference integrity check to confirm that the evidence package number, rule entry reference, and version metadata reference bound to the ownership relationship to be written and the evidence reference relationship can be parsed and traced back; conflict isolation check to confirm that relationships registered as identity node competition conflicts or identity merging conflicts will not enter the effective version; and version reference consistency check to confirm that the version metadata referenced in this submission is consistent within the batch and consistent with each relationship record in the change set to be submitted. The platform outputs an enumerated result status for each check and simultaneously records the trigger reason category and corresponding reference information, ensuring that the version generation process has an auditable check track, rather than simply providing a success or failure conclusion.

[0114] The platform uses a combination of append-only change records and version indexes to store the identity relationship graph: In the storage layer, corresponding change records and version metadata are saved for each version; in the query layer, the version index is used to locate the currently effective version, and the platform supports rebuilding the identity relationship status under a specified version. When corrections or replacements of relationships are needed, the platform does not overwrite historical records but generates a new version. In the new version, the platform performs revocation, replacement, or migration operations on the specified attribution relationship, and writes the correction reason category, trigger source reference, evidence package reference corresponding to the revoked or replaced relationship, and rule entry reference information on which the correction is based into the correction record, making the correction process itself a traceable change chain. The corrected version is also associated with the access path relationship configuration referenced when it took effect, the associated time window template, and event type mapping, etc., facilitating subsequent comparison, backtracking, and auditing of differences before and after correction by version.

[0115] After the identity relationship graph is generated and in its effective version, the platform uses the current effective version as the basis for subsequent incremental associations. Whenever a new observation sequence is added to the database, the platform uses the candidate pool formed in the previous stage as the attachment input, and extracts the identity nodes to which each candidate sequence belongs from the candidate pool, summarizing them to form an identity node candidate set. The platform makes attachment decisions with identity nodes as the aggregation center, avoiding boundless expansion based solely on local matching relationships between sequences. Incremental attachments use the existing hierarchical confirmation criteria and reference the same set of rule entries, without introducing new judgment standards, ensuring that new attachments and historical confirmations are interpreted consistently under the same rule reference relationship. The identity node candidate set contains only one identity node, and the candidate relationship between this identity node and the new sequence is marked in the candidate pool as directly writable and without any conflict requiring verification. When a new sequence is marked, the platform attaches it to the identity node and generates a new version. It also writes an evidence reference edge to bind the candidate evidence package number, rule entry reference, and version metadata reference. When the candidate set of identity nodes contains multiple identity nodes, or when the candidate relationship is marked as a conflict requiring review, the platform does not perform the attachment. Instead, it registers the candidate relationship related to the new sequence as an identity node competition conflict and transfers it to the secondary confirmation queue. This ensures that the review is carried out around the competing identity set, avoiding identity cross-linking caused by erroneous attachment. When there is no attributable identity node in the candidate pool and the new sequence cannot form a stable writable candidate, the platform does not force the creation of a new identity node. Instead, it includes the new sequence in the pool to be reviewed and binds the rule entry reference and version metadata reference when it enters the pool. This ensures that the new sequence remains in a traceable waiting state even when there is insufficient evidence.

[0116] For candidate relationships not deemed writable, and those deemed requiring review during incremental attachment, the platform employs a centralized review pool. This pool uses the evidence package number as its primary index, recording the observation sequence identifiers, conflict type markers, quality grading criteria fields, collection condition label sets, contextual evidence fields, and category reference information for required supplementary evidence at both ends of the candidate pair. This allows subsequent reviews to be conducted directly based on the existing evidence structure. To prevent the pool from accumulating, the platform sets failure conditions and records their source and associated versions using traceable failure rule identifiers. When a record is added to the pool, it is bound to the currently effective failure rule identifier. Subsequent rule adjustments only apply to newly added records; historical records are executed according to their bound rules or enter a re-evaluation queue. Failure conditions... The system employs logical constraints and publicly discloses the triggering criteria: when a record pending review fails to receive the required evidence for an extended period under the bound retention rules and does not enter the review process, retention is invalidated and the record is archived; when stronger, alternative evidence appears on the same access link or at the same location and meets the substitution rules, substitution is invalidated. The substitution determination is based on interpretable comparisons of the quality grading results, keyframe index status, risk tags, and time matching markers in the sequence metadata, and the evidence references and reasons for invalidation of the substituted record are retained simultaneously; when changes in the location connectivity configuration cause the original candidate path to no longer be valid, path invalidation is triggered and the record enters a re-queue for review or becomes invalid directly; the platform retains the invalidation reason category, the version reference corresponding to the trigger time, and rule reference information for records that have been invalidated to support subsequent auditing and rule optimization.

[0117] Through this step, the platform solidifies the attribution relationship between personnel identity nodes and observation sequence nodes in the effective identity relationship graph version, and associates the corresponding evidence package number and rule entry reference information with each written relationship; relationships with identity node competition or that may trigger identity merging are not included in the effective version but are transferred to the secondary confirmation queue; unconfirmed relationships are included in the pending review pool, and are archived or re-queued for review according to the invalidation rules, so that subsequent new observation sequences are all attached based on the latest effective version and continuously updated according to a unified writing entry standard.

[0118] In one embodiment, the platform is used for security management of multiple cameras in a park. First, it establishes unified files for each camera location and defines the access path relationships between locations, forming a referable access relationship configuration. Simultaneously, it establishes a unified time base, maintains device time offset records and time health status, and configures access event types, the correspondence between events and location roles, and cross-location associated time window templates. When an access event is triggered, each location captures a facial image, generates a structured event record, and attaches acquisition condition tags and frame set metadata. When the platform stores the data, it performs time normalization, deduplication, and sequence correction. Subsequently, the platform performs quality grading on the captured records and saves the grading criteria. The system organizes the same passage process into a multi-frame observation sequence that can be queued and retrieved. Then, under the constraints of passage relationship and associated time window, it retrieves matching sequences of adjacent points to generate candidate association pairs. The main and auxiliary evidence, labels and rule references of the two sequences are aggregated to form an evidence package and included in the candidate pool. After the platform performs consistency verification on the candidate pairs, it performs hierarchical confirmation and conflict diversion to form a confirmed result set, a pending confirmation result set and an unconfirmed result set. Finally, the confirmed relationship is written into the identity relationship graph according to the version and associated with the configuration version. Subsequent newly added sequences are incrementally attached according to the latest version. Unconfirmed records enter the pending review pool and are converged in a controlled manner according to the failure rules to support traceable and error-correctable continuous identity association.

[0119] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0120] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0121] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0122] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0123] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] In addition, the functional modules in the embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0125] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0126] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0127] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A security management method based on facial recognition, characterized in that, include: S1: Establish the camera location topology and unify the time base, and configure cross-location association time windows and access event types; S2: Each location captures a face image when a passage event is triggered, and records the device identifier, timestamp, and collection condition label; S3: Read the acquisition condition labels, frame set metadata, and image detection status. Determine the quality level of the captured record based on the state enumeration dictionary and the hierarchical mapping table, and write the quality level, hierarchical basis field, and source marker into the record. Frames corresponding to unavailable records are treated as placeholder frames and included in the passage event timeline. Capture records are enqueued by location and event type and sorted by unified timestamp. Multiple frame records are merged by observation window and platform event number. When the event number is missing, it is merged by combining trigger source, target tracking, channel direction, and scene label. Write the main and auxiliary indexes according to the frame retention rules, aggregate sequence labels and retain the source, generate sequence number associated with platform event number and device event instance identifier, and write the rule version. The state enumeration dictionary defines the value set and semantic boundary of each state field, and the hierarchical mapping table defines the correspondence between state field combinations and quality levels. For highly available records, a small number of main evidence frames are used as the main evidence and redundant frames are restricted from entering the sequence. For moderately available records, neighboring frames are supplemented as auxiliary evidence based on the main evidence frames. For low-availability records, frames before and after occlusion, before and after changes in illumination, or before and after changes in motion state are prioritized as auxiliary evidence. S4: Generate cross-point candidate association pairs based on point topology and associated time windows. Retrieve candidate sequence pairs in upstream and downstream queues according to the associated time window template entries, and write the time matching tightness mark and the corresponding template entries and the passage time baseline entries. Based on the collection condition compatibility rule entries, retain, downweight or eliminate candidate sequence pairs and record the rule references. The system aggregates sequence identifiers from both ends, location and event type, time interval, primary and secondary evidence indexes, tag set, path references, and context source identifiers to generate an evidence package. It is then layered according to preset sorting items. Candidate sequence pairs are retrieved in upstream and downstream queues based on associated time window template entries, and time matching tightness markers and corresponding template entries and baseline entries for passage duration are written. Candidate sequence pairs are retained, down-weighted, or eliminated according to collection condition compatibility rules, and the rule references are recorded. The evidence package is generated by aggregating the sequence identifiers from both ends, location and event type, time interval, primary and secondary evidence indexes, tag set, path reference and context source identifier, and is layered according to preset sorting items; S5: Generate a competition set identifier by aggregating candidates from the same upstream or downstream sequence, and determine whether to directly confirm, pending confirmation, or not confirm based on the verification record; For those directly confirmed, register the confirmation record with the evidence package number and lock the verification and rule reference; For those pending confirmation, register the conflict type and associate the trigger item, evidence index, competition set identifier, mapping table version, and display template for secondary confirmation; For those not confirmed, register the audit item, and the platform outputs three types of handling results, transferring the conflict record to secondary confirmation and registering the conflict type; S6: Confirm the relationship and write it into the versioned identity relationship graph. Subsequent records will be associated incrementally according to the latest version. Unconfirmed records will be entered into the pending review and invalidation conditions will be set.

2. The security management method based on face recognition according to claim 1, characterized in that, Establish a camera location topology and unify the time base, configure cross-location associated time windows and access event types, including: Establish point files and set point roles, construct point access relationships, record branch and area / floor adjacency, generate relationship versions and duration baseline versions, and derive associated time window template versions; The platform clock calibration maintains the offset effect record, time health and retransmission sequence mark, and the original timestamp, normalized timestamp and offset identifier are recorded in the database. The strategy package is issued based on the event type and subject to the role of the location. After the event record is marked, it is reported into the database.

3. The security management method based on face recognition according to claim 1, characterized in that, Each location captures a facial image when a passage event is triggered, and records the device identifier, timestamp, and collection condition tags, including: Access control or turnstile locations are merged into events according to the controller state sequence and key frames or candidate frames are output. Open areas are continuously tracked and triggered by targets and their events are merged. The snapshot record is written with the location number, event type, image index and sequence mark, and the database is written with double timestamps, offset identifiers and deduplication and rearrangement. The data collection condition labels are converted into platform-unified fields and values ​​according to a preset comparison relationship, and the records and images are stored separately. Output frame metadata; for a single-frame device, it is padded by the buffer of adjacent frames at the edge.

4. The security management method based on face recognition according to claim 1, characterized in that, Based on the location topology and associated time windows, cross-location candidate association pairs are generated, including: For the observation sequence, determine the location and direction of travel, extract reachable points based on the path range rule entries and travel relationship versions, and divide the upstream candidate set and the downstream candidate set; For retransmission sequences or sequences with time health anomalies, candidate matching is performed based on the time correction field and the order correction field, and the source of correction is recorded. Semantic filtering is performed on the mapping entries based on event type constraints. If the directions are inconsistent, no candidates are generated and an audit record is registered.

5. The security management method based on face recognition according to claim 1, characterized in that, Confirmed relationships are written into the versioned identity relationship graph. Subsequent records are associated incrementally according to the latest version. Unconfirmed records are entered into a pending review phase with expiration conditions set, including: The confirmed relationships are summarized into change sets in batches and appended to the generated effective version after consistency verification, and associated with the versions of the access relationships, time windows, and event type rules; Establish or expand chains based on sequence ownership status; relationships with competition or merger risks are transferred to secondary confirmation. New sequences are added incrementally according to the effective version, and unconfirmed relationships are entered into the pending review pool according to the evidence package number and handled according to the invalidation rules.

Images