Local talent pool and cloud collaborative resume retrieval method and system

Abstract

The application discloses a local talent pool and cloud cooperative resume retrieval method and system. Two ends form a comparable handle with a same random binding token as a key; the local first sends a verifiable range expression, the server and the independent authorization range take an intersection, the authorized epoch, the authorized context digest and the set commitment are associated with the effective retrieval range and the version and returned after the identified confirmation, and the local only sends the intersection member projection. The server calculates the current authorized context digest before the retrieval, calculates the current authorized context digest before the capsule formation after the hit, and compares with the effective range binding digest; the capsule digest field is recalculated and compared again before the candidate operation, and any point failure closes the corresponding action. After that, the local executes the original and evidence three-level closure, and adopts a recoverable submission protocol according to the side effect type.

Description

Technical Field

[0001] This invention relates to the fields of computer data processing, distributed retrieval, and access control technology, and in particular to a method and system for retrieving resumes in a local talent pool and in a cloud-based collaborative manner. Background Technology

[0002] Resume files stored by recruiters may be distributed across multiple managed directories on local electronic devices, and file types may include portable document formats, word processing files, spreadsheet files, and image files. Cloud servers are suitable for performing structured searches, keyword searches, vector searches, graph relation searches, or language model semantic searches. Local file management and cloud computing thus form a cross-device data processing chain.

[0003] In this cross-device data processing chain, the candidate set that can be retrieved in the cloud should not be declared solely by the local device. Whether the original resume still exists locally, whether it belongs to the selected talent pool, and whether it is still readable are two independent and potentially changing constraints, as well as whether the accessing entity has the right to process the corresponding candidate on the server side.

[0004] If the server directly accepts the candidate identifier set uploaded by the local device as the basis for authorization, candidate data that has been removed from the talent pool, belongs to other access subjects, or is in an expired generation of the talent pool may be included in the retrieval process. Conversely, if the server determines the candidate set only based on the authorization records in the cloud, and cannot prove that the corresponding original document can still be parsed and opened by the local device when performing candidate operations.

[0005] Resume search results also have source revision dependencies. After the server returns the results, the original local resume may be deleted, replaced, modified, or moved, and access permissions may also change between the generation of the results and the retrieval of the original. Simply saving candidate identifiers or relevance scores cannot determine whether the evidence on which the matching criteria are based can still be located in the existing original.

[0006] Different actions performed on the same candidate may have varying requirements for original documents and evidence. For example, displaying a candidate's hit description, opening the original resume, adding the candidate to the candidate list, exporting materials, generating a report, and sending materials may each require different sets of evidence. Simply marking candidates as available or unavailable does not provide sophisticated technical gating for these actions.

[0007] Some solutions expand the search scope or switch to other sources when the file is unavailable or the candidate set is empty. However, the expanded dataset may not simultaneously satisfy the local existence constraint and the server authorization constraint, thus changing the data processing boundary of the original recruitment search task.

[0008] Therefore, a data processing mechanism is needed across local electronic devices and servers, so that cloud-based AI resume retrieval only operates on the valid intersection of constraints between the two parties, and that each result can be reclosed to evidence with the appropriate permissions and revisions before performing operations that depend on local originals. Summary of the Invention

[0009] The technical problem to be solved by this invention is: how to simultaneously constrain the local existence range of candidate data and the server authorization range during the collaborative process of local talent pool and cloud-based artificial intelligence retrieval, and prevent invalid results from driving local operations when the status of the original resume or evidence changes.

[0010] A further technical problem to be solved by the present invention is: how to maintain a machine-verifiable version association between recruitment retrieval tasks, candidate projections, hit conditions, evidence, and local resume originals without sending local absolute paths, original file opening capabilities, and irrelevant original texts to the server.

[0011] The technical problem that this invention also needs to solve is: how to determine whether the required evidence is closed for different candidate operations, and when some evidence fails, only close the operations that depend on that evidence, instead of discarding the results that can still be interpreted.

[0012] To address the aforementioned technical problems, this invention employs a shared candidate binding protocol, a two-stage transfer protocol that prioritizes range over projection, a stable authorization epoch and single-operation confirmation separation protocol, a result capsule closure protocol, and a recoverable submission protocol differentiated by operation side effect type.

[0013] On one hand, local electronic devices and servers register shared candidate binding namespaces, namespace registration versions, shared candidate binding rule versions, and candidate binding records. These three items are referred to as the three candidate binding dimensions. The registration identifiers at both ends are used only to locate the same candidate binding record; both ends obtain the same random binding token from the record under controlled conditions, and use this token as a key with a key digest function to calculate a comparable candidate handle for the canonical sequence of the three candidate binding dimensions.

[0014] The local electronic device acquires a recruitment search task and forms a local candidate range and a parsing map stored locally based on the original resumes in the managed talent pool. The local candidate range is bound to the shared candidate binding namespace, rule version, talent pool generation, and local range version; the local parsing map associates candidate handles and evidence identifiers with the local original document location information.

[0015] The delivery first enters the scope phase. The local electronic device forms a verifiable scope representation and only sends the task, talent pool, activity-bound version, local scope version, sorted candidate handle set, scope snapshot summary, freshness, and transport authentication fields; no candidate fact evidence projection is sent until the server returns a valid scope confirmation object.

[0016] Server verification can validate the integrity, freshness, replay protection, and active version of a scope expression, independently forming server authorization candidate scopes based on server registry records and access control status. This verification does not interpret local claims as server authorization, nor does it prove that the local original still exists at the time of the operation.

[0017] The server takes the intersection of the local scope and the authorized scope only if the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version are all the same and active. It then forms a valid scope version, an authorized epoch identifier, and a valid candidate handle set commitment, and generates an authorized context digest based on all fixed overriding fields. The server returns a valid scope confirmation object protected by a signature or session message authentication value, carrying an ordered valid set or set commitment and membership proof.

[0018] The projection stage only begins after the local electronic device verifies the valid scope and confirms the objects. Only candidates confirmed to belong to the valid intersection are generated and sent as task-restricted candidate projections. Projections are bound to the task, valid scope version, candidate handle, evidence, source revision, derived revision, and integrity summary, but do not carry absolute paths, original file opening capabilities, local parsing mappings, or irrelevant original text.

[0019] The server verifies each projection to be within the current valid range, and reviews the authorization epoch state before retrieval and before capsule formation. Structured, keyword, vector, graph relation, or language model semantic retrieval is performed only on projections still within the valid intersection. Projections or hits outside the valid range are rejected and classified.

[0020] The candidate result capsule is bound to the recruitment task, three candidate binding dimensions, local and authorized scope versions, effective scope versions, authorized epoch identifier, authorized context digest, mapping and operation strategy versions, candidate handles, conditional evidence pairs, source and derived revisions, and is protected by a server integrity authentication value. The authorized context digest is not written to or modified at the moment of single operation confirmation.

[0021] When the server forms a valid search scope, it commits the authorization epoch identifier, authorization context summary, and valid candidate handle set to the valid search scope and its version. Before performing an AI search, the server reads the current value of the summary field, calculates the current authorization context summary before the search, and compares it with the summary bound to the valid search scope; the search is only performed if the summaries are identical and the authorization status, revocation generation, and term all pass. After a search results in a hit but before forming a candidate result capsule, the server reads the same fields again, calculates the current authorization context summary before capsule formation, and compares it with the summary bound to the valid search scope; a capsule bound to that summary is only formed if it passes again. Before any candidate operation, the summary is recalculated and compared with the current summary based on the capsule summary field; failure at any point in time results in the corresponding action being disabled.

[0022] Local electronic devices issue one-time capability credentials only for permitted operations and select recoverable commit protocols based on side effect type: file exports use temporary files and atomic renaming, database records use transactions or compare-and-swap, sending uses a persistent sender and idempotent message identifier within the same transaction as credential consumption, and interface release uses state compare-and-swap with idempotent rendering. Resources are not assumed to participate in the same distributed transaction; failures before commit are aborted and discarded, and recovery is achieved after commit using idempotent identifiers.

[0023] By registering a unified shared candidate binding namespace, performing integrity, freshness, and anti-replay checks on verifiable range expressions, and conducting versioned intersection with the server's independent authorized range, the AI ​​retrieval component only obtains candidate inputs that are commonly included in both ranges; the actual local existence is still verified by the local device holding the original during operation, and the server's range expression verification is not extended to be interpreted as proof of the existence of remote files.

[0024] By separating task-restricted candidate projections from local parsing mappings maintained only by local electronic devices, the server processes factual evidence units relevant to the recruitment retrieval task, while local absolute paths, open capabilities, and irrelevant original texts remain in the local storage domain, thereby reducing the transmission of irrelevant local resume data.

[0025] By using candidate result capsules to connect task version, scope version, authorization policy version, parsing mapping version, operation policy version, authorization freshness, candidates, conditions, evidence, source revision version, and derived revision version, the results returned by the server can be re-parsed locally based on established data relationships, avoiding the need to drive original operations solely based on candidate identifiers or scores.

[0026] By using candidate-level, condition-level, and evidence-level closed states, as well as a capability bitmap differentiated by operation, the system can retain closed condition-evidence pairs when some evidence fails, and close operations that depend on unclosed evidence, thus achieving hierarchical gating of candidate results.

[0027] By re-verifying server authorization before retrieval and capsule formation, independently verifying the authorization context summary before operation and final commit, and re-verifying the identity, source revision, and permissions of the same opened file object, comparing stable attributes and content identity before and after reading, using immutable snapshot buffers and per-operation commit records, it can identify state changes between authorization revocation, namespace version rotation, original deletion, content corruption, permission revocation, in-situ writes, and verification and external side effects, and convert these states into machine-processable failure types to prevent stale results from continuing to trigger local operations. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the collaborative architecture and data boundary of a local electronic device and server according to an embodiment of the present invention.

[0029] Figure 2 This is a flowchart of a local talent pool and cloud-based collaborative resume retrieval method according to an embodiment of the present invention.

[0030] Figure 3 This is a schematic diagram of the core data objects, versions, and mapping relationships in one embodiment of the present invention.

[0031] Figure 4 This is a diagram showing the transition between the three-level closed state and the candidate operation gating state according to an embodiment of the present invention.

[0032] Figure 5 This is a timing diagram showing the relocation and rebinding after source revision changes in an embodiment of the present invention, where the scope intersection is empty. Detailed Implementation

[0033] The present invention will be further described below with reference to the accompanying drawings and embodiments. The embodiments are used to illustrate data objects, processing steps, and their interrelationships, and are not intended to limit the present invention to a particular file system, retrieval model, database, or communication protocol.

[0034] like Figure 1 As shown, the local electronic device side is configured with task 110, original 120, local range 130, local parsing mapping 140, current authorization context confirmation request and verification unit 150, intersection candidate projection 210, local closure unit 320, operation gating unit 330, and failure object 340; the server side is configured with independent authorization range 220, effective range 230, retrieval unit 240, current authorization context confirmation unit 250, and result capsule 310. The range expression crosses the boundary first, and the projection only crosses the boundary after the intersection confirmation is returned; before retrieval, the retrieval unit 240 rereads the summary field, recalculates, and compares the current summary, respectively, before the result capsule 310 is formed; during candidate operations, unit 250 recalculates according to the capsule summary field and compares the current summary before returning the confirmation object; the local parsing mapping never crosses the boundary.

[0035] A "Recruitment Search Task" is the data processing context for a resume search. The task identifier is used to associate local and server objects; the recruitment requirement version is updated when the content, strength, or evidence requirements of the conditions change; the condition evidence requirements specify whether each condition is necessary evidence for the corresponding candidate's action; and the allowed candidate actions define the operational capabilities that this task can generate.

[0036] A candidate handle is an opaque value that identifies a candidate within the shared candidate binding namespace. Candidate binding records use the local candidate registration identifier and the server candidate registration identifier as lookup keys and are controlled to be associated with the same random binding token. Both ends use the random binding token as a key with a key digest function to compute handles against a canonical sequence of the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version.

[0037] "Source Revision Version" refers to the version of the original local resume content, which can be determined by the revision number and content identity in the managed talent pool. "Derived Revision Version" refers to the version of the set of factual evidence formed from the original. When the source revision version changes, the old candidate result capsule retains only diagnostic uses and its operational capabilities are revoked; even if the evidence is successfully repositioned, capabilities can only be regenerated after a new local scope, projection, effective scope, and result capsule are formed.

[0038] A "conditional evidence pair" includes at least a condition identifier and one or more evidence identifiers. The condition identifier points to a condition in the recruitment search task; the evidence identifier points to a page, paragraph, table cell, or identification area within the original document through local parsing mapping. A condition may require multiple pieces of evidence, and a piece of evidence may support multiple conditions.

[0039] "Closure" indicates that the identifiers and versions in the result capsule can be resolved to local objects that meet the corresponding candidate operation requirements according to the specified data relationships. Closure determination does not recalculate the relevance ranking of candidates, but rather checks whether the result can safely drive the local operation.

[0040] "Operational capability credentials" are one-time, short-lived data objects generated by the operation gating unit for a single permitted operation after closure. Before requesting confirmation of the current authorization context, the local electronic device pre-assigns an operation identifier and a capability credential identifier for the operation to be executed. The pre-assigned identifier does not indicate that the operational capability credential has been generated before the three-level closure and the corresponding operation capability bit determination are passed. Each operation has a different operation identifier and capability credential identifier; the result status of unused credentials is "not created," the initial dispatch status of sending candidate material credentials is "not dispatched," and the dispatch status of the other four types of credentials is "not applicable." An operation submission record corresponding one-to-one with the credential is established only when a temporary result is formed for the corresponding operation request; the credential and submission record are bound to at least the operation type, task identifier, candidate handle, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, local scope version, authorization scope version, effective scope version, source revision version, authorization context summary, opened file object identity, authorization status snapshot, access permission snapshot, immutable result reference, result visibility status, dispatch status, and credential status. When the staging is complete, the commit record changes from non-existent to PREPARED, and the credentials change from unused to IN_PROGRESS. Only when the commit record, credentials, and result enter the committed, consumed, and releaseable / visible / dispatchable states respectively within the same atomic state transition do they cross the defined commit point for each operation type. Failed branches enter the aborted, undo, and discard states respectively. Credentials only authorize the creation of an immutable snapshot buffer from the bound file object and the release of an external result of a specified type once; they do not authorize reopening the file via the original path. Different operations cannot share credentials or commit records.

[0041] The recruitment search task objects include shared candidate binding namespaces, namespace registration versions, shared candidate binding rule versions, task identifiers, recruitment demand versions, selected talent pool identifiers, condition sets, condition evidence requirements, allowed operation sets, and operation strategy versions. Each item in the condition set may include a condition identifier, a standardized condition expression, and a necessity type. The formation method of the standardized condition expression is not a necessary step in this implementation method; this method starts processing from the already formed conditions and evidence requirements.

[0042] The original resume record includes the shared candidate binding namespace, namespace registration version, shared candidate binding rule version, candidate handle, talent pool identifier, local source handle, content identity, source revision version, readability status, and permission status. Content identity can be determined by the file content summary, stable file object attributes, or a combination of both; the local source handle can resolve to an absolute path, but the absolute path is not written to the object sent to the server.

[0043] The local candidate scope objects for a task include the task identifier, recruitment requirement version, talent pool identifier, talent pool generation identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, local scope version, candidate handle set, issuance time, validity period, random number, resolution mapping version, operation policy version, scope snapshot digest, and scope transmission authentication value. The scope snapshot digest's covered fields are fixed as: task identifier, recruitment requirement version, talent pool identifier, talent pool generation identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, local scope version, and a candidate handle set arranged in a defined order. It does not cover the issuance time, validity period, or random number. The scope transmission authentication value uses a message authentication code or digital signature bound to the device session and covers the scope snapshot digest, issuance time, validity period, and random number. The server recalculates the snapshot digest, verifies the transmission authentication value, checks the validity period, and registers the used random number. These two cannot be mixed: when renewing the same scope, the snapshot digest can remain unchanged, but the random number and scope transmission authentication value must change. This check does not replace handle intersection operations, nor does it prove that a local component that is not visible to a remote location actually exists during operation.

[0044] The task-restricted candidate projection objects include the task identifier, recruitment requirement version, talent pool identifier, talent pool generation identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, local scope version, scope snapshot summary, resolution mapping version, candidate handle, source revision version, derived revision version, set of fact evidence units, and projection integrity summary. Each fact evidence unit includes a condition identifier, normalized fact value, a set of evidence identifiers consisting of at least one evidence identifier, evidence type, the derived revision version used when forming the unit, and an optional evidence fragment summary. The projection integrity summary covers the aforementioned fields and fact evidence units, and is used to bind the projection content and its scope attribution. The server recalculates the summary and compares the scope snapshot summary carried by the projection with the verifiable scope expression. Only when both summaries pass and both handle versions are active is the projection considered a member of the scope snapshot.

[0045] The server's authorized candidate scope includes the task identifier, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, access subject identifier, device session identifier, authorization scope version, authorization policy version, revocation generation identifier, authorized candidate handle set, authorization validity period, and authorization status. The server locates candidate binding records using the registration identifier and forms handles from random binding tokens in the records, without inputting the registration identifier as a handle digest.

[0046] The valid search scope includes the task, talent pool, three candidate binding dimensions, local scope version, access subject, device session, authorization scope version, authorization policy version, revocation generation identifier, authorization status, authorization validity period, valid scope version, authorization epoch identifier, valid candidate handle set commitment, valid candidate handle set, and authorization context digest. The authorization epoch identifier, authorization context digest, and valid candidate handle set commitment are associated with the valid search scope and valid scope version. The authorization context digest consistently covers the access subject, device session, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, valid candidate handle set commitment, and authorization validity period.

[0047] Candidate result capsules have a created or uncreated state. Capsules are created only when the valid search scope is not empty and all validations pass. Created capsules include a task identifier, recruitment requirement version, talent pool and generation identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, local scope version, scope snapshot summary, authorized scope version, authorized policy version, authorized epoch identifier, authorized validity period, valid scope version, authorized context summary, resolution mapping version, operation policy version, candidate handle, conditional evidence pair, source revision version, derived revision version, search component version, formation time, and server integrity authentication value. Uncreated capsules only record the shared candidate binding namespace, namespace registration version, shared candidate binding rule version, task identifier, valid scope version, authorized context summary, and scope-level failure reason; they do not include candidate handles, conditional evidence pairs, source revision versions, or server integrity authentication values. The authorized context summary is used to associate with independently formed server authorized snapshots and does not indicate a search hit. The server integrity authentication value can be a server digital signature or a message authentication code bound to an authenticated device session; capsules do not carry local absolute paths or original file opening capabilities.

[0048] The local resolution mapping object includes the task identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, local scope version, resolution mapping version, mapping from candidate handle to local source handle, and mapping from evidence identifier to evidence locator, original text digest, evidence type, and source revision version. The mapping is stored by local management domain and becomes invalid or generates a new version when the task is destroyed, the talent pool is removed from management, the access subject changes, the handle version is rotated, or the original document is revised or rebound. The resolution mapping version in the capsule, as well as the shared candidate binding namespace and the two handle versions, must be consistent with the currently active mapping stored locally.

[0049] The local closure determination object stores the task, candidates, three candidate binding dimensions, range version, authorization epoch identifier, authorization context digest bound to the candidate result capsule, current authorization context digest, parsing mapping version, and hierarchical closure status. The device first pre-allocates an operation identifier and capability credential identifier for the operation to be executed, generates an unused challenge value, and sends a confirmation request to bind the authorization epoch identifier and capsule digest. After obtaining the confirmation object, it verifies the server authentication value covering the identifier, session, challenge, sequence number, confirmation time, confirmation period, authorization epoch identifier, and current digest, and compares the current digest with the capsule digest. Only when the two digests are identical, the three-level closure is passed, and the corresponding operation capability bits are all correct, does it generate an operation capability credential referencing the pre-allocated identifier.

[0050] The aforementioned nine types of objects respectively assume the responsibilities of task constraints, original facts, scope transfer, task projection, server authorization, valid intersection, result encapsulation, local resolution, and operation determination. The shared candidate binding namespace registration relationship enables the handles at both ends to be comparable; the server does not need to receive local resolution mappings to complete the retrieval, and the local electronic device does not need to obtain the internal expression of the server's authorization rules, but it needs to obtain the authorization version, policy version, and authorization validity period protected by the server's authentication value and bound to the operation identifier, capability credential identifier, device session, challenge value, sequence number, confirmation time, and confirmation validity period, in order to perform result closure before credential issuance and before the determined submission point for each operation type.

[0051] like Figure 2 As shown, before step S501, the local electronic device and the server register a shared candidate binding namespace, namespace registration version, shared candidate binding rules, and shared candidate binding rule version through an authenticated device session, and establish a shared registration record or obtain a mapping record issued by the server. The server writes its candidate registration record into the server-side handle mapping according to the formation rules of the active version. The local electronic device then reads the original records of task 110 and managed talent pool 120, excludes unresolvable source handles, originals that have exited the selected talent pool, and records that do not belong to the valid talent pool generation, generates a local candidate range 130 of tasks bound to the two active versions, and simultaneously generates or updates a local parsing mapping 140 with a parsing mapping version and bound to the same version.

[0052] The local scope version is updated when events occur that change the scope content, such as changes to the candidate handle set, talent pool generation, recruitment demand version, or resolution mapping version. The issuance time indicates the moment when the verifiable scope representation of the task's local candidate scope is formed in this transmission, and the expiration date indicates the deadline when the representation can be accepted by the server. The local electronic device maintains the freshness of the unchanged scope in an authenticated device session with a scope renewal event carrying a new random number; a scope expiration event is sent when original file additions / deletions, generational changes, demand changes, mapping changes, expiration dates, namespace registration version or shared candidate binding rule version rotation, conflicts, or invalidations are detected. The server maintains the local scope state accordingly. The original local scope version and old handle version only retain an interpretation relationship; they are not restored through renewal and are no longer used for new retrieval or operational capabilities.

[0053] In step S502, a local preprocessing chain, independent of the current AI resume retrieval, pre-processes the original resume record with format parsing, text region recognition, or structured field extraction to form candidate facts, evidence identifiers, evidence types, and evidence locators stored only in the local parsing mapping. The projection forming unit does not fabricate the above facts or locator information during retrieval, but only selects existing fact evidence units based on conditional evidence requirements. Each fact evidence unit stores the condition identifier, normalized fact value, evidence identifier set, evidence type, and the derived revision version used when forming the unit. The projection generator executes the field permission table, serializing only the specified fields. The scope snapshot summary permanently covers the task, requirement, talent pool, generation, namespace, namespace registration version, shared candidate binding rule version, local scope version, and handle set arranged in a defined order; the scope transfer authentication value separately covers the summary, issuance time, validity period, and random number; the projection integrity summary covers the projected task, requirement, talent pool, generation, namespace, two handle versions, local scope version, scope snapshot summary, mapping version, candidate, source revision, derived revision, and fact evidence unit.

[0054] For portable document formats, evidence locators may include page numbers and enclosing areas; for word processing files, they may include paragraph markers, table markers, and cell markers; for spreadsheet files, they may include worksheet markers and cell ranges; for image files, after the local electronic device performs optical character recognition (OCR), it can write the image page marker, the recognition area, and the recognized text summary into the evidence locator. The evidence locator in the projection is an opaque reference to the aforementioned local locators.

[0055] In step S503, the server only receives verifiable range expressions and not task-restricted candidate projections. It recalculates the range snapshot summary, verifies the range transmission authentication value using device session verification materials, checks the issuance time, validity period, and whether the random number has been registered and used, and verifies the task, recruitment requirements, talent pool, generation, shared candidate binding namespace, local range status, and version relationship. The server also verifies that the namespace registration version and the shared candidate binding rule version are related and both are active. It selects authorized candidate handles from the server-side handle mapping according to the current access subject, device session, talent pool affiliation, and authorization policy, forming a server-authorized candidate range 220 with authorization status and revocation generation identifier. After all verifications pass and the three candidate binding dimensions of both parties are consistent, the intersection of the two handle sets is taken to generate a valid retrieval range 230. The server does not presume the local original actually exists during operation simply because the expression verification passes.

[0056] The server generates a commitment to the set of valid candidate handles and, based on the access subject, device session, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, commitment to the set of valid candidate handles, and authorization validity period, forms an authorization context digest. The server associates the authorization epoch identifier, authorization context digest, and commitment to the set of valid candidate handles with the valid retrieval scope and valid scope version, and then forms and returns a valid scope confirmation object protected by a signature or session message authentication value. This object binds the task and scope version, authorization epoch identifier, authorization context digest, set commitment, and the ordering of the valid set or membership proof. If any fixed overriding field changes, the original digest becomes invalid and a new digest is generated.

[0057] When any validation fails or the intersection is empty, the server determines the set of valid candidate handles to be empty, generates a range-level closure failure object, does not read candidate projection content, does not call the AI ​​retrieval unit 240, and does not create a candidate result capsule or local closure determination. Failure objects can be distinguished by range integrity failure, expression expiration, random number replay, task inconsistency, talent pool or generational inconsistency, namespace or handle version inconsistency, local range invalidation, authorized range invalidation, unavailable authorized context, changes in authorized policy, version association inconsistency, and an empty intersection; an empty intersection is not represented by a fictitious candidate handle.

[0058] In step S504, after the local electronic device verifies the valid scope confirmation object, it only forms a task-restricted candidate projection for candidates verified as valid intersection members and sends it to the server. The server recalculates the projection integrity summary and verifies the task, valid scope version, candidate handle, source revision version, and membership relationship. Before performing the AI ​​resume retrieval, it rereads the current values ​​of each field used when forming the valid retrieval scope binding summary, calculates the current authorization context summary before retrieval and compares it with the valid retrieval scope binding summary, and verifies the authorization status, revocation generation identifier, and authorization validity period. The AI ​​retrieval unit 240 is called only when the two summaries are the same and the verification passes; otherwise, the AI ​​resume retrieval is not performed. When the retrieval unit returns an out-of-scope handle, the output adapter discards the hit and records the out-of-scope status.

[0059] In step S505, after the AI ​​retrieval produces a hit but before forming a candidate result capsule, the server again reads the current values ​​of the access subject, device session, talent pool identifier, three candidate binding dimensions, authorization scope version, authorization policy version, revocation generation identifier, authorization status, valid candidate handle set commitment, and authorization validity period. It then calculates the current authorization context summary before capsule formation and compares it with the valid retrieval scope binding summary. Only when the two summaries are identical and the authorization status, revocation generation identifier, and authorization validity period all pass verification, is each valid hit's condition identifier and evidence identifier set combined into a conditional evidence pair. The task, requirement, talent pool, generation, three candidate binding dimensions, local scope version, scope snapshot summary, authorization scope version, authorization policy version, authorization epoch identifier, authorization validity period, valid scope version, current authorization context summary before capsule formation, mapping version, operation policy version, candidate, conditional evidence pair, source revision, and derived revision are all written into the candidate result capsule 310; otherwise, uncaptured hits are discarded and no capsule is formed. The server integrity authentication value covers all fields that determine the closure relationship.

[0060] The local electronic device pre-assigns an operation identifier and a capability credential identifier for the operation to be executed, generates an unused challenge value, and sends a candidate operation confirmation request that binds the authorization epoch identifier and the authorization context summary of the candidate result capsule. The server's current authorization context confirmation unit 250 rereads the current values ​​of each field used when forming the authorization context summary bound to the candidate result capsule and calculates the current authorization context summary; only when the current summary is the same as the request binding summary and the authorization status, revocation generation, and duration pass, is a confirmation object formed that references the authorization epoch identifier and the current summary, and carries the operation identifier, capability credential identifier, device session, challenge value, confirmation sequence number, confirmation time, confirmation validity period, and identification values ​​covering all fields; otherwise, the confirmation object is rejected. The local unit 150 verifies the confirmation object and compares the current summary with the capsule summary again. Only after passing the comparison is the confirmation result handed over to the local closure unit 320 to perform three-level closure.

[0061] Candidate-level closure requires that the candidate handle exists in the corresponding local scope version, can resolve to the original in the managed talent pool, the original is readable, and the access subject performing the operation has the necessary permissions. If any of these requirements are not met, all operational capabilities dependent on the original are disabled.

[0062] Conditional closure is performed for each hit condition. If the task specifies that a condition requires at least one piece of evidence, the candidate result capsule must contain the corresponding evidence identifier; if the task specifies that it needs to be supported by different types of evidence, then the corresponding evidence identifiers should all be present. Conditions that are only for display and do not require original evidence can be marked as requiring no evidence according to the task rules.

[0063] Evidence-level closure requires that the evidence identifier can be located in the original document through local resolution mapping, the current evidence content matches the original text summary saved in the mapping, and its candidate handle, condition identifier, and source revision version relationship are valid. If the source revision versions are the same, the location can be directly verified; if the source revision versions are different, the process of relocation is initiated.

[0064] The operational capability bitmap treats opening the original resume, adding to the candidate list, exporting, generating a report, and sending candidate materials as independent bits. Each bit is associated with the necessary candidate-level, condition-level, and evidence-level state sets, and is constrained by the upper bound of the set of operations allowed by the recruitment retrieval task. The operation identifier and capability credential identifier for the operation to be executed are pre-assigned before requesting confirmation from the current authorization context; a one-time short-term credential referencing the pre-assigned identifier is generated only when the three-level closure is successful and the corresponding capability bit is allowed. Initially, the credential is unused and no result is created; the sending and dispatching status of the candidate material sending credential is undispatched, and the other four types of credentials are inapplicable. When an actual operation request generates a temporary result, an operation submission record corresponding one-to-one with the credential is established; different operations do not share credentials or submission records.

[0065] Opening the original resume can require candidate-level closure; adding it to the candidate list can further require the recruitment search task to be marked as a necessary condition and its evidence to be closed; exporting, generating reports, and sending candidate materials can respectively require closure of all conditional evidence pairs cited in their output. Specific operational strategies can be adjusted according to the deployment purpose, but operations on original documents that have not passed candidate-level closure should not be set to allowed.

[0066] Operation capability credentials are bound to the identity of the same file object, not just the path, and are also bound to the operation identifier, operation type, capability credential identifier, task identifier and candidate handle, shared candidate binding namespace, two handle versions, local scope version, authorized scope version, effective scope version, source revision version, authorized context digest, authorized state snapshot, access permission snapshot, immutable result reference, result visibility status, dispatch status, and credential status. The local electronic device records the stable attributes, content identity, and permissions of the same opened file object before and after reading. The operation processor only takes its immutable snapshot buffer as input and first forms an externally invisible display object, temporary object, or non-dispatchable queue item. When the temporary storage is complete, an operation commit record bound to the same fields is atomically created, the record is set to ready, and the credentials are changed from unused to in progress. Before final submission, the device generates a new unused confirmation challenge value and obtains the current authorization context confirmation object bound with the same operation identifier and capability credential identifier. It re-verifies the server authentication value, request and session binding, unused challenge value, sequence number increment, confirmation freshness, confirmation validity period, authorization validity period, activity of two handle versions, consistency of authorization context digest, credential in progress and not consumed or expired, and valid permissions. If all pass, the new challenge value is atomically consumed and the sequence number is accepted. Then, in the common submission domain, the record, credential, and result are atomically converted to committed, consumed, and releasable, visible, or dispatchable. If any review fails or conversion conflict occurs, it is converted to pre-submission abort, credential revocation, and result discard, without expanding the effective retrieval scope.

[0067] For candidate results where some evidence is not closed, the local electronic device retains the capsule and the closed conditional evidence pair, closes the bits that depend on the unclosed evidence in the operational capability bitmap, and keeps other bits that belong to the task permission set and meet their respective necessary conditions allowed. An operation-by-operation credential referencing the pre-assigned identifier for an operation is generated only when all three levels of closure and capability bits corresponding to that operation pass; pre-assigned identifiers for failed operations are discarded or await expiration and do not form consumable credentials. The typed failure object record records the affected evidence identifier and operation type.

[0068] If the current authorization context summary before retrieval or capsule formation is inconsistent with the binding summary of the valid retrieval scope, or if the authorization status, revocation of generational identifier, or authorization validity period verification fails, the server will not perform a retrieval or generate a candidate result capsule. For results with incorrect server integrity authentication values, unavailable operation confirmation objects, mismatched operation or capability identifiers or device sessions, used confirmation challenge values, non-incrementing confirmation sequence numbers, confirmation times exceeding the freshness window, expired confirmation or authorization validity periods, inconsistencies between the current authorization context summary and capsule summary, inconsistent task or requirement versions, inconsistent talent pool or generational versions, inconsistent candidate binding dimensions, invalid local scope versions, incompatible authorization scope versions, authorization policy versions, or valid scope versions, inconsistent parsing mapping versions, or inconsistent operation policy versions, the local electronic device will not parse the original, will not generate any operation capability credentials, will invalidate the corresponding pre-assigned identifier, and will generate a typed confirmation or capsule association failure object.

[0069] When the source revision changes, the local electronic device immediately revokes the ability to operate based on the old candidate result capsule, marking the old capsule as only usable for diagnosis. Subsequently, a relocation query is generated based on the original evidence summary, evidence type, adjacent headings, and coordinate relationships between preceding and following text or tables to search for candidate positions in the existing original document. After the candidate positions are verified through content identity, candidate association, and conditional association, only the local parsing mapping candidate status used to form the next version is updated; the evidence-level status corresponding to the old capsule is not directly changed to operable closure.

[0070] If multiple candidate positions exist in the existing original document that cannot be uniquely determined, or if no candidate position passes both content and association verification simultaneously, the relocation fails, and the system sets the corresponding evidence-level closure state and the operational capability position dependent on that evidence to unclosed and prohibited. If the relocation succeeds and both the current namespace registration version and the shared candidate binding rule version are active, the local electronic device generates a new parsing mapping version, a local scope version, a task-restricted candidate projection, and a verifiable scope expression carrying a new random number for the active binding version; the server re-verifies the authorized scope and the current authorized context, forms a new valid scope, performs the retrieval, and forms a new candidate result capsule. The local electronic device can only generate new per-operation credentials after completing the three-level closure of the new capsule.

[0071] When the original associated document becomes unavailable, but an alternative source with identical content exists within the same managed talent pool, the local electronic device verifies the identity of the alternative source's content, access permissions, talent pool ownership, candidate handle association, and the activity status of the two current handle versions. If all verifications pass, the system generates a new parsed mapping version bound to the active version, a local scope version, a task-restricted candidate projection, and a verifiable scope expression carrying new random numbers. The server, based on the new version, re-verifies the authorized scope and context, re-forms a valid scope, performs the retrieval, and generates a new candidate result capsule bound to the revised version of the alternative source.

[0072] Rebinding does not use the operational capability credentials of the old result capsule; even if all four checks pass, candidate-level, condition-level, and evidence-level closure checks must be re-executed for the new candidate result capsule. If the alternative source does not belong to the corresponding talent pool, the accessing subject does not have the right to read, the content identity is inconsistent, or the candidate association is inconsistent, the local electronic device outputs a typed failure object indicating that the alternative source is unqualified and closes the relevant operational capability bits. Example 1: Normal Closure

[0073] Local electronic devices and servers register the shared candidate binding namespace N1, namespace registration version NSV1, shared candidate binding rule version HRV1, and their activity status in the authenticated device session. The task identifier for the recruitment retrieval task object is T1, the recruitment requirement version is R1, the selected talent pool is L1, the operation strategy version is OP1, the conditional evidence requirements include C1-E1 and C2-E2, and the allowed operations are open, add to candidate list, and export. The resume original record object includes the candidate handle H1, local source handle P1, content identity D1, source revision version S1, readable status, valid permission status, and file object identity F1.

[0074] The local electronic device forms a local candidate scope object for the task. Its talent pool generation is G1, its local scope version is L1V1, its resolution mapping version is M1, and its handle set includes H1. The scope snapshot digest Q1 only covers T1, R1, L1, G1, N1, NSV1, HRV1, L1V1, and the handle set arranged in a defined order; the verifiable scope expression also includes the issuance time, validity period, and random number NCE1, and uses the session message authentication code MAC1 as the scope transmission authentication value. The local resolution mapping M1 binds NSV1 and HRV1, maps H1 to P1, and maps E1 and E2 to the original location.

[0075] The server only processes verifiable range expressions. From the server-side N1 handle mapping bound to NSV1 and HRV1, it selects H1 for the access subject SUBJECT1 and device session SESSION1, forming the authorized range version A1, authorized policy version AP1, authorized status valid, revocation generation RVG1, authorized epoch identifier EPOCH1, and authorized validity period AX1. After the range snapshot, transport authentication value, anti-replay, and version verification pass, a valid range version V1 and handle set H1 are formed. A commitment CMT1 is formed for the sorted valid handle set, and the authorized context digest AUTHCTX1 is formed only by the canonical sequence of SUBJECT1, SESSION1, L1, N1, NSV1, HRV1, A1, AP1, RVG1, authorized status valid, CMT1, and AX1. The server returns a valid range confirmation object bound to T1, L1V1, A1, V1, EPOCH1, AUTHCTX1, CMT1, and the sorted set {H1}, overwriting the aforementioned fields with the server authentication value RANGEAUTH1.

[0076] The local electronic device verifies RANGEAUTH1 and T1, L1V1, A1, V1, EPOCH1, AUTHCTX1, CMT1, and set {H1}. Only after confirming that H1 belongs to a valid intersection is a task-constrained candidate projection formed. This projection includes T1, R1, L1, G1, N1, NSV1, HRV1, V1, M1, H1, S1, derived revision D1V1, and fact evidence units C1-E1 and C2-E2, and carries a projection integrity summary PDI1 covering the above fields, excluding absolute paths that P1 can resolve. The server recalculates PDI1 and verifies the membership relationships of V1 and H1 relative to CMT1 before handing the projection over to the retrieval unit.

[0077] Before the AI ​​retrieval unit prepares to process the projection corresponding to H1, the server reads the current values ​​of the twelve fixed fields used when forming the authorization context summary AUTHCTX1 and calculates the current authorization context summary PREAUTH1; the retrieval is only performed when PREAUTH1 is equal to AUTHCTX1 and the current authorization status, RVG1, and AX1 are passed. After a hit occurs but before a candidate result capsule is formed, the server reads the same set of fields again and calculates the current authorization context digest RESULTAUTH1. Only when RESULTAUTH1 equals AUTHCTX1 and the status, RVG1, and AX1 are still valid, is a candidate result capsule object with the status "created" formed, binding T1, R1, L1, G1, N1, NSV1, HRV1, L1V1, Q1, A1, AP1, EPOCH1, AX1, V1, RESULTAUTH1, M1, OP1, H1, C1-E1, C2-E2, S1, and D1V1, and these fields are overwritten with the server integrity authentication value SIG1. If any digest comparison or verification fails, no retrieval is performed or no capsule is formed.

[0078] The local electronic device uses the verification material obtained from the device session to verify SIG1, pre-assigns an operation identifier OID1 and a capability credential identifier CID1 for the operation to be performed, generates an unused challenge value CH1, and sends a candidate operation confirmation request to the server, which is bound to EPOCH1 and capsule summary AUTHCTX1. The server rereads the current values ​​of the twelve fixed fields used when forming AUTHCTX1 and calculates CURAUTH1; only when CURAUTH1 equals AUTHCTX1 and the current authorization status, RVG1, and AX1 pass, it forms and returns a confirmation object that references EPOCH1 and CURAUTH1, separately binds OID1, CID1, SESSION1, CH1, confirmation sequence number SEQ1, confirmation time CT1, and confirmation validity period CE1, and overwrites the aforementioned fields with SA1; otherwise, it refuses to form a confirmation object. After verifying SA1, request and session binding, CH1 is not used, SEQ1 is incremented, CT1 is fresh, CE1 and AX1 are not expired, and CURAUTH1 is equal to AUTHCTX1, the device atomically consumes CH1 and accepts SEQ1. Then, it compares the capsule, local state and confirmation object item by item, obtains P1 through M1 and opens the file object F1, and re-verifies readability, permissions, S1 and E1 and E2 positioning to form a three-level closed local closure judgment object.

[0079] The operation capability bitmap is opened, added to the candidate list, and exported as allowed. The device only receives the export request, so it uses the OID1 and CID1 pre-assigned for the export operation in step

[0078] . After the three-level closure and export capability bits are passed, it generates the unused export credentials with the binding task identifier T1, candidate handles H1, N1, NSV1, HRV1, L1V1, A1, V1, S1, AUTHCTX1, F1, authorization and permission snapshot, and immutable result reference. The device forms an immutable snapshot buffer from the same F1 and temporarily stores the export result, atomically establishes the prepared record, and sets the export credentials to in progress. Before final submission, the device generates a new unused challenge value CH2 and obtains a confirmation object bound to the same OID1, CID1, and SESSION1. It verifies the server authentication value SA2 covering all confirmation fields, that CH2 is unused, that the confirmation sequence number SEQ2 is greater than SEQ1, that the confirmation time is fresh, and that the confirmation validity period and AX1 have not expired. If all conditions are met, CH2 is atomically consumed and SEQ2 is accepted. Then, at the definitive submission point of the export operation, the record, credentials, and export result are atomically set to submitted, consumed, and visible. While opening and adding to the candidate list are allowed, because no corresponding operation request has been received, no identifier is pre-assigned, no credentials are generated, and no submission record is submitted.

[0080] The nine types of objects and their states in this embodiment are as follows: Recruitment retrieval task T1 and resume original record H1 are in a processable state; the task local candidate range L1V1, task restricted candidate projection PDI1, server authorized candidate range A1, effective retrieval range V1, candidate result capsule SIG1, local parsing mapping M1, and local closure judgment are all bound to NSV1 and HRV1; the capsule, effective range, closure judgment, per-operation credential, and submission record are all bound to AUTHCTX1. The three-level state is closed, and the three task allow bits are allowed; the exported submission record is submitted, and the exported credential is consumed; unexecuted credentials are still unused and do not have corresponding submission records. Failure before submission produces invisible and discarded results; after submission, interruption only uses immutable result references to idempotently release or dispatch submitted results without consuming credentials again. Example 2: Local Scope Failure

[0081] Namespace N2 is registered. The recruitment retrieval task targets T2, requirement version R1, and operation strategy version OP1; the resume original record object H2 originally belonged to generation G1 of talent pool L2, and has source revision S2 and local source handle P2. After the verifiable range expression is issued, its validity period expires and the local device does not send a renewal event carrying a new random number.

[0082] The original task's local candidate range objects included L2V1, range snapshot digest Q2, range transport authentication value MAC2, random number NCE2, and parsing mapping versions M2 and H2. The server marked L2V1 as expired based on its validity period; M2 only retained the historical association between H2-P2-S2 and no longer generated capabilities for new operations.

[0083] The original task-restricted candidate projection object carries Q2 and projection integrity summary PDI2 and is bound to L2V1; although the server-authorized candidate scope object A2 obtains H2 from the server registration record and is still valid, it cannot restore the expired L2V1 to validity.

[0084] The freshness check identifies expired L2V1 objects, and the valid retrieval scope objects are in a closed state and the handle set is empty; the server does not read the projection bound to L2V1 and does not call the artificial intelligence retrieval unit.

[0085] In this embodiment, the creation status of the candidate result capsule object is determined to be not created; the not created object records N2, NSV1, HRV2, T2, the closed valid scope version and the authorization context summary of the current authorization snapshot of A2, the scope closure failure object record returned by the server expresses expiration, T2, R1, L2V1, Q2 and A2, and does not contain candidate handles, and does not interpret expiration as the local original not actually existing.

[0086] If the local electronic device holds a capsule previously formed based on L2V1, the capsule can only be used to display historical diagnostic relationships; the creation status of the local closure determination object is not created, and only the handle triplet, task, effective scope version of closure, authorization context summary of the current A2 authorization snapshot and scope-level failure reason are recorded, without including candidate handles, operation capability bitmap, per-operation credentials or commit records.

[0087] Since no valid search range exists, the local electronic device does not create an operational capability bitmap, therefore no allow bits are available, and no operational capability credentials, operation submission records, or temporary external results are generated. If a search is still required, a new verifiable range representation and a new projection bound to its range snapshot summary must be formed using new random numbers.

[0088] The nine categories of objects and their states in this embodiment are as follows: Recruitment retrieval task T2 still exists; original resume record H2 is only retained as a local fact; the local candidate range L2V1 of the task expires due to the expiration of the deadline; the restricted candidate projection PDI2 of the task is not read; the server-authorized candidate range A2 is valid but cannot replace the local range; the valid retrieval range is empty; the candidate result capsule is not formed; the local parsing mapping M2 only retains historical associations; the local closure judgment only records range-level failures and does not include the operational capability bitmap. State propagation includes range activity, deadline expiration, server range state expiration, valid set empty, retrieval not invoked, capsule not formed, bitmap not created, and capability not issued. Example 3: The intersection of authorizations is empty

[0089] Namespace N3 and registered version NSV1 have been registered. The recruitment retrieval task object T3 is bound to requirement version R1, talent pool L3 and operation strategy OP1; the resume original record objects H31 and H32 have source revisions S31 and S32 and readable local source handles, respectively.

[0090] The local range L3V1 includes H31, H32, range snapshot digest Q3, issuance time, validity period, random number NCE3, and range transfer authentication value MAC3; the parsed mapping M3 stores the candidate and evidence locations; both task-restricted projections carry Q3 and their respective projection integrity digests.

[0091] The server maps the N3 handle from the server side and the access subject authorization record to form A3, authorization policy AP1, and authorization period AX3. The authorization handle set only contains H39 and does not contain H31 and H32.

[0092] After the range snapshot, transmission authentication value, anti-replay, projection binding, and authorized range verification all pass, the server calculates the intersection of {H31,H32} and {H39} to obtain an empty set and forms a range-level intersection empty state; this state does not use fictitious handles or placeholder handles as members of the empty set.

[0093] The server does not read the fact evidence units of H31 and H32, does not call the artificial intelligence retrieval unit, and determines the creation status of the candidate result capsule object as not created; the not created object records the authorization context summary of N3, NSV1, HRV3, T3, empty valid range version and A3 current authorization snapshot, while the range-level failure object includes T3, L3V1, Q3, A3, AP1 and the intersection is empty type.

[0094] After receiving a failed object identified by the server, the local electronic device does not read the local source handle in M3. The creation status of the local closure judgment object is not created. It records the handle triplet, task, empty valid range version, authorization context summary of the current authorization snapshot of A3, and range-level failure, but does not contain candidate handles or operation capability bitmaps.

[0095] Since there is no valid search scope, the local electronic device does not create an operational capability bitmap, and therefore there is no allow bit; the local electronic device does not search other directories, does not add candidate handles, does not establish an immutable snapshot buffer, and does not generate operational capability credentials, operation commit records, or external results.

[0096] The nine types of objects and their states in this embodiment are as follows: Recruitment retrieval task T3 and original resume records H31 and H32 are in the local management domain; the integrity verification of the task's local candidate range L3V1 and the task's restricted candidate projection passes; the server-authorized candidate range A3 only contains H39; the handle set of the effective retrieval range V3E is empty; the candidate result capsule is not formed; the local parsing mapping M3 is not read; the local closure judgment record range level fails and no operational capability bitmap is created. State propagation is as follows: authorized handles come from server registration records, intersection is empty, projection is not read, retrieval is not invoked, capsule is not formed, bitmap is not created, and capability is not issued. Example 4: Source revision changed and all evidence relocated

[0097] Namespace N4, namespace registration version NSV4, and shared candidate binding rule version HRV4 are registered and active. The recruitment retrieval task object T4 is bound to requirement version R1, talent pool L4, and operation strategy OP1; the old capsule is bound to H4, NSV4, HRV4, source revision S4V1, local scope L4V1, scope snapshot summary Q4A, and resolution mapping M4V1. The resume original record object subsequently becomes S4V2, with the change manifested as paragraph reformatting.

[0098] If the local device detects inconsistencies between S4V1 and S4V2 before operation, it immediately revokes the capability of the old capsule and marks it as diagnostic-only. M4V1 saves the original text summaries, evidence types, and adjacent content features of E41 and E42, which the local device uses to perform relocation in S4V2.

[0099] After E41 and E42 both uniquely pass the content identity, candidate handle and condition association verification, and NSV4 and HRV4 are still active, the local device forms a parsing map M4V2 bound to the two active versions, a local range L4V2, a range snapshot digest Q4B, a range transport authentication value MAC4B carrying a new random number NCE4B, and a new projection bound to the two handle versions, Q4B, S4V2, and D4V2 and having a projection integrity digest PDI4B.

[0100] The server re-verifies NSV4, HRV4, Q4B, MAC4B, PDI4B, anti-replay status, and A4 and AP1 formed by the server registration records. It confirms the validity of the authorization twice, before the retrieval and before the capsule, to form the valid scope V4V2 and the new authorization context digest AUTHCTX4B and performs the retrieval. Then, it forms a new capsule bound to L4V2, Q4B, A4, AP1, V4V2, AUTHCTX4B, M4V2, OP1, H4, S4V2, and D4V2.

[0101] The local electronic device uses device session verification materials to verify the server integrity authentication value and authorization period of the new capsule, compares the capsule's task, scope, authorization, mapping and operation policy version with the local state item by item, and then obtains the new locators of E41 and E42 through M4V2.

[0102] The candidate level, C41 and C42 condition levels, and E41 and E42 evidence levels of the new capsule are all closed; the local closure determination record M4V2 and the identity of the existing document object are recorded, and the evidence status of the old capsule is not rewritten to operable closure.

[0103] Operations that depend on E41 and E42 in the operational capability bitmap are allowed. The local electronic device generates only one-time, short-term credentials that bind the identity of S4V2 and the opened file object for new capsules; old credentials remain in a revoked state.

[0104] The nine types of objects and states in this embodiment are as follows: Recruitment retrieval task T4 remains R1; the original resume record changes from S4V1 to S4V2; the local candidate range of the task is updated from L4V1 to L4V2; the restricted candidate projection of the task is updated to PDI4B; the server-authorized candidate range A4 is valid after two re-checks; the valid retrieval range is updated to V4V2; the old candidate result capsule can only be diagnosed and forms a new capsule bound to S4V2, NSV4, HRV4, and AUTHCTX4B; the local resolution mapping is updated to M4V2; the local closure determination only recloses the new capsule and generates new capabilities. Successful relocation itself does not directly restore capabilities; in the event of failure or handle version invalidation, evidence and dependent operations remain closed. Example 5: Partial Evidence Fails

[0105] Namespace N5, namespace registration version NSV5, and shared candidate binding rule version HRV5 are registered and active. The recruitment retrieval task object T5 is bound to R1, L5, and operation strategy OP5, allowing only addition to the candidate list and report generation. Adding to the candidate list depends on C51-E51, and report generation depends on both C51-E51 and C52-E52. The original resume record H5 is bound to P5, content identity D5, and source revision S5, and has read access rights.

[0106] The local range L5 carries the range snapshot digest Q5, the random number NCE5, the range transport authentication value MAC5, and the mapping versions M5 and H5; the projection carries Q5, M5, S5, derived revisions D5, C51-E51, C52-E52, and the projection integrity digest PDI5. M5 can resolve E51, but the location information for E52 is missing.

[0107] The server generates A5 and AP1 from the registration records bound to NSV5 and HRV5, verifies Q5, MAC5, PDI5 and reviews the authorization twice, forming V5 containing H5 and the authorization context digest AUTHCTX5; the capsule is bound to T5, R1, N5, NSV5, HRV5, L5, A5, AP1, authorization period, V5, AUTHCTX5, M5, OP5, H5, C51-E51, C52-E52, S5 and D5.

[0108] After verifying the authentication value and all versions of the local electronic device server, a determination is made regarding candidate-level closure, the presence of C51 and C52 condition identifiers, E51 evidence-level closure, and E52 evidence-level non-closure.

[0109] The local closure determination object records NSV5, HRV5, A5, AP1, V5, AUTHCTX5, authorization period, M5, OP5, file object identity, and E52 content missing. It retains the cross-reference of "report depends on E51 and E52" in the C51-E51 and C52-E52 relationship and operation strategy, and obtains the current authorization context confirmation object that has passed the server authentication value, freshness, anti-replay, confirmation validity period, and authorization validity period verification and has a digest of AUTHCTX5.

[0110] OP5 makes adding to the candidate list depend only on C51-E51, while generating a report depends on both C51-E51 and C52-E52. E51 is closed while E52 is not closed, so the ability bit for adding to the candidate list is enabled, the ability bit for generating a report is disabled, and no credentials, commit records, snapshot buffers, or temporary objects are created for the report.

[0111] The local electronic device generates a one-time, short-lived credential for adding an operation to the candidate list only if the operation is in an allowed state. This credential includes a bound operation identifier, capability credential identifier, task identifier T5, candidate handle H5, NSV5, HRV5, L5, A5, V5, S5, AUTHCTX5, and file object identity. If this credential is in an unused state, the result status is "not created," and the dispatch status is "inapplicable," no operation commit record is created because no actual request to add the operation to the candidate list has been received. Credentials are not generated for opening originals because opening is not a allowed task operation. When a report is requested, the system reviews the report along its two dependency branches C51-E51 and C52-E52, outputting evidence that clearly identifies C52, E52, and the report generation operation to locate failure diagnostics. No report credentials, commit records, snapshot buffers, or external results are generated.

[0112] The nine categories of objects and their states in this embodiment are as follows: Recruitment retrieval task T5 specifies that the candidate list depends on E51, and the report depends on both E51 and E52; the original resume record H5 has readable rights; the task's local candidate range L5 and the task's restricted candidate projection PDI5 are valid; the server-authorized candidate range A5 is valid after re-checking; the valid retrieval range V5 includes H5; the candidate result capsule retains C51-E51 and C52-E52; the local parsing mapping M5 can only close E51; the local closure judgment sets the candidate list capability to allowed and the reporting capability to prohibited. All objects are associated using NSV5, HRV5, and AUTHCTX5, with only one unused candidate list credential and no submission records; the report diagnostics only point to C52, E52, and the report generation operation, and do not incorrectly close candidate list operations that only depend on E51. Example 6: Original document deleted, damaged, or unreadable

[0113] Namespace N6 is registered. Recruitment retrieval task T6 is bound to R1, L6, and OP1; after the results are generated, the original resume record H6 encounters one of the following errors: local source handle not found, content reading failed, or format corrupted.

[0114] The old local range L6 includes Q6, MAC6, M6, and H6, and their version relationships are still used to interpret historical results; after the local device detects an anomaly in the original, it sends a range failure event, making L6 no longer used for new retrieval or capabilities, and M6 cannot obtain readable file objects.

[0115] The old projection's PDI6 and Q6, the server registration record's A6, and the old valid range V6 only describe the data relationships at the time the result was formed; successful verification and authorization are not interpreted as the server having proven that the subsequent local original still exists.

[0116] The old capsule can still display H6, hit conditions, evidence identifiers, and versions, but its status is interpretable but not executable, and it is not used as a credential for the ability to open, export, or send.

[0117] The local closure determination objects are records A6, AP1, M6, and OP1. The candidate level is set to unclosed, and the original is distinguished as missing, damaged, or unreadable based on the opening result. Conditional relations are preserved, and the evidence level is marked as unresolvable.

[0118] All bits in the operational capability bitmap that depend on the original are disabled, and the local electronic device does not generate one-time credentials, immutable snapshot buffers, temporary files, or send queue items.

[0119] The typed failure object carries H6, failure type, L6, M6, the detected source revision, and the affected operation, but does not carry an absolute path that can be accessed by the server.

[0120] The nine categories of objects and their states in this embodiment are as follows: Recruitment retrieval task T6 is retained; original resume record H6 is in a missing, damaged, or unreadable state; the local candidate range L6 is closed due to a failure event; historical task restricted candidate projection PDI6 is no longer used as retrieval input; server-authorized candidate range A6 is no longer used as proof of local existence; the old valid retrieval range V6 is no longer accepted for new processing; the old candidate result capsule can only be interpreted; the local parsing mapping M6 cannot obtain readable file objects; the local closure determination sets the candidate-level and all original dependency operations to unclosed and prohibited positions. The system does not generate credentials, snapshots, or external results. Example 7: Permission Revocation and File Changes During Operations

[0121] Namespace N7, namespace registration version NSV7, and shared candidate binding rule version HRV7 are registered and active. Recruitment retrieval task T7 is bound to R1, L7, and OP7, allowing the export and sending of materials; the original resume record H7 has read permissions upon initial closure, with the file object identity being F7. Subsequent permissions are revoked during reading, stable attributes change, or the content identity changes from D7A to D7B.

[0122] The local scope L7 carries NSV7, HRV7, Q7, NCE7, MAC7, M7, and H7; the projection carries NSV7, HRV7, Q7, M7, S7, D7, and PDI7; the server generates A7, AP1, revocation generation RVG7, and authorization period AX7 from the registration record, and verifies their validity before retrieval and capsule formation, generating V7 and authorization context summary AUTHCTX7.

[0123] The capsule is bound to T7, R1, N7, NSV7, HRV7, L7, Q7, A7, AP1, AX7, V7, AUTHCTX7, M7, OP7, H7, conditional evidence, S7, and D7. The first local closure judgment is to pre-allocate operation identifiers and capability credential identifiers for export and send, and generate unused challenge values. The server authentication value is obtained, covering all confirmation fields and bound to the current authorization context confirmation object of SESSION7. After the server authentication value, request binding, freshness, anti-replay, confirmation validity period, and AX7 are all passed, a three-level closure is displayed, and the export and send capability bits are allowed.

[0124] The local device uses different one-time short-term credentials for export and send requests, including operation identifiers, capability credential identifiers, and bound task identifiers T7, candidate handles H7, F7, NSV7, HRV7, L7, A7, V7, S7, and AUTHCTX7. Both credentials are initially unused and no results are created. The export credential's send / dispatch status is "inapplicable," and the send credential's send / dispatch status is "not dispatched." The device records the stable attributes, content identity D7A, and permissions before F7 reads the data. It reads data from F7 to form an immutable snapshot buffer, simultaneously writing the export to an invisible temporary object and writing the send material to the undispatch queue item. Upon completion of temporary storage, operation submission records are created and set to "ready," while both credentials are set to "in progress."

[0125] After reading, the local device acquires stable attributes, content identity, and permissions for the same F7, and generates new unused confirmation challenge values ​​for the defined submission points of each operation type, and obtains confirmation objects bound to the same operation identifier and capability credential identifier. If the permission is revoked, a permission invalidation occurs; if the attribute or content identity changes to D7B, a read contention occurs; if the credential expires, the server authentication value is incorrect, the operation or session binding is inconsistent, the challenge value has been used, the confirmation sequence number is not incremented, the confirmation time exceeds the freshness window, the confirmation validity period expires, or the AX7 expires, respectively, capability invalidation, confirmation authentication failure, confirmation request mismatch, confirmation replay, confirmation expiration, or authorization expiration will occur.

[0126] The operation capability bitmap stores a three-level closed snapshot at the time of credential issuance, with the export and send bits enabled. Before the definitive commit point for each operation type, the challenge value is atomically consumed, the sequence number is accepted, and the definitive commit point for each operation type is skipped only if the server authentication value, operation and capability identifiers and session binding, challenge value is unused, sequence number is incremented, confirmation is fresh and within its validity period, authorization has not exceeded AX7, and all existing files and credentials have passed verification. In the event of any failure, the operation gating unit changes the target request to prohibited, the corresponding credential to revoked, the commit record to aborted before commit, and the result is discarded. If an interruption occurs after the definitive commit point for each operation type, the record remains committed and the credential remains consumed, and recovery is only possible based on idempotent references to immutable results.

[0127] For failures before commit, the operation gating unit closes F7, discards immutable snapshot buffers, temporary exported objects, and undispatched send queue items, terminates the target operation, and outputs the corresponding typed failure object from the categories of invalid permissions, read contention, capability failure, invalid acknowledgment authentication value, mismatched acknowledgment request, expired or replayed acknowledgment, and expired authorization. External results are not visible and cannot be dispatched, and the effective retrieval scope is not expanded. For interruptions after commit, the recovery process completes idempotent release or dispatch based on the immutable result references of the committed records, without reverting to a failure before commit or reusing credentials.

[0128] The nine types of objects and states in this embodiment are as follows: recruitment retrieval task T7 and operation strategy OP7 activities; original resume record H7 undergoing changes in permissions, stability attributes, or content identity during reading; task local candidate range L7, task restricted candidate projection PDI7, server authorized candidate range A7, effective retrieval range V7, candidate result capsule, local parsing mapping, and local closure judgment binding NSV7, HRV7, and AUTHCTX7. Local closure judgment saving allows snapshots during issuance; two credentials enter the process from unused and two commit records enter the prepared state; failure before any of the following before submission—file, confirmation authentication, freshness, anti-replay, or authorization period—causes the corresponding record to be aborted, credential revoked, and result discarded; after submission, interrupted branches retain committed and consumed branches and are idempotently released or dispatched based on immutable result references; the two types of branches are not merged. Example 8: Compliance Rebinding of Content Alternative Sources

[0129] Namespace N8, namespace registration version NSV8, and shared candidate binding rule version HRV8 are registered and active. Recruitment search task T8 is bound to R1, talent pool L8, and OP1; the original resume record H8-P81 is no longer available, but H8-P82 exists in the managed talent pool, with the same content and identity as P81, valid permissions, and belonging to L8.

[0130] The old scope L8V1, snapshot summary Q8A, mapping M8V1, projection PDI8A, and old capsules are all bound to the source revision of P81; after the local device discovers that P81 is unavailable, it revokes the old capabilities and marks the old capsules as diagnostics-only.

[0131] The local electronic device verifies the content identity, current access subject permissions, L8 attribution, and H8 association of P82. All four verifications must pass; otherwise, the rebinding process ends. After all four verifications pass, the local electronic device generates a new evidence location candidate in P82 based on the original text summary of E81, evidence type, and adjacent content characteristics. If this candidate cannot uniquely pass the content identity, candidate association, and condition association verifications, E81 remains open and does not generate any operational capabilities.

[0132] After verification is successful and NSV8 and HRV8 are still active, the local device forms a bound M8V2, L8V2, range snapshot digest Q8B, and range transmission authentication value MAC8B carrying a new random number NCE8B, and maps H8 and E81 to P82; L8V1 and the old capabilities remain disabled.

[0133] The local device forms a new projection bound to NSV8, HRV8, Q8B, M8V2, P82 source revision S82 and derived revision D82, and carries a projection integrity digest PDI8B; the server reconstructs and verifies A8 and AP1 from the registry records, forming V8V2 and a new license context digest AUTHCTX8B.

[0134] The server verifies the authorization twice, before the retrieval and before the capsule, and re-executes the retrieval to form new capsules bound to T8, R1, N8, NSV8, HRV8, L8V2, Q8B, A8, AP1, authorization period, V8V2, AUTHCTX8B, M8V2, OP1, H8, S82 and D82.

[0135] The local electronic device verifies the server authentication value and all versions of the new capsule, obtains the current authorization context confirmation object with the digest AUTHCTX8B, re-executes the three-level closure on the new capsule, generates a capability bitmap that allows the corresponding operation and binds the P82 file object, two handle versions, and a per-operation one-time short credential of AUTHCTX8B.

[0136] The nine types of objects and their states in this embodiment are as follows: Recruitment retrieval task T8 remains R1; the original resume record is replaced by an unusable P81 with a valid P82; the task's local candidate range is updated to L8V2; the task's restricted candidate projection is updated to PDI8B; the server-authorized candidate range A8 is valid after two re-checks; the valid retrieval range is updated to V8V2; the old candidate result capsule can only be diagnosed and forms a new candidate result capsule bound to the P82 source revision; the local parsing mapping is updated to M8V2; the local closure determination only recloses the new capsule and generates new capabilities. If any alternative source verification fails, the new object chain is not formed and related operations remain prohibited. Alternative implementation methods

[0137] The local candidate range can transmit a complete ordered set of handles, or it can use a set commitment and provide membership proofs as needed by the server. No factual evidence projections are transmitted during the range phase; projections are only sent locally for handles that have passed membership verification after the server has formed a valid intersection and returned an authenticated intersection set or membership proof.

[0138] The effective scope version is determined by the local scope, authorized scope, task, and three candidate binding dimensions; the authorized epoch identifier, authorized context summary, and set commitment are associated with the effective retrieval scope and this version. The authorized context summary covers twelve fixed authorized fields; the server calculates the current authorized context summary before retrieval, and calculates the current authorized context summary before capsule formation after a hit but before capsule formation, and compares them with the effective retrieval scope binding summary respectively. The current authorized context confirmation object separately carries the single confirmation time, sequence number, challenge value, and confirmation period, and the current summary is recalculated according to the fields used when the capsule was bound and compared with the capsule summary.

[0139] Candidate handles can be opaque identifiers obtained by sharing a random binding token with a key digest. New tokens and versions are generated when binding records collide, are revoked, or rotate; a valid intersection does not occur if both ends do not confirm the same active binding version. Candidate handles do not contain local absolute paths.

[0140] Task-restricted candidate projections can be transmitted in batches by candidate or factual evidence unit, but each batch must occur after the corresponding valid range has been confirmed, and must carry the valid range version and verifiable intersection membership; the server rejects units that do not belong to the current intersection.

[0141] Retrieval algorithms can be single-stage or multi-stage, and can switch between structured retrieval, keyword retrieval, vector retrieval, graph relation retrieval, and language model semantic retrieval. The relevance calculation of the retrieval algorithm does not change the constraints of the input and output range adapters on valid candidate handles.

[0142] The server integrity authentication value of the candidate result capsule and the server authentication value of the current authorization context confirmation object can both adopt server digital signatures or message authentication codes bound to the device session; these are independent authentication values ​​for different objects. The former covers all closed fields of the capsule; the latter deterministically covers all required fields in the confirmation object except itself, including operation identifier, capability credential identifier, device session identifier, confirmation challenge value, confirmation sequence number, confirmation time, confirmation validity period, and authorization validity period. The communication link can also be encrypted, but encryption cannot replace independent verification of request binding, freshness, replay protection, validity period, and local originals.

[0143] Evidence relocation can employ precise matching of the original text summary, matching after text normalization, local content summarization, page layout features, or table structure features. The mapping is updated only when all pre-defined identity and association conditions are met; otherwise, it remains open.

[0144] Operational capability credentials are implemented by local protected objects, with each operation having an independent identifier, credentials, and record. Final side effects do not require a single transaction across the file system, database, messaging system, and interface; export, business record, send, and interface release employ atomic renaming, database transactions or CAS, transactional sender mailboxes, and idempotent rendering, respectively, and determine whether to abort before commit or recover after commit based on their respective recoverable commit points. Exception handling

[0145] Scope closure failure types include at least task inconsistency, shared candidate binding namespace inconsistency, namespace registration version or shared candidate binding rule version conflict, local scope failure, authorized scope failure, unavailable authorized context, inconsistent version association, and empty intersection. The server performs the same scope-level empty set and retrieval suppression actions on these types, and retains different types in the failure objects for the upper layer to decide whether to reformulate the scope, without using candidate-level placeholder objects to represent scope failure.

[0146] Capsule association failure types include at least integrity verification failure, inconsistent recruitment requirement versions, inability to associate local scope versions, inability to associate authorized scope versions, and inability to associate valid scope versions. Authorization confirmation failure types include at least invalid server authentication value, mismatch between operation or capability identifier or session, confirmation expiration, confirmation replay, authorization expiration, and inconsistent authorization context digest. For these types before credential issuance, local electronic devices do not parse the original document or generate operation capability credentials; for these types before the determined commit point for each operation type, submission is aborted, credentials are revoked, and temporary results are discarded.

[0147] Original file failure types include at least original file missing, original file unreadable, original file corrupted, permission invalidated, and read contention. Original file missing is determined by the source handle being unable to resolve to the file object; original file corrupted is determined by the failure to read the specified format or the failure of content identity verification; read contention is determined by the inconsistency between the file object identity at the time of closure and at the time of operation, or by the inconsistency between the stable attributes or content identity of the same opened file object before and after reading.

[0148] Evidence failure types include at least invalid locators, inconsistent evidence content, inconsistent candidate associations, inconsistent conditional associations, and non-unique relocation. Evidence failure may disable only operations that depend on the corresponding evidence, while candidate-level failure disables all operations that depend on the original document.

[0149] For each failed object, the system can record the task identifier, candidate handle, involved version, failure type, affected condition identifier, evidence identifier, and operation type. The local source handle in the record can be stored locally only; records sent to the server do not include absolute paths.

[0150] When the intersection is empty or the range check fails, the server completes the closure by terminating candidate projection reading, maintaining an empty candidate set, not creating capsules, and not invoking the retrieval component. Before local closure or the defined commit point for each operation type, if server authentication, freshness, replay protection, confirmation validity period, authorization validity period, or other checks fail, the local electronic device completes the closure by keeping the results invisible, revoking the corresponding credentials, closing the file object, discarding the snapshot buffer and temporary results, and terminating the operation. After the defined commit point for each operation type, if the operation is interrupted, the result is released or dispatched based on the committed operation-by-operation commit records and immutable result references with idempotency, without reverting to an uncommitted state or consuming credentials again. No abnormal recovery action is performed by adding candidates or searching other directories.

[0151] If a network interruption occurs after the range is formed but before the candidate result capsule is returned, the local electronic device can retry sending the same task and version object; the server uses the task identifier and version field to determine whether to reuse the formed result. If any version has changed, the valid range is recalculated without marking the old capsule as the new version result.

[0152] When a network interruption occurs after the capsule returns, the local electronic device can verify the capsule's integrity and local originals. However, when issuing operation credentials and before the final commit point for each operation type, it must still obtain a confirmation object bound to the same operation identifier, capability credential identifier, and device session using the new unused challenge value at each stage. It must also verify the server authentication value, confirmation freshness, confirmation validity period, anti-replay status, and authorization validity period. If this cannot be obtained or any verification fails, the corresponding operation capability bit or commit request remains prohibited, and the effective search scope is not expanded. Operations that have passed the final commit point for each operation type can only be idempotently released or dispatched based on the committed record and immutable result reference. Systems, devices and storage media

[0153] like Figure 1 As shown, the local and server systems separate the scope phase and projection phase through a valid scope confirmation gate. Shared candidate binding units ensure that the handles at both ends are comparable; the valid scope object is associated with the valid scope version, authorization epoch identifier, authorization context digest, and set commitment. The scope-restricted retrieval unit calculates and compares the current authorization context digest before retrieval, and the result capsule forming unit calculates and compares the current authorization context digest before capsule formation after a hit but before capsule formation. During candidate operations, local unit 150 and server unit 250 form independent confirmation round trips; failure at any point in time closes the corresponding action.

[0154] The server includes candidate binding, authorization scope, valid scope, valid scope confirmation, scope-restricted retrieval, and capsule formation units. The valid scope confirmation unit returns an authenticated intersection set or membership proof before receiving factual evidence projection; the projection receiving unit only receives intersection member projections bound to the current valid scope version.

[0155] The local electronic device includes candidate binding, range formation, parsing mapping, valid range verification, intersection candidate projection, closure, and operation-by-operation commit units. The operation-by-operation commit unit maintains different commit and recovery fields for files, databases, outboxes, and interface states, and records credential consumption and external side effect states respectively.

[0156] Non-transitory computer-readable storage media may store programs that cause a processor to perform local-side or server-side steps, including shared candidate binding, range expression, intersection confirmation, intersection candidate projection, stable authorization epoch separation and single confirmation separation, result capsule closure, and resumable submission selected by side effect type.

[0157] The division of units is used to illustrate functional relationships, and in actual implementation, they can be merged or split. As long as data processing still maintains the versioned valid intersection of the local scope and the server's independent authorization scope under the common namespace and the two active handle versions, the separate verification of the three types of integrity quantities, the continuity of the authorization context digest in the valid scope, capsule, closure, per-operation credentials and commit records, the three-level closure before the operation, and the determination of the commit point for each operation type per operation, different software, hardware or software-hardware combinations can be used to implement it; any operational capability after source revision or source change is regenerated by a completely new chain.

[0158] The technical features in the above embodiments can be combined without contradiction. For those skilled in the art, equivalent changes can be made to the encoding form, communication method, and module deployment location of the object without departing from the scope of the present invention, provided that the transmission, result capsule, and operation closure relationship are not affected. Valid scope, evidence closure and anomaly recovery implementation methods

[0159] In this implementation, cross-device transmission is divided into a scope phase and a projection phase. The scope phase only transmits verifiable scope representations; after the server independently forms the authorized scope and calculates the valid intersection, it returns the valid candidate set or membership proof to the local machine through the authenticated valid scope confirmation object. The projection phase only transmits task-restricted candidate projections that can be proven by the confirmation object to belong to the valid intersection; therefore, the server neither receives nor caches candidate factual evidence projections before the intersection is formed.

[0160] The registration service shared by the server or local electronic device and the server establishes candidate binding records for the same natural candidate in both the local registration domain and the server registration domain. The registration identifiers at both ends are used only to locate the record; the record is associated with the same random binding token. Both ends use this random binding token as the HMAC key to calculate the candidate handle using a canonical sequence of the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version. The server or registration service rejects collisions and performs token rotation.

[0161] The local scope forming unit calculates a scope snapshot digest for the task identifier, requirement version, talent pool and generations, shared candidate binding namespace, rule version, local scope version, and sorted handle set, and protects the issuance time, duration, and random number with a device session key or device signature. Verifiable scope expressions do not contain fact values, evidence text, source file paths, or original file opening capabilities. The server first verifies the authenticity, freshness, replay protection, and version activity status of the expression before starting the authorized scope calculation.

[0162] The server authorization scope forming unit generates an authorization epoch identifier and calculates an authorization context digest using fixed fields. These fixed fields include the access subject, device session, talent pool, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, valid candidate handle set commitment, and authorization validity period; single confirmation fields and the digest are stored separately.

[0163] The valid range forming unit intersects two sorted handle sets and forms a commitment to a valid candidate handle set. The valid range confirmation object carries the sorted intersection, or carries the set commitment and membership proof; the server signature or session message authentication value covers the task, range version, authorization epoch identifier, authorization context digest, set commitment, and set or proof.

[0164] Upon receiving a valid scope confirmation object, the local device verifies the authentication value, task and scope version, authorization epoch, valid scope version, and membership proof. Only after successful verification does the intersection candidate projection unit select relevant facts from the existing local evidence profile to form a projection integrity summary bound to the valid scope version. If the confirmation object expires, the intersection is empty, or any membership proof fails, the local device does not form a transport projection and outputs a scope-level failure.

[0165] When the server receives a projection, it verifies the task, candidate handle, effective scope version, projection integrity summary, and membership. Before executing a search, the server reads the current values ​​of each field used when forming the effective search scope binding summary, calculates the current authorization context summary before the search, and compares it with the effective search scope binding summary; the search is only executed if the summaries are identical and the status, revocation generation, and expiration period all pass; otherwise, the search is rejected. After a search results in a hit but before capsule formation, the server reads the same fields again, calculates the current authorization context summary before capsule formation, and compares it again; only if this comparison passes again is a candidate result capsule bound to that summary formed; otherwise, capsule formation is rejected.

[0166] The current authorization context confirmation request binds the authorization epoch identifier and the authorization context digest bound to the candidate result capsule. The server rereads the current values ​​of each field used when forming the capsule digest and calculates the current authorization context digest. A confirmation object is formed only if the current digest equals the request-bound digest and the authorization status, revocation generation identifier, and authorization validity period all pass; otherwise, the confirmation object is rejected. The confirmation object binds the single operation identifier, capability credential identifier, device session, unused challenge value, incrementing confirmation sequence number, confirmation time, and confirmation validity period, and references the stable authorization epoch identifier and the current authorization context digest; the server signature or session message authentication value covers all fields.

[0167] Different candidate operations use different commit protocols based on their side effect boundaries. Export operations form file system commit points using temporary files in the same directory, content synchronization, content summaries, and atomic renaming; database candidate lists or reports form commit points using the same database transaction; send operations form local commit points using transactional outbox records and credential consumption, with external dispatching completed by a dispatcher carrying an idempotent message identifier; interface release forms commit points by comparing and exchanging operation states. The recovery process only determines whether an operation is committed or uncommitted within the boundaries of its corresponding resource, without assuming these resources participated in the same distributed transaction.

[0168] The local independent implementation includes candidate binding record location, range expression sending, valid range confirmation and set proof verification, intersection candidate projection, capsule verification, current authorization context confirmation request and verification, comparison of current digest and capsule digest, three-level closure and operation-by-operation recoverable submission.

[0169] The server-side independent implementation includes shared candidate binding, verifiable range expression verification, server-authorized range formation, effective intersection calculation, effective range confirmation, and intersection projection reception. Before range-limited retrieval and before the result capsule is formed, it rereads twelve summary fields, recalculates the current summary, compares it with the effective range-bound summary, and closes upon failure. In response to candidate operation confirmation requests, it rereads the fields used when forming the capsule summary, calculates the current summary, compares it with the capsule summary, and only forms and returns a confirmation object upon successful completion. This implementation does not require the server to obtain local absolute paths or the ability to open original files.

[0170] In the system implementation, a valid range confirmation gate is set between the local range forming unit and the intersection candidate projection unit; the server range-limited retrieval unit and the result capsule forming unit are respectively set with full-field summary verification gates, and the corresponding actions are rejected when the summaries are different or when the status, revocation generation, or deadline fails. The local unit 150 sends a request to the server unit 250 to bind the capsule summary. Unit 250 recalculates the current summary according to the capsule summary fields and returns a confirmation object if they are consistent and the authorization is valid; otherwise, it refuses to form a confirmation object. Only after unit 150 compares again is the local closure unit 320 allowed to continue.

[0171] Electronic devices can function independently as either local or server-side devices. Non-transitory computer-readable storage media store programs that enable local electronic devices to execute local methods or servers to execute server methods, according to the device's role; a single device is not required to simultaneously hold both local originals and server authorization records.

[0172] When candidate binding records are rotated, the server or registration service first creates a new random binding token and a new rule version. After both ends confirm that they can form the same new handle, the new version is activated, and then the old version stops receiving new tasks. An ongoing old task can only complete the prepared operation within its specified time limit and cannot form a new valid scope with the old version; the scope remains closed when a conflict is confirmed.

[0173] Anomaly types include, at a minimum, missing binding records, handle collisions, expired or replayed range expressions, invalid authorization epochs, failed membership proofs, projections exceeding the intersection, inconsistent capsule versions, invalid originals or evidence, and failed per-operation commits. Each anomaly only disables the search or operation within its scope of responsibility; recovery is not achieved by expanding the candidate scope, sending unconfirmed projections, or reusing one-time credentials.

[0174] Taking file export as an example, the operation record stores the temporary path, target path, content digest, and credential identifier in the PREPARED state; after a successful atomic renaming, even if the process fails to immediately mark the record as COMMITTED, the recovery program can compare the target file digest and idempotently complete the record. Taking sending as an example, COMMITTED indicates that the outbox record and credential consumption have been completed in the local transaction, but does not mean that the external recipient has received it; the dispatch status and receipt status are updated separately.

[0175] The technical boundaries of this invention are the verifiable intersection of the local candidate existence range and the server-authorized range, the minimum projection transfer after the intersection, the closure of the result to the local original, and the operation-by-operation recoverable submission. This invention does not focus on the internal extraction, translation, normalization, and index maintenance methods for constructing a resume evidence profile; the local preprocessing chain can employ other methods capable of outputting factual evidence units and evidence identifiers. Candidate Binding, Authorization Confirmation, and Actor Boundary Implementation Methods

[0176] This implementation uses the following unique, standardized terminology: shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization epoch identifier, authorization context digest, current authorization context digest, current authorization context confirmation object, and commitment to the set of valid candidate handles. The first three are collectively referred to as the three candidate binding dimensions. These terms have the same meaning in the claims, specification, abstract, and drawings.

[0177] Candidate binding records use the local candidate registration identifier and the server candidate registration identifier as lookup keys. These two registration identifiers are not included in handle computation; the same random binding token for controlled associations is used as the key with a key digest function, and a canonical sequence of shared candidate binding namespace, namespace registration version, and shared candidate binding rule version serves as message input.

[0178] The server forms a valid candidate handle set commitment for the set of valid candidate handles for the ordering. A valid range confirmation object may carry the complete ordering set, or it may carry the set commitment and a membership proof for each proposed project handle; the membership proof is valid only if it can be recalculated relative to the same set commitment. The task, range version, authorization epoch identifier, authorization context digest, set commitment, and set or proof in the object are all overridden by the server signature or session message authentication value.

[0179] The fixed overriding fields of the authorization context digest are: access subject, device session, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, valid candidate handle set commitment, and authorization validity period. Any change to any of these overriding fields will generate a new digest and invalidate the original digest.

[0180] The current authorization context confirmation request binds the authorization epoch identifier and capsule digest. The server recalculates the current authorization context digest based on the current values ​​of each field used when forming the authorization context digest bound to the candidate result capsule and compares it with the capsule digest. If they are the same and the authorization status, revocation epoch identifier, and authorization validity period are all passed, the confirmation object references the current digest and separately carries the operation identifier, capability credential identifier, device session, unused challenge value, confirmation sequence number, confirmation time, and confirmation validity period; otherwise, the confirmation object is rejected. Single-time fields are not written into the digest, and the server signature or session message authentication value overrides all confirmation fields.

[0181] The local electronic device method forms a complete local actor chain from candidate binding record location, range representation, valid range confirmation and verification, projection, capsule retrieval, current authorization context confirmation request and verification, comparison of current summary and capsule summary, three-level closure to local side effect submission. Its subordinate result closure and operation-by-operation submission steps do not require the server to perform local original document reading.

[0182] The server method extends from locating candidate binding records, forming authorization scopes, valid intersections and set commitments, authentication and verification of projected members, to reading twelve fixed fields before retrieval and before capsule formation, calculating the current summary, comparing it with the valid scope binding summary and closing it if it fails, and further extending to calculating the current summary according to the capsule summary fields after receiving the candidate operation confirmation request, comparing it with the capsule summary, and forming and returning the current authorization context confirmation object only if it passes, thus forming a complete server actor chain. The server does not perform local parsing mapping, original opening, or local side-effect submission.

[0183] Electronic devices and non-transitory computer-readable storage media store or execute native or server-side methods according to their device roles. A single device is not required to simultaneously hold both native and server-side authorization records, nor is it required to execute all steps at either end of a collaborative method.

[0184] In the set proof example, the server forms a commitment C for the sorted set of valid handles H1, H3, and H8, and returns a proof P for H3. The device first verifies the server's authentication value, and then recalculates C using P and H3; if the object being verified is missing C, P cannot recalculate C, or the authentication value does not cover C, then the projection of H3 remains closed. Data processing compliance boundaries

[0185] The resumes and candidate data involved in this instruction manual shall be obtained legally and processed within the authorized purpose and scope; system output shall not be based solely on discriminatory factors prohibited by laws and regulations in making recruitment decisions. This instruction manual does not change the aforementioned technical process and technical effect judgment regarding the intersection of verifiable scopes, task-limited projection, authorization confirmation, evidence closure, and operation-by-operation submission.

Claims

1. A method for retrieving resumes in collaboration between a local talent pool and a cloud-based system, characterized in that: include: Under an authenticated device session, local electronic devices and servers register a shared candidate binding namespace, a namespace registration version, a shared candidate binding rule version, and a candidate binding record for the same managed talent pool. The candidate binding record uses the local candidate registration identifier and the server candidate registration identifier as record location information and associates the two with the same random binding token. The local electronic device and the server respectively locate the candidate binding record, and form a comparable candidate handle only based on the canonical sequence of the same random binding token obtained from the candidate binding record, the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version; the local electronic device obtains a recruitment retrieval task, forms a task local candidate range and a local parsing mapping maintained only by the local electronic device based on the original resume records in the managed talent pool, and sends a verifiable range expression of the task local candidate range to the server without sending a candidate factual evidence projection, the verifiable range expression being at least bound to... The system includes a task identifier, a recruitment requirement version, a talent pool identifier, a talent pool generation identifier, the shared candidate binding namespace, the namespace registration version, the shared candidate binding rule version, a local range version, a set of candidate handles arranged in a defined order, a range snapshot digest, a validity period, a random number, and a range transmission authentication value. The server verifies the verifiable range expression, independently forming server-authorized candidate ranges and authorized range versions from the server-side candidate registration records according to the access subject, device session, talent pool affiliation, and authorization policy. These are only defined in the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version. When all are identical, the intersection of the local candidate scope of the task and the candidate handle set in the authorized candidate scope of the server is taken to form the effective retrieval scope, effective scope version, authorization epoch identifier, and effective candidate handle set commitment; the server calculates the authorization context digest for the canonical sequence of access subject, device session, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, effective candidate handle set commitment, and authorization validity period; the server combines the authorization epoch identifier and the authorization context... The summary and the commitment of the set of valid candidate handles are associated with the valid retrieval scope and the version of the valid scope; the server returns a valid scope confirmation object to the local electronic device, the valid scope confirmation object being bound to at least the task identifier, the local scope version, the authorized scope version, the valid scope version, the authorized epoch identifier, the authorized context summary, the commitment of the set of valid candidate handles, and a set of valid candidate handles arranged in a determined order or a membership proof that can verify the membership of candidate handles relative to the commitment of the set of valid candidate handles, and carrying a server signature or session message authentication value covering the aforementioned fields;After verifying the server signature or session message authentication value, version relationship, and the set of valid candidate handles or membership proof of the valid scope confirmation object, the local electronic device selects factual evidence units related to the recruitment retrieval task from the local preprocessing chain only for candidates verified to belong to the valid retrieval scope to form a task-restricted candidate projection, and sends the task-restricted candidate projection to the server. The task-restricted candidate projection is bound to the task identifier, the valid scope version, candidate handle, evidence identifier, source revision version, derived revision version, and projection integrity digest, and does not contain the absolute path of the resume original, the ability to open the original, local parsing mapping, or original text unrelated to the recruitment retrieval task. The server verifies that the candidate handle of the task-restricted candidate projection belongs to the valid retrieval scope and verifies the valid scope version and projection integrity digest. Before performing the AI ​​resume retrieval, the current values ​​of each field used when forming the authorization context digest bound to the valid retrieval scope are reread and the pre-retrieval values ​​are calculated. The current authorization context summary is compared with the authorization context summary bound to the effective search range, and the authorization status, revocation generation identifier, and authorization validity period corresponding to the authorization epoch identifier are verified. Only when the two summaries are identical and the aforementioned verification passes, an AI resume retrieval is performed on the task-restricted candidate projection; otherwise, the AI ​​resume retrieval is not performed. After the AI ​​resume retrieval produces a hit but before forming a candidate result capsule, the current values ​​of the aforementioned fields are read again and the current authorization context summary before capsule formation is calculated. This current authorization context summary before capsule formation is compared with the authorization context summary bound to the effective search range, and the authorization status, revocation generation identifier, and authorization validity period corresponding to the authorization epoch identifier are verified again. Only when the two summaries are identical and the aforementioned verification passes, a candidate result capsule is formed, binding the current authorization context summary before capsule formation, the effective range version, the conditional evidence pair, and the source revision version; otherwise, the candidate result capsule is not formed. Before performing any of the following candidate operations—opening the original resume, adding to the candidate list, exporting, generating a report, or sending candidate materials—the local electronic device pre-assigns an operation identifier and a capability credential identifier for that candidate operation. It then generates an unused challenge value and sends a candidate operation confirmation request to the server, binding the authorization epoch identifier and the authorization context summary bound to the candidate result capsule. The device obtains the authorization epoch identifier and the current authorization context summary recalculated by the server based on the current values ​​of each field used when forming the authorization context summary bound to the candidate result capsule, and compares this with the operation identifier, the capability credential identifier, the device session, and the unused challenge value. The system confirms the current authorization context confirmation object bound to the confirmation sequence number, confirmation time, and confirmation validity period. It verifies the server signature or session message authentication value, request binding, single confirmation freshness, current authorization status, and authorization validity period of the current authorization context confirmation object. It compares the current authorization context digest with the authorization context digest bound to the candidate result capsule and verifies the integrity of the candidate result capsule. Only when the two digests are the same and the aforementioned verification passes, it performs candidate-level, condition-level, and evidence-level closure on the existing resume original, access permissions, source revision version, and evidence location according to the local parsing mapping. The closure constitutes a three-level closure and forms a per-operation capability bit. And only for per-operation capability bits in the allowed state, a one-time operation capability credential is generated, referencing the operation identifier and the capability credential identifier. The one-time operation capability credential is consumed according to the side effect type of the candidate operation using the corresponding recoverable submission protocol. Among them, file export uses temporary files, content digests and atomic renaming; adding to the candidate list and report records uses database transactions or comparison and exchange; sending candidate materials uses persistent mailbox records and idempotent message identifiers in the same transaction as credential consumption; and releasing interface results uses comparison and exchange of status records and idempotent rendering. When the pre-submission verification fails, the corresponding operation record enters the pre-submission abort state and the temporary result is discarded. When the post-submission interruption occurs, it is restored according to the idempotent identifier and immutable result reference without consuming the one-time operation capability credential again.

2. A method for retrieving resumes from a local talent pool and in collaboration with the cloud, executed by a local electronic device, characterized in that: include: Candidate binding records are located using local candidate registration identifiers. A random binding token shared with server-side records is obtained from these records. Candidate handles are formed based on the random binding token, shared candidate binding namespace, namespace registration version, and shared candidate binding rule version. A task-local candidate range, local resolution mapping, and verifiable range expression are formed. The verifiable range expression is sent to the server first, without sending candidate fact evidence projections. A valid range confirmation object is obtained and verified, consisting of the server's commitment to a set of valid candidate handles formed based on the intersection of the local range and the server's authorized range, and the server's signature or session message authentication value. Task-restricted candidate projections are formed and sent only to candidates verified as valid members by a valid sorted set or a membership proof relative to that set. Candidate result capsules are obtained, and candidate operations are pre-allocated. The system generates an operation identifier and a capability credential identifier, generates an unused challenge value, and sends a candidate operation confirmation request to the server, binding the authorization epoch identifier and the authorization context digest bound to the candidate result capsule. It obtains and verifies the current authorization context confirmation object bound to the operation identifier, the capability credential identifier, and the unused challenge value, as well as the current authorization context digest recalculated by the server. It compares the current authorization context digest with the authorization context digest bound to the candidate result capsule, and performs candidate-level, condition-level, and evidence-level closures only if they are identical and the verification passes. These closures constitute a three-level closure and form a per-operation capability bit. Only for per-operation capability bits in an allowed state, a one-time operation capability credential referencing the operation identifier and the capability credential identifier is generated, and a per-operation recoverable submission is performed according to the side effect type of the candidate operation.

3. A method for collaborative resume retrieval between a local talent pool and a cloud platform, executed by a server, characterized in that: include: The candidate binding record is located by the server candidate registration identifier. A random binding token shared with the local electronic device side record is obtained from the candidate binding record. A candidate handle is formed based on the random binding token, the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version. The verifiable range expression sent by the local electronic device when no candidate fact evidence projection is sent is received. The server authorized candidate range and the authorized range version are independently formed and their intersection is taken with the candidate handle set in the verifiable range expression. The process involves: forming a valid search scope, a valid scope version, an authorization epoch identifier, a valid candidate handle set commitment, and an authorization context digest; associating the authorization epoch identifier, the authorization context digest, and the valid candidate handle set commitment with the valid search scope and the valid scope version; forming and returning a valid scope confirmation object that binds the valid candidate handle set commitment, a valid sorted set or membership proof, and a server signature or session message authentication value; receiving task-restricted candidate projections after returning the valid scope confirmation object; verifying that each task-restricted candidate projection belongs to the valid search scope; and before performing the AI ​​resume retrieval, rereading the current values ​​of the access subject, device session, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, valid candidate handle set commitment, and authorization validity period, and calculating the current authorization status before the retrieval. The following summary describes a process where the current authorization context summary before retrieval is compared with the authorization context summary bound to the effective retrieval range, and the authorization status, revocation generation identifier, and authorization validity period corresponding to the authorization epoch identifier are verified. Only when the two summaries are identical and the aforementioned verification passes, an AI resume retrieval is performed on the verified task-restricted candidate projection; otherwise, the AI ​​resume retrieval is not performed. After the AI ​​resume retrieval produces a hit but before forming a candidate result capsule, the current values ​​of the aforementioned fields are read again, and the current authorization context summary before capsule formation is calculated. This current authorization context summary before capsule formation is compared with the authorization context summary bound to the effective retrieval range, and the authorization status, revocation generation identifier, and authorization validity period corresponding to the authorization epoch identifier are verified again. Only when the two summaries are identical and the aforementioned verification passes, a candidate result capsule bound to the current authorization context summary before capsule formation is formed; otherwise, the candidate result capsule is not formed. The system receives confirmation requests sent by local electronic devices for candidate operations, which bind the authorization epoch identifier and the authorization context digest bound to the candidate result capsule. It rereads the current values ​​of each field used when forming the authorization context digest bound to the candidate result capsule and calculates the current authorization context digest accordingly. It compares the current authorization context digest with the authorization context digest bound to the confirmation request. Only when both are identical and the current authorization status, revocation generation identifier, and authorization validity period corresponding to the authorization epoch identifier all pass verification, it forms and returns a current authorization context confirmation object referencing the authorization epoch identifier and the current authorization context digest, and binding the operation identifier, capability credential identifier, device session, unused challenge value, confirmation sequence number, confirmation time, and confirmation validity period, with the aforementioned fields overwritten by a server signature or session message authentication value. If the two digests are different or the aforementioned verification fails, it refuses to form the current authorization context confirmation object.

4. The method according to claim 1 or 3, characterized in that, The candidate binding record is issued by a server or a registration service shared by a local electronic device and a server. It includes a random binding token identifier and is controlled to be associated with the random binding token. It also includes a shared candidate binding namespace, a namespace registration version, a shared candidate binding rule version, an activity status, a revocation generation, and a rotation generation. The local candidate registration identifier and the server candidate registration identifier are only used to locate the candidate binding record and are not used for candidate handle calculation. The candidate handle is calculated by a key digest function using the random binding token as the key, on the canonical sequence of the shared candidate binding namespace, the namespace registration version, and the shared candidate binding rule version. The server or the registration service rejects handle collisions within the same active namespace and generates a new random binding token when a binding record is revoked, a token is leaked, or a rule version is rotated, preventing the old candidate handle from participating in new intersections.

5. The method according to claim 1 or 3, characterized in that, The authorization context digest is calculated within the same authorization epoch as a canonical sequence of access subject, device session, talent pool identifier, shared candidate binding namespace, namespace registration version, shared candidate binding rule version, authorization scope version, authorization policy version, revocation generation identifier, authorization status, valid candidate handle set commitment, and authorization validity period. The confirmation time, confirmation sequence number, confirmation challenge value, and confirmation validity period are not included in the authorization context digest. The server protects the valid scope confirmation object and the current authorization context confirmation object with server signature or session message authentication value, respectively, and forms a new authorization context digest and invalidates the original authorization context digest when any of the aforementioned fixed overlay fields changes. When a candidate operation is confirmed, the server recalculates the current authorization context digest based on the current values ​​of all the aforementioned fixed overlay fields.

6. The method according to claim 1 or 2, characterized in that, The candidate result capsule is also bound to the recruitment demand version, talent pool generational identifier, local scope version, authorized scope version, authorization strategy version, local parsing mapping version, operation strategy version, candidate handle, evidence identifier set, derived revision version, retrieval component version, and server integrity authentication value. The local electronic device compares the candidate result capsule item by item with the local task, scope, mapping, and operation strategy status, and only opens candidate operations that depend on the corresponding evidence when the content identity, access permissions, source revision version, and evidence location of the currently opened file object have all passed the verification.

7. The method according to claim 1 or 2, characterized in that, The step-by-step recoverable commit is one of the following: For exported files, first write to a temporary file in the same directory and synchronize the data, record the target path and content summary, and then perform an atomic rename. During recovery, determine whether the commit has been made based on the target file summary; For adding to the candidate list or generating a report, compare the unconsumed status of one-time operation capability credentials in the same database transaction, write to the business record, and mark the credentials as consumed. For sending candidate materials, a persistent sender box record with an idempotent message identifier is written in the same database transaction and the credentials are marked as consumed. The dispatcher then retryes according to the idempotent message identifier. For releasing interface results, the operation record states are compared and exchanged, and idempotent rendering is referenced based on the immutable results. Each operation does not require the file system, database, messaging system, and interface state to participate in the same distributed transaction.

8. A local talent pool and cloud-based collaborative resume retrieval system, characterized in that, The system includes a local electronic device and a server. The local electronic device includes a candidate binding record location unit, a local range formation unit, a local parsing mapping unit, a valid range confirmation and verification unit, an intersection candidate projection unit, a current authorization context confirmation request and verification unit, a local closure unit, and an operation-by-operation submission unit. The server includes a candidate binding record location unit, an authorization range formation unit, a valid range and set commitment formation unit, a valid range confirmation unit, a range-limited retrieval unit, a result capsule formation unit, and a current authorization context confirmation unit. The valid range and set commitment formation unit is configured to associate the authorization epoch identifier, authorization context digest, and valid candidate handle set commitment with the valid retrieval range and valid range version. The range-limited retrieval unit is configured to reread the fields used when forming the authorization context digest bound to the valid retrieval range before performing the retrieval and calculate the current authorization context digest before the retrieval. The current authorization context digest before the retrieval is compared with the authorization context digest bound to the valid retrieval range, and the comparison is performed only when the two digests are the same and the authorization status, revocation generation identifier, and authorization validity are all valid. The retrieval is performed only when all time limits pass the verification; otherwise, the retrieval is rejected. The result capsule forming unit is configured to read the aforementioned fields again and calculate the current authorization context summary before capsule formation after a retrieval hit occurs and before the formation of a candidate result capsule. The current authorization context summary before capsule formation is compared with the authorization context summary bound to the effective retrieval range. A candidate result capsule bound to the current authorization context summary before capsule formation is formed only when the two summaries are the same and the authorization status, revocation generation identifier, and authorization validity period all pass the verification; otherwise, the formation of a candidate result capsule is rejected. The current authorization context confirmation unit is configured to receive a confirmation request, reread the fields used when forming the authorization context summary bound to the candidate result capsule and calculate the current authorization context summary, compare the current authorization context summary with the authorization context summary bound to the candidate result capsule, and form an identified and confirmed object only when the two summaries are the same and the authorization status, revocation generation identifier, and authorization validity period all pass the verification; otherwise, the formation of the identified and confirmed object is rejected. Each unit is configured to execute the method described in claim 1.

9. An electronic device, comprising a processor, a memory, and a communication interface, characterized in that, The memory stores a computer program, which, when executed by the processor, causes the electronic device to perform the method of claim 2 as a local electronic device or to perform the method of claim 3 as a server, depending on the device role of the electronic device.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor of the electronic device, the electronic device, depending on its device role, performs the method of claim 2 as a local electronic device or performs the method of claim 3 as a server.

Images