Multi-format multi-language resume evidence portrait construction method and system

Abstract

The application discloses a multi-format multi-language resume evidence image construction method and system. The system forms an immutable snapshot from the same opened file object, saves source byte revision identification and content equivalence identification respectively, establishes cross-format positioning, source image area and OCR transcription separation evidence object and versioned dependency graph. After state partition, only the fields meeting the index access rules and having valid positioning can form or maintain the current effective index; when the CAS succeeds, the access state is atomically updated and the versioned event is written into the persistent mailbox, the index writer consumes the event to add, replace or remove the corresponding machine index record, and refuses the obsolete or conflict event to cover the current state. When the source byte changes, a replacement or tombstone event is generated and the vector record is atomically switched, preventing the invalid fields from being recovered by out-of-order or replay.

Description

Technical Field

[0001] This invention relates to the fields of electronic document processing, natural language processing, and computer information retrieval technology, and in particular to a method and system for constructing evidence profiles associated with the original text location from resumes of different file formats and languages, and controlling machine retrieval of index fields based on the evidence status and location validity. Background Technology

[0002] The talent information system accepts resumes in various file formats, including searchable PDF, scanned PDF, DOCX, XLSX, and images. A single file may also contain multiple languages, tables, text boxes, columns, and image text. Different formats use different placement methods for pages, paragraphs, text flow, cells, and image areas.

[0003] Current resume processing methods typically involve first converting the file into plain text or a uniform structure, and then extracting fields such as name, position, organization, skills, and length of service. While a uniform structure facilitates subsequent calculations, it can easily lose the correspondence between derived fields and specific revisions and original positions in the source file during the conversion process.

[0004] When translating and standardizing multilingual resumes, the original expressions, the translated results, and the standardized concepts may be stored as the same field value. Consequently, machine retrieval indexes cannot distinguish between content explicitly stated in the source document and derived content obtained through translation or concept mapping.

[0005] Job titles, organizations, responsibilities, skills, and start and end dates in a work experience are often scattered across different document areas. If each field is extracted independently and then directly merged, it may combine facts from different job stages into experiences not recorded in the original documents.

[0006] The following situations—such as a resume omitting a fact, the original text explicitly denying a fact, text recognition failing to reliably obtain a fact, and conflicting information from different fragments—each have different implications for data processing. If all of these situations are represented by null values, Boolean values, or single confidence scores, differentiated control cannot be implemented during subsequent index writing.

[0007] Once derived fields have been written into the machine retrieval index, changes to the source file, failure of local locators, or failure of local parsing may cause the derived fields to lose their original textual basis. Continuing to use the entire profile will retain the invalidated fields, while deleting or rebuilding the entire profile will simultaneously affect fields that still have valid evidence.

[0008] Therefore, it is necessary to establish a cross-file format source location and evidence object system so that each specific retrieval field can be verified to the original text in the specific resume source revision, and the range of affected fields can be determined when local evidence fails, so as to control the field-level writing and withdrawal of machine retrieval index. Summary of the Invention

[0009] The purpose of this invention is to provide a method and system for constructing evidence profiles of multi-format and multi-language resumes, in order to solve the problems of derived fields being separated from the original revised text after heterogeneous resume conversion, different evidence states being entered into the machine retrieval index indiscriminately, and the unclear scope of impact of local evidence failure.

[0010] This invention first establishes a candidate object identifier and a current source pointer for the resume to be processed, then reads all bytes from the same opened file object and forms an immutable snapshot. The source byte revision identifier, parsing, positioning, evidence, facts, projection, and pending events are all based on this immutable snapshot; the content equivalence identifier is saved separately.

[0011] The immutable snapshot forms a format-related reconstructable localization relationship. For image regions, the source image region object stores the pixel range and image summary, while the OCR transcription object separately stores the recognized text, model version, and confidence information and references the source image region; the OCR transcription is not marked as the original bytes of the source file.

[0012] Evidence fragments, candidate facts, and experienced events are generated from the location relationships, and the source expression, translation value, and normalized value are saved respectively. Versioned dependency graph records the dependencies and applicable versions between parsing, OCR, language recognition, translation, normalization, concept mapping, facts, projection, and index records.

[0013] Evidence polarity, fact resolution status, and location status are stored separately; the projection field also stores the source byte revision, projection version, and dependency summary. When the model, rule, or concept system version changes, only the fields that need to be recalculated are determined along the versioned dependency edges.

[0014] Maintain the index admission status and index baseline version for candidate object identifier, projection field identifier, and index type. The commit thread rereads the current source pointer, projection version, and index baseline version; if the comparison and exchange are successful, update the admission status and write it to the persistent mailbox in the same atomic state transition; if it fails, neither of these is written.

[0015] The state partitioning results directly control the initial and persistent index admission: only fields whose fact-resolution state meets the admission criteria and whose positioning is valid can form and maintain the current valid index record; fields that are pending verification, conflicting, or unindexable retain projections and dependencies but must not form or maintain the current valid machine retrieval index record. After a successful comparison and exchange, the event enters the persistent mailbox. The index writer consumes the event and adds, replaces, or removes the corresponding machine index record, rejecting outdated or conflicting events from overwriting the current state.

[0016] When any byte in the source file changes, a new source byte revision is generated, and the old revision is not reused even if the content equivalence identifiers are the same. The locator is rebuilt on the new revision, and the affected fields are determined along the reverse dependency; if the admission criteria are still met, a replacement event is generated; otherwise, a tombstone event is generated. Vector records atomically switch their current pointers after the new version is built and verified.

[0017] This invention also provides a multi-format, multilingual resume evidence profiling system, including a source revision and parsing representation module, an evidence fragment module, a fact and experience construction module, a fact parsing status module, an index admission module, and a partial withdrawal module. Each module is configured to perform the corresponding processing in the above method.

[0018] The present invention also provides an electronic device, including a processor and a memory, wherein a computer program stored in the memory implements the above-described method when executed by the processor.

[0019] The present invention also provides a computer-readable storage medium on which a computer program stored is executed by a processor to implement the above-described method.

[0020] By binding source revision identifiers, format-related locators, and original evidence fragments, derived fields from different file formats can use a unified dependency relationship to return the corresponding source file location.

[0021] By separately saving the original value, derived value, evidence polarity, fact analysis status, and location status, and performing joint admission before index writing, fields that are unknown, unverified, conflicting, or have lost their original position formed by candidate facts with non-empty evidence references can still be saved as projected records with status, but will not be written as determined fields into the machine retrieval index; fields that are not recorded at all in the resume will not generate candidate facts or profile projections based on them.

[0022] By rebuilding or mapping the locator on the changed source revision and then maintaining the reverse dependency path from the projected field to the failed locator, it is possible to limit the set of fields that need to be removed or rebuilt from the machine for index retrieval; fields that do not depend on the failed locator or are still valid after revalidation maintain the index state.

[0023] The aforementioned technical effects are directly generated by the reference relationships between data objects, the index admission order, and the partial withdrawal process, without relying on specific file parsing libraries, optical character recognition models, language models, database products, or retrieval ranking models. Attached Figure Description

[0024] Figure 1 A schematic diagram of the structure and data flow of a system for building evidence profiles of multi-format, multi-language resumes.

[0025] Figure 2 A flowchart illustrating the method for constructing evidence profiles for multi-format, multi-language resumes.

[0026] Figure 3 This diagram illustrates the data object relationships between resume source revisions, cross-format locators, evidence fragments, candidate facts, experience events, searchable profile projection fields, and machine-retrieval index records.

[0027] Figure 4 This diagram illustrates the relationship between evidence polarity, fact analysis status, location status, and machine retrieval index admission.

[0028] Figure 5 This is a timing diagram illustrating the execution of field-level withdrawal and local reconstruction along the reverse dependency path after a source revision change or location failure. Detailed Implementation

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments. The object identifiers, text, and field values ​​in the embodiments are used to describe object relationships and processing order, and do not constitute a limitation on the scope of protection.

[0030] like Figure 1 As shown, the source snapshot and source byte revision 110 enter the document area 120 and the positioning relationship 130; evidence fragments 140, facts 210, events 220 and versioning dependencies form a projection 320; the CAS index admission module 310 only forms a versioned index event 325 for the current version; the index 330 is updated idempotently according to the event sequence number; the versioning dependency and the local update module 340 form a replacement, tombstone and processing diagnosis 350.

[0031] The resume source revision object includes at least the candidate object identifier, the current source pointer pointing to the current authoritative source byte revision, the source byte revision identifier covering all bytes of the immutable snapshot, the file format, the byte length, the immutable snapshot reference, and the object constraint version. The index baseline version is the currently applied index state version corresponding to a triple consisting of the candidate object identifier, the projection field identifier, and the index type.

[0032] A document region object includes at least a region identifier, a parent region identifier, a region type, a reading order, a parsing path, and a reconstructable positioning relationship reference. A region can be a page, column, paragraph, table, cell, text box, or image region, and can form a parent-child region structure.

[0033] The reconstructable location relationship object includes at least the locator identifier, resume source revision reference, locator type, format-related location value, content fingerprint, neighborhood fingerprint, and verification status. The reconstruction operation first verifies the resume source revision, then obtains the target range based on the format-related location value, and finally verifies whether the obtained range corresponds to the range when the evidence fragment was generated using the content fingerprint or neighborhood fingerprint.

[0034] Evidence fragment objects include at least the evidence identifier, source byte revision reference, locator reference, source text range or source image region reference, fragment language, acquisition method, and status. OCR transcription of image regions is stored as a separate derived object, preserving the recognized text, model version, and confidence information; the source image region itself is still determined by the locator and image summary.

[0035] Candidate fact objects must include at least a fact identifier, fact type, original value, derived value, applicable time, evidence polarity, fact parsing status, evidence fragment reference, and processing rule version. Experience event objects must include at least an event identifier, event type, time interval, time status, reading order status, reading order candidates, experience relationship identifiers affected by reading order ambiguity, and fact references related to position, organization, responsibilities, skills, or education. Time status indicates missing or overlapping time periods; reading order candidates are stored as independent fields; reading order ambiguity is not written to the time status.

[0036] A fact conflict set includes at least a conflict set identifier, fact key, scope of application, member fact references, conflict cause, object constraints, processing rule version, and closed status. A conflict set is only created when the fact type, the object it refers to, and the applicable time overlap, and the preset coexistence rule determines that the members cannot all be true at the same time.

[0037] The searchable profile projection fields include at least the projection field identifier, field type, field value, applicable time, evidence polarity, fact analysis status, location status, status partition, candidate fact reference, and projection version. Regardless of whether the projection fields are written to the machine retrieval index, they are saved to the dependency edges of candidate facts, evidence fragments, locators, and source revisions. Machine retrieval index record 325 is an independent object distinct from the projection fields, including at least the index record identifier, projection field identifier, field value, applicable time, evidence polarity, fact analysis status, resume source revision identifier, evidence reference, and index write version. When a canonical value exists, it includes the canonical value and a record status used to distinguish between valid and withdrawn records. When no attributable time exists, the applicable time field is explicitly saved as null without being omitted. Only projection fields that meet the admission criteria form the currently valid machine retrieval index record 325.

[0038] Processing diagnoses include at least the diagnosis type, affected source revision, affected region, affected fact, affected projection field, responsible processing stage, and subsequent processing actions. Processing diagnoses do not replace state control; for example, when a locator failure diagnosis is generated, the corresponding projection field must synchronously exit the determined index partition. When a resume completely omits a field, a field missing diagnosis can be formed that only indicates the field type, source revision, and reason for the missing information. This diagnosis does not carry the fact value for that field, does not reference non-existent candidate facts or projection fields, and does not enter the object chain from candidate facts to searchable profile projection fields.

[0039] like Figure 2 As shown, the method includes S201 to S206. S201 fixes the source revision and forms a parsed representation; S202 forms traceable evidence fragments; S203 forms candidate facts and experienced events; S204 forms evidence polarity, fact parsing state, and location state, and generates projection fields with state partitions and evidence references; S205 performs joint admission of state and location before machine index writing, and writes the event to the persistent mailbox after successful CAS and consumes it by the index writer to add corresponding records; S206 reconstructs or maps the location relationship on the new source revision, and then generates and consumes replacement or tombstone events along the dependency path from the failed location relationship, and performs machine index field-level replacement, withdrawal, partial reconstruction, and diagnostic output. Implementation Method 1: The Complete Object Chain of Mixed Language PDFs

[0040] In this embodiment, the source file is a two-page PDF resume containing a text layer and a scanned image area. The system generates a resume source revision object SR1, which records the source identifier, content summary, PDF format, content length, object constraints, and processing rule version, and obtains the first revision verification value before parsing begins.

[0041] Document region R11 is formed for the text layer of the first page, and document region R21 is formed for the image region of the second page. R11 selects the native text parsing route, and R21 selects the image text recognition route; the two regions respectively store the page order and the reading order within the region.

[0042] For image transcriptions, the system saves the content addressing object, pixel range, and image summary of the original image bytes as the source image region object; the OCR unit generates a transcription object that references this region, and the transcription object saves the candidate recognized text, model version, confidence information, and recognition status. Evidence fragments reference the source image region and the transcription version used, but do not mark the recognized text as the original bytes of the source file.

[0043] For PDF image pages or DOCX / XLSX regions containing image text, the format locator, source image region object, and OCR transcription object are saved separately. Model changes or manual corrections generate new transcription versions, while the old versions are retained as historical derived objects; recalculation is performed only based on facts and projections that depend on the old transcription versions.

[0044] From E11, job fact F11 and time fact F12 are formed; from E21, responsibility fact F21 and skill fact F22 are formed; and F11, F12, F21, and F22 are bound to experience event X1. The Chinese translation value of the English job title and the standard job title value are saved as derived values, while the original English text of E11 remains unchanged.

[0045] The index admission module generates projection fields P11, P12, P21, and P22 with status for F11, F12, F21, and F22, respectively. When the fact resolution status of F11, F12, and F21 is confirmed and the corresponding locator is valid, P11, P12, and P21 are written into the machine retrieval index; if the image and text acquisition status of F22 is insufficient to meet the admission conditions, F22 is in an unverified state, P22 enters the unverified partition, and is not written into the machine retrieval index.

[0046] P11, P12, P21, and P22 are saved to the candidate facts, evidence fragments, locators, and SR1 dependency paths, respectively. P11, P12, and P21 are written to the machine retrieval index; P22, F22, E21, and L21 are retained so that the skill facts can be updated without regenerating the corresponding R11 objects when R21 is reprocessed later.

[0047] Before index submission, the system rereads the current source pointer of the candidate object, the current projection version identified by the projection field, and the index admission status corresponding to the candidate object identifier, projection field identifier, and index type. It then compares and exchanges the source byte revision pointed to by the current source pointer, the current projection version, and the index base version. If successful, the admission status is updated in the same atomic state transition, and the versioned index event carrying the next event sequence number is written to the persistent mailbox. If it fails, no consumable events are generated. Implementation Method 2: Reconstruction and Verification of the PDF Locator

[0048] In this embodiment, the PDF locator consists of source revision references, page numbers, page width and height, normalized coordinate regions, start and end character positions of the text layer, target content fingerprints, and fingerprints of preceding and following neighboring content. Normalized coordinates are used to adapt to different display scaling, while character positions and content fingerprints are used to verify the retrieved text.

[0049] For regions with text layers, the reconstruction process first opens the same source revision indicated by SR2, obtains the text layer of the specified page, and then obtains the target range according to the character position; then it calculates the fingerprint of the target range and its neighborhood, and compares it with the fingerprint in the locator.

[0050] For the scanned area, reconstruction processing obtains the specified page image, converts the pixel region according to normalized coordinates, obtains the recognized text sequence associated with that region, and compares the recognized text fingerprints. The recognized text can be saved during the initial processing or retrieved again under the same object constraints and processing rule versions.

[0051] When the page identifier, target range, and content fingerprint all correspond, the location status is set to valid; when the source revision identifier is inconsistent, the page does not exist, the target range is out of bounds, or the content fingerprint does not correspond, the location status is set to invalid, and the reason for failure is recorded.

[0052] A candidate fact can reference one or more PDF locators. When multiple locators support the same fact, each locator is saved separately; if one locator fails while another still provides the same original text evidence, the fact resolution status can be recalculated according to the preset sufficient evidence rule, instead of directly deleting the fact that still has valid evidence.

[0053] When a fact depends solely on the failure locator, the corresponding projected field is determined along the dependency, placed in an unindexable partition within the projection, and the corresponding field is removed from the machine-retrieved index. Other page facts that have no dependency on this failure locator remain unaffected.

[0054] PDF locators can also use page object identifiers, text object numbers, polygonal regions, reproducible descriptors of marked content, or combinations thereof, as long as they can reconstruct the target original text range in the same source revision and provide a definite valid or invalid status. Implementation Method 3: DOCX Locator and Intra-paragraph Evidence

[0055] In this implementation, the source file is a DOCX resume. The system generates a source revision SR3, which saves the example content summary H3 and object constraint and processing rule version V3. Document areas are formed from the main document component, header component, text box, and table cell. Each area saves the component path, parent area, and logical reading order.

[0056] For a given paragraph, generate DOCX locators L31 to L34. Each locator includes a document part identifier word / document.xml, a paragraph identifier P31, a paragraph number, its own text execution number and character range within the execution, a paragraph specification text fingerprint FP31, and fingerprints of adjacent paragraphs. If a paragraph identifier exists, it is used first; otherwise, a combination of the paragraph number and the neighboring fingerprint is used.

[0057] Evidence fragments E31 to E34 are generated for the example original text in the aforementioned job description, including "example engineer," "example organization," "2022.01—2024.03," and "responsible for example system design." E31 to E34 sequentially reference L31 to L34 and preserve the original text, Chinese fragment language, and raw text acquisition status. Each evidence fragment references a corresponding character range but shares the same paragraph area to maintain the connection within the same job description.

[0058] Candidate facts F31 to F34 respectively store the job title "Example Engineer", organization "Example Organization", time period "2022.01—2024.03", and responsibility "Responsible for Example System Design", and reference E31 to E34 in sequence. Experience event X3 stores facts referencing F31 to F34, with a confirmed time status, a confirmed reading order status, an ordered candidate area, and an empty set of affected experience relationships. Another employment record within the table forms a different experience event; the skill facts of two events cannot be merged into the same employment fact solely because they have the same specification value.

[0059] When all L31 to L34 are valid in the initial verification and the fact resolution status of F31 to F34 is confirmed, projection fields P31 to P34 are formed in the positive attribute partition, and machine retrieval index records I31 to I34 are formed respectively. Each index record stores the corresponding projection field identifier, field value, applicable time (represented as 2022.01 to 2024.03), affirmative polarity, confirmed status, SR3, corresponding evidence citation, index write version, and valid record status. In subsequent verification, the system obtains paragraphs according to document components and paragraph identifiers, then obtains target text according to execution and character range, and compares content fingerprints. If different parser versions or different parsing rounds produce different text execution segments for the same source file byte sequence, while the paragraph specification text and target character sequence remain unchanged, the character range can be reconstructed in the paragraph specification text and a new locator can be generated.

[0060] Under the condition that the byte sequence of the source file remains unchanged, the system uses different parser versions or starts a new parsing round to obtain parsed representations with different text execution boundaries but the same document logical content. The system recalculates the cryptographic content digest for the same source file byte sequence and recalculates the paragraph canonical text and target character sequence. The results are consistent with the content digests H3, FP31, and the original texts stored in E31 to E34 stored in SR3, respectively. Therefore, the source revision identifier remains SR3. The system generates new locators L31R to L34R bound to SR3 on the same paragraph canonical text, records their reconstruction from L31 to L34, and updates the locator references of E31 to E34 to L31R to L34R in sequence. F31 to F34 still refer to the same evidence fragments, P31 to P34 still refer to the same facts, and I31 to I34 still refer to the same projections and evidence. The processing record D31 saves SR3, the parser version or parsing round, the mapping between the old locator and the new locator, and the reason for the successful split reconstruction. The processing does not generate a failed locator identifier, nor does it initiate projection or index withdrawal.

[0061] DOCX locators can also use bookmarks, content control identifiers, XML node paths, or paragraph content anchors, as long as the locator value is bound to the source revision and the original text used can be verified during index admission and subsequent validation. Implementation Method 4: Experience with XLSX Locator and Table

[0062] In this implementation, the source file is an XLSX resume representing work experience in rows. The system generates a source revision SR5, which saves the example content summary H5 and object constraint and processing rule version V5, and establishes hierarchical document areas for workbooks, worksheets, table areas, rows, cells, and merged cell areas.

[0063] For cells A8 to E8 in the example row, XLSX locators L51A to L51E are created respectively. Each locator includes the worksheet stability identifier SHEET-5, the corresponding cell address, the merged cell range, the character range within the cell, the read mode, and the content fingerprint. The read mode indicates whether the evidence is taken from a formula, a calculated formula value, displayed text, or the original cell value. The initial locator snapshot records L51A to L51E as valid and binds them to SR5.

[0064] The example texts obtained from L51A to L51E, namely "Example Organization," "Example Position," "2021.06," "2023.12," and "Example Responsibility," respectively form evidence fragments E51A to E51E. Candidate facts F51A to F51E sequentially store the corresponding organization, position, start time, end time, and responsibility value, referencing the corresponding evidence fragments. Experience event X5 stores fact references F51A to F51E, the confirmed time status, the determined reading order status, a reading order candidate list arranged from A8 to E8, and an empty set of affected experience relationships. For merged cells, their locators simultaneously store the merged area and the base cell responsible for carrying the value.

[0065] When L51A to L51E are all valid and F51A to F51E are all confirmed, projection fields P51A to P51E and machine retrieval index records I51A to I51E are formed. Each index record stores the projection field identifier, field value, applicable time (represented as June 2021 to December 2023), affirmative polarity, confirmed status, SR5, corresponding evidence reference, index write version, and valid record status. When a cell contains multiple skills separated by line breaks, the system forms multiple evidence fragments based on the character range within the cell, with each skill fact referencing its own fragment; when the character ranges are indistinguishable, the skill fact references the entire cell and preserves the common evidence relationship.

[0066] When a worksheet is renamed but the stability identifier and source revision content still correspond, the location can be reconstructed based on the stability identifier. At the start of the verification event in this example, L51E changes from a valid state to a state awaiting re-verification; when it is further determined that cell E8's address is out of bounds or the content fingerprint is inconsistent and cannot be reconstructed, L51E changes from a state awaiting re-verification to a state of invalidation. The final location snapshot records L51A to L51D as valid, L51E as invalid, and forms a diagnostic D51 containing SR5, L51E, E51E, F51E, P51E, I51E, and the withdrawal phase.

[0067] The reverse dependency module only receives locator identifiers whose final state is "failed," and the state awaiting re-verification is not used as withdrawal input. In this example, the set of failed locator identifiers only contains L51E, so the reverse traversal only reaches E51E, F51E, P51E, and I51E; the system moves P51E to the unindexable partition and changes the record state of I51E to "withdrawn." L51A to L51D remain valid, corresponding to P51A to P51D maintaining the positive attribute partition, and I51A to I51D maintaining the valid record state.

[0068] The XLSX locator can also save table names, structured references, named cells, row keys, or column header paths to accommodate changes in column order; regardless of the locator value used, it must maintain a reference relationship with the source revision, content fingerprint, and evidence fragment. Implementation Method 5: Multilingual Derived Values ​​and Mapping Ambiguity

[0069] In this implementation, a piece of original text contains a job title in one language and a job description in another language. The system determines the segment language of each piece of evidence separately, without covering the segment language with a single language tag at the document level.

[0070] For job fact F61, save the original value V0, the translated value V1, and the candidate normalized value V2. Both V1 and V2 reference the evidence fragments that generated them, the version of the translation processing rules, or the version of the semantic mapping, while V0 remains the original text in the source file.

[0071] When V0 can be uniquely mapped to a standard job concept, and the corresponding evidence fragment and locator are valid, F61 can be a confirmed state, and V2 can be used as a definite projection value; the index record also saves the evidence reference of V0 to support the original text verification.

[0072] When V0 corresponds to multiple canonical job concepts and existing evidence cannot disambiguate, F61 saves multiple canonical value candidates, and the fact resolution status is unverified. These multiple candidates can be used for subsequent verification and form a projected record to be verified, but none of them may be selected as the definitive job field to be written into the machine retrieval index.

[0073] When the original text is obtained but the language of the fragment cannot be determined, the system saves the original text, language candidates, and reasons for insufficient language judgment. It does not force the generation of translation values ​​and sets the fact parsing status of the corresponding candidate fact to unverified. The candidate fact saves the evidence polarity according to the actual support direction of the fact candidate in the original text, and references non-empty evidence fragments and their effective locators. Insufficient language judgment itself neither rewrites the evidence polarity nor is it represented as an unknown state or explicitly denied by the original text.

[0074] The multilingual direct extraction route and the translation-then-extraction route can generate fact candidates in parallel. When the two routes point to the same source text and have the same normative value, they can form a single fact according to the preset evidence merging rules; when they are inconsistent, each candidate and its processed version are saved, forming an unverified state or a set of fact conflicts.

[0075] Semantic normalization can be achieved using vocabularies, ontology, rules, statistical models, or language models. This implementation protects the data relationships between the original text, derived values, mapped versions, fact resolution states, and index admissions, without limiting it to a specific model. Implementation Method Six: Polarity, Fact Analysis State, and Conflict Control

[0076] In this implementation, evidence polarity, fact resolution state, and location state are three separately stored and mutually orthogonal attributes. Affirmative polarity indicates that the original text supports a fact, while negative polarity indicates that the original text indicates it does not possess or has not completed a fact. Fact resolution state indicates whether the fact currently possesses sufficient evidentiary conditions to perform deterministic indexing behavior. Location state indicates whether the original text position can be reconstructed and verified in the binding source revision. Changes in any one dimension do not directly rewrite the other two dimensions.

[0077] When a candidate fact is affirmative, the fact analysis status is confirmed, and the location status is valid, the corresponding projection field enters the positive attribute partition and can be written into the machine retrieval index; when a candidate fact is negative, the fact analysis status is confirmed, and the location status is valid, the corresponding projection field enters the negative evidence partition and can be written into the machine retrieval index as negative evidence, but cannot be written as the corresponding positive attribute at the same time.

[0078] When a skill is completely absent from a resume, no candidate facts regarding whether the skill is possessed are generated, no searchable profile projection field or machine-retrievable index record for that skill is generated, and the absence of the skill is not inferred as a negation. The system can output a field missing diagnosis, which only saves the source revision, field type, stage of responsibility handling, and reason for the field missing. It does not carry the skill fact value, does not reference candidate facts or projection fields, and does not enter the object chain from candidate facts to searchable profile projection fields. The semantics of the unknown state are limited to the fact that the current resume does not provide the original text information required to establish the corresponding fact value. When there are locatable "unknown," "pending," or equivalent expressions in the original text that form candidate facts with non-empty evidence references, the candidate facts can form a projection to be verified, but for fields that are completely absent, only the above diagnostic path is executed.

[0079] When the original text region has been obtained, but text recognition, segment language judgment, or entity mapping are insufficient to form a definite value, the fact resolution status is unverified. The corresponding projection field enters the unverified partition and is not written to the machine retrieval index. The unverified status saves the existing original text, locator, and processing failure stage for reprocessing at the region level.

[0080] When two pieces of evidence in the same source revision provide facts that cannot be simultaneously established and whose applicable times overlap, the system forms a set of fact conflicts. For example, if the same fact key for the same experienced event has two mutually exclusive end-of-term dates, and the coexistence rule determines that the two cannot be simultaneously established, then both facts are retained and the latest value is not chosen to overwrite the earlier value.

[0081] If two job facts overlap in time, but the pre-defined coexistence rules allow for overlapping periods of part-time work, concurrent employment, or job change, then a conflict will not automatically arise due to the time overlap. Conflict determination uses the fact type, the object referred to, the applicable time, and the coexistence rules simultaneously.

[0082] Membership facts in a conflict state form projected records in the conflict partition and are not written into the machine retrieval index as conflict-free definitive attributes. Conflict closure operations generate new processing events and fact resolution states, without deleting the original conflicting members and their evidence.

[0083] Regardless of the fact resolution status, if the corresponding locator fails, the corresponding projection field will be preferentially placed in the unindexable partition. The reason for the fact resolution status and the reason for the locator failure will be saved, and the field cannot be added to or maintained in the machine retrieval index. The locator status is used as an independent admission condition to avoid misinterpreting a confirmed status as permanently valid.

[0084] Figure 4The truth relationships shown can be implemented as rule tables, decision trees, finite state machines, or deterministic verification functions. Their operations are defined as follows: the three dimensions are stored using different fields; an update event for one dimension only updates that dimension; partitioning actions are calculated after reading the three dimensions. Therefore, affirmative and negative polarities, the four types of fact parsing states, and the positioning state can form deterministic and reproducible projective partitioning and machine indexing actions. Implementation Method 7: Projection Admission and Field-Level Withdrawal

[0085] In this implementation, the source revision SR7 stores the example content summary H7. The PDF locator L71 stores the coordinate region, character range, and content fingerprint of the first page; the evidence fragment E71 references L71 and stores the original text "Example Skill A"; the candidate fact F71 with affirmative polarity references E71 and stores the standard skill value SKILL-A; the forward attribute projection field P71 references F71; the machine retrieval index record I71 references P71 and stores SKILL-A, the applicable time for explicitly empty records, affirmative polarity, confirmed status, SR7, E71, index write version, and valid record status. The system establishes reverse adjacency relationships from L71 to E71, E71 to F71, and F71 to P71.

[0086] During the initial index admission process, the system first generates and saves the state and dependencies of P71. Then, it verifies the correspondence between SR7 and the source file content according to the partitioning results and index admission rules, and uses L71 to reconstruct the original position of E71. Only when the F71 fact resolution state meets the admission conditions and L71 is valid is P71 determined as a writable field, an add event is generated, and it is written to the persistent mailbox after successful CAS. The index writer consumes the event to form I71. Partitions that are pending verification, conflicting, or unindexable retain projections but must not form or maintain them as currently valid machine retrieval index records. Therefore, machine indexes do not adopt the write-then-verify processing order.

[0087] For another original text "Example Certificate B" in the same SR7, establish locator L72, evidence fragment E72, confirmed affirmative fact F72, projection field P72, and machine retrieval index record I72. I72 stores P72, the canonical value CERT-B, the applicable time when explicitly empty, affirmative polarity, confirmed status, SR7, E72, index write version, and valid record status. Experience event X7 references F71 and F72, storing the confirmed time status, the determined reading order status, an ordered region candidate, and an empty set of affected experience relationships; even if P71 and P72 belong to the same candidate profile field group, their dependency paths are still stored separately.

[0088] When subsequent verification reveals changes to the source file content, the system generates a new source revision SR8 and converts L71 and L72, which depend on SR7 and were originally valid, to a state pending re-verification. The system then reconstructs or maps L71 and L72 on SR8 according to format-related location values ​​and re-verifies them. It does not directly inherit the valid state on SR7 as the valid state on SR8, nor does it start the withdrawal process directly with a state pending re-verification.

[0089] If L71 cannot be reconstructed, mapped, or has an inconsistent content fingerprint on SR8, then L71 is changed from pending re-verification to invalid and added to the invalid locator identifier set. If L72 generates a new locator L82 bound to SR8 and valid in state after reconstruction rules, and still corresponds to the original text, then a new evidence fragment E82 bound to SR8 is generated on L82. E82 saves the original text "Example Certificate B" and records that it was reconstructed by E72. E72 is retained as the old revised evidence replaced by E82. The evidence reference of F72 is updated to E82, P72 still references F72, and I72 is updated to reference P72, SR8, and E82. The reverse dependency and local withdrawal module only traverses the reverse adjacency relationship starting from L71 in the invalid locator identifier set to obtain the affected set E71, F71, P71, and I71, while E82, F72, P72, and I72 are not included in the affected set.

[0090] The system retains P71 in the searchable image projection, marks its location status as invalid, and moves it to the unindexable partition. It also changes the record status of I71 to withdrawn. The system retains P72 and I72, which still meet the admission criteria after re-verification. P72's location status remains valid, and I72 retains the explicitly empty applicable time, SR8, E82, new index write version, and valid record status. Simultaneously, it generates a processing diagnostic, D71. D71 stores SR7, SR8, the invalid locator L71, affected objects E71, F71, P71, and I71, the withdrawal processing stage, and the recommended reprocessing area.

[0091] After re-parses the document region corresponding to L71, a new locator, a new evidence fragment, a new version of fact, and a new projection field are generated. The new projection field replaces the original field with the projection version and is written to the machine retrieval index after being admitted. The original projection field and dependencies can be retained as historical processing records, but must not continue to be used as valid basis for the current machine index fields.

[0092] The affected set can be determined using reverse adjacency list traversal, relational table join query, graph traversal, or event subscription. The traversal starts at the failure locator or failure evidence fragment and ends at the searchable profile projection field; projection fields not reachable from the starting point are not included in the withdrawal set.

[0093] When a projected field depends on multiple pieces of evidence, the withdrawal module re-executes the versioned evidence sufficiency rule for that field after removing invalid evidence. If the remaining evidence still meets the admission criteria, the dependency path and projection version are updated, and the field in the machine retrieval index is retained; otherwise, the corresponding field is marked as invalid in the projection, the field is withdrawn from the machine retrieval index, and the reason for insufficiency is recorded. Implementation Method 8: Exception Handling and Alternative Resolution Routes

[0094] In this embodiment, the system revises the SR9 of the PDF source to be checked, and saves the example content summary H9 in SR9. Before forming a complete candidate profile, the system forms document type features based on the number of individual candidate identity fields, personal experience structure, document area type and its distribution, and checks the content availability status. If the features indicate that the source file belongs to a job document, blank template, invoice, certificate, business data, or list of multiple people and does not meet the single-person resume object constraint, the system outputs a non-single-person resume type diagnosis referencing SR9 and stops candidate profile construction.

[0095] For encrypted files whose decryption content has not been obtained, the system outputs an encrypted file diagnosis and does not generate forged original text, locators, or candidate facts; for files with damaged structures that cannot form a stable source location, the system outputs a damaged file diagnosis and stops processing.

[0096] When PDF region R91 in SR9 has reliable native text, region R92 has insufficient native text, and region R93 has two feasible reading orders, the native text, image text recognition, and multimodal document parsing routes are selected respectively, forming locators L91, L92, and L93 bound to SR9. Alternative routes must continue to output locators and evidence fragments bound to the same source revision; otherwise, their results must not enter the determined index partition.

[0097] L91 forms evidence fragment E91 bound to SR9 and saves the original text "Example Job C" and the confirmed job fact F91; L92 forms evidence fragment E92 bound to SR9 and saves the candidate text and the unverified job fact F92; L93 forms evidence fragment E93 bound to SR9 and the unverified experience relationship fact F93 dependent on cross-regional order. Experience event X9 references F91 to F93, and its time status is independently saved as confirmed. The system forms a positive attribute projection P91 and a machine retrieval index record I91. I91 saves the applicable time, SR9, E91, index write version, and valid record status, which are explicitly empty; the system also forms unverified projections P92 and P93. P92 and P93 do not generate machine retrieval index records. Low-quality text recognition diagnosis D92 references SR9, L92, E92, F92, and P92, while other regions with reliable original text continue processing.

[0098] When multiple columns, floating text boxes, or nested tables result in multiple possible reading orders, X9 maintains the time state as confirmed and stores the R91, R92, R93 order indicated by candidate RO-A and the R91, R93, R92 order indicated by candidate RO-B in the independent reading order candidate field. X9 also includes the experience relationship REL-93 across R92 and R93 in the affected experience relationship set and maintains the fact resolution state of this relationship as unverified. The system does not merge experience events across order candidates to form the reading order ambiguity diagnosis D93 referencing SR9, L93, E93, F93, X9, P93, and REL-93; P91 and I91, which can be determined in a single area, are retained.

[0099] When language recognition returns multiple candidates and cannot disambiguate, save the language candidates and the original text, set the corresponding candidate facts to unverified and do not force translation; when semantic mapping returns multiple canonical values, save the mapping candidates and prevent the uniquely determined value from being written to the index.

[0100] When the model output does not meet the object constraints of candidate facts, experienced events, or evidence references, a limited number of restructuring processes can be performed or the model can be switched to the rule extraction route. If the model still does not meet the object constraints, a structured output error diagnosis will be output instead of generating definitive facts that lack evidence references.

[0101] When the source file changes during processing, if the snapshot stability check or CAS commit detects an inconsistency, the system discards the pending commit events of the old snapshot and reconstructs the affected area on a new immutable snapshot formed from the same open file object; newer field-level events that have already been written are not overwritten by older events.

[0102] Each anomaly diagnosis includes the responsible stage and the affected objects. Regional anomalies only block fields that depend on that region; when the entire source file is unavailable, source revisions cannot be fixed, or the document type is not a single-person resume, a complete searchable profile projection is not formed.

[0103] The alternative routes in this implementation can be provided by different parsing libraries, text recognition models, document vision models, rule engines, or language models, but the output must meet the common constraints of source revision binding, reconstructable location, evidence fragment citation, fact parsing status, and index admission. Other alternative implementation methods

[0104] In an alternative implementation, the parsing representation is based primarily on the document's native structure: PDF uses a text layer and page objects, DOCX uses an open document XML structure, and XLSX uses a workbook structure; image processing is performed only on regions where text cannot be obtained from the native structure.

[0105] In an alternative implementation, each document page is first rendered in a uniform visual coordinate space. Regions, reading order, text, and fact candidates are generated by the document visual model. The uniform visual coordinates are then mapped to PDF pages, DOCX paragraphs, or XLSX cells. Uniform visual coordinates cannot replace source revision verification.

[0106] Candidate facts and evidentiary relationships can be stored in a relational database, maintaining dependencies with foreign keys and reverse indexes; they can also be stored in a document database, maintaining dependencies with embedded references; or they can be stored in a graph structure or append-only event streams. Changes in storage methods do not alter field-level dependencies and withdrawal relationships.

[0107] Projection and machine index are different objects. Index updates are accomplished through replacement or tombstone events carrying source byte revisions, projection versions, event sequence numbers, and idempotency flags; fields pending verification, conflicting, pending reverification, and invalid fields remain in the projection but do not constitute currently valid index records.

[0108] The source byte revision identifier is a cryptographic digest algorithm that covers a defined byte sequence from the first byte to the last byte of the source file. The normalized content equivalence identifier can ignore container timestamps, non-semantic metadata, or normalized typesetting marks, but is only used for reconstruction and caching strategies; even if the equivalence identifier is the same, changes to the source bytes still form a new source byte revision.

[0109] Each parser, OCR model, language recognition, translation model, normalization rules, concept system, fact state rules, conflict rules, and index admission rules is configured with a version. Derived objects and projection fields store the applicable version and dependency edges, enabling the recalculation range to be determined when any version changes.

[0110] Before the initial index write, a CAS check must be performed on the current source pointer, source byte revision, projection version, and index base version; successful updates and persistent mailbox writes belong to the same atomic state transition.

[0111] When a fact has multiple valid pieces of evidence, admission can be determined by rules such as all evidence must be valid, at least one piece of evidence must be valid, or the evidence sufficiency rule can be configured according to the fact type. The adopted rules and their versions are stored in the fact or projection field to support subsequent dependency recalculation.

[0112] The source revision and parsing representation module, evidence fragment module, fact and experience construction module, fact parsing state module, index admission module, and local withdrawal module can be deployed on the same electronic device or distributed across multiple communicating computing nodes. Module distribution does not alter the source revision and evidence citation constraints.

[0113] When modules are distributed across different nodes, the transmitted object carries at least the candidate object identifier, projection field identifier, index type, source byte revision, object version, dependency summary, and index event sequence number; the receiving node still performs state admission and idempotent comparison according to the same field-level scope.

[0114] Electronic devices can be desktop computers, servers, or computing systems consisting of local processing nodes and service processing nodes. The processor executes programs in memory to establish object references, determine execution status, update projections, and perform machine retrieval indexes.

[0115] The computer-readable storage medium can store program instructions, object constraints, locator reconstruction rules, state admission rules, and dependency withdrawal rules that implement S201 to S206. The above data processing procedures are generated when the program is executed by the processor.

[0116] This invention processes single resume source byte revisions to form an evidence profile and versioned searchable projection, without performing identity merging of different resumes to determine whether they belong to the same natural person, without accepting recruitment tasks to perform candidate recall, scoring or sorting, and without calculating the intersection of the local candidate range and the cloud-authorized range.

[0117] Without deviating from the separation of source byte revision and content equivalence, immutable snapshots, reconstructable location, separation of source image and OCR transcription, versioning dependency, CAS admission, and ordered replacement and tombstone relationship, equivalent replacements can be made for object name, storage structure, model and deployment method. Evidence Version and Index Consistency Implementation Method

[0118] This implementation separates the byte identity of the source file from the normalized content equivalence relation. The source byte revision identifier covers all source file bytes involved in the processing; a new revision is formed as long as any byte changes. The content equivalence identifier is formed by removing the container timestamp, non-semantic metadata, or normalized typesetting marks from the content representation. It is only used to select the reconstruction scope and cache reuse strategy and does not replace the source byte revision identifier.

[0119] The source snapshot module opens the source file without following symbolic links, reads all bytes from the same opened file object, and compares the object's identity, length, modification flags, and permissions before and after the read. If the comparison is consistent, an immutable snapshot is formed; parsing, location, evidence, facts, projection, and source byte revision calculations are all based on this snapshot.

[0120] PDF, DOCX, and XLSX locators save page and coordinates, document parts and paragraphs or text runs, worksheets and cells or merged regions, and content fingerprints, respectively. Image locators save source image object identifiers, pixel regions, and image summaries; OCR transcription is a derived object referencing that pixel region, separately saving the recognized text, model version, and confidence information. OCR transcription can serve as a source of evidence for candidate facts but is not marked as original bytes of the source document.

[0121] The versioned dependency graph records directed edges between the source text range or source image region, OCR transcription, speech recognition, translation, normalization, concept mapping, candidate facts, experienced events, projection fields, and index records. Each node carries the applicable version from the parser, OCR model, speech recognition, translation model, normalization rules, concept system, state rules, conflict rules, and admission rules. When versions change, the recalculation set is determined by the dependency edges.

[0122] The index admission record is bound to the candidate object identifier, projection field identifier, index type, expected current source pointer, expected source byte revision, expected projection version, expected index base version, and next event sequence number. The submission thread rereads the current source pointer, the current projection version corresponding to the projection field identifier, and the index admission status respectively; if the comparison and exchange are successful, the admission record is updated in the same atomic state transition and the event is written to the persistent mailbox; if it fails, no consumable events are written.

[0123] The index writer consumes versioned index update events from the persistent mail box, forming event scopes based on candidate object identifier, projection field identifier, and index type. An idempotent key is constructed using the event scope, index event sequence number, and idempotent event identifier. Each scope maintains the currently applied index event sequence number and its idempotent event identifier. Application is rejected if the pending event sequence number is less than the current sequence number; if the sequence numbers are equal and the idempotent event identifiers are the same, no duplicate writing is performed, and an application confirmation is returned; application is rejected and a sequence number conflict is recorded if the sequence numbers are equal but the idempotent event identifiers are different; only when the sequence number is higher and the source byte revision, projection version, and index base version verification pass, is the machine-retrieved index record added, replaced, or withdrawn, and the current sequence number and its idempotent event identifier advanced. Sequence numbers for other fields or index types are not included in the comparison within this scope.

[0124] The location reconstruction service first reconstructs or maps the locator on the new source byte revision. Successful reconstructions generate new evidence versions referencing the new revision; failures become invalid locators. The reverse dependency module only retrieves reachable projection fields from invalid or version-affected nodes and re-executes the sufficient evidence rule and state admission rule for each field. Fields not reachable from the starting point retain their current version.

[0125] For fields that still meet the admission criteria, a replacement event is generated according to the next event number of the corresponding field and index type, and the historical projection is retained. For fields that no longer meet the admission criteria, a tombstone event is generated according to the next event number of the corresponding scope, and the current machine index record is marked as withdrawn. Both replacement and tombstone events, after rereading the current source pointer, current projection version, and index admission status, use the same comparison and exchange validation as the new event. Upon successful comparison and exchange, the admission status is updated and written to the persistent mailbox via the same atomic state transition. The state to be revalidated itself is not written back to the current machine index. Rebuilding, replacement, and tombstone events all include the source byte revision, projection version, rule version, and event number.

[0126] The input version of a vector index record is formed by the projected content summary, the embedding model version, the vector dimension, and the normalization parameters. After the new vector is constructed in the versioned namespace and verified by the dimension and content summary, it is switched by comparing and swapping with the current record pointer; if the switch fails, the outdated construction result is discarded, and if the switch is successful, the old record is marked as replaced and is delayed in being recycled.

[0127] Relational indexes, inverted indexes, and vector indexes consume the same versioned index event or its sub-events. Idempotent event identifiers are bound to at least the candidate object identifier, projection field identifier, index type, index event sequence number, event type, and event content summary; consumers store the currently applied sequence number and its idempotent event identifier. When an external write succeeds but local confirmation is interrupted, replaying the same sequence number and the same idempotent event identifier only completes the application confirmation; events with the same sequence number but different idempotent event identifiers are recorded as sequence number conflicts and do not overwrite the current index state.

[0128] The system implementation includes a source snapshot and byte revision module, a content equivalence determination module, a cross-format positioning module, an image and OCR object module, an evidence and fact construction module, a versioned dependency graph module, a stateful projection module, an atomic CAS admission module, a persistent mailbox, and a field-level versioned index update module.

[0129] Electronic devices and storage media save snapshots of the same object, byte revisions, location reconstruction, dependency traversal, atomic admissions and outboxes, field-level idempotent events, tombstone replacement, and vector pointer toggling instructions.

[0130] Anomalies include at least snapshot read contention, source byte revision changes, locator reconstruction failure, insufficient OCR confidence, inconsistent model or rule versions, CAS conflicts, out-of-order index events, and vector switching conflicts. The system retains the responsible node, input version, affected objects, and recommended reprocessing scope separately, and does not overwrite new revision failures with the old index's successful status.

[0131] In an example where only the container save time of a DOCX changes while the content of the text, tables, and images is equivalent, the system generates a new source byte revision but can obtain the same content equivalence identifier; the system still rebuilds the locator and generates evidence versions that reference the new revision, and can only reuse intermediate parsing caches that have been validated by the input version based on the equivalence identifier, and cannot allow old evidence or old index records to continue to claim binding to the current byte revision.

[0132] In the scanned PDF example, the source image region object stores the page image summary and pixel range, while the OCR transcription object stores the candidate recognized characters, model version, and confidence interval. Manual review can change the fact resolution status of a certain transcription version to "confirmed," but the transcription still references the source image region as a derived object. When changing the OCR model, only the facts and projections dependent on the corresponding transcription version are recalculated.

[0133] The technical boundaries of this invention are multi-format source byte revision, reconstructable location, evidence and derived version dependency, state admission, and versioned index withdrawal and replacement. This invention does not perform different resume identity merging, does not accept recruitment tasks for candidate recall, scoring, or ranking, and does not calculate the intersection of the local candidate range and the cloud-authorized range. Snapshot, Atomic Admission, and Field-Level Event Implementation Methods

[0134] The candidate object identifier is a stable object identifier for a single pending resume within the evidence profile domain. The current source pointer is a persistent reference to this candidate object, its value pointing to the current authoritative source byte revision. The index baseline version is the currently applied index state version corresponding to the triplet of candidate object identifier, projection field identifier, and index type.

[0135] The source snapshot module reads all bytes from the same opened file object and forms an immutable snapshot while maintaining stable properties before and after the read. Source byte revisions, parsed representations, locators, evidence fragments, facts, projections, and pending events all reference this snapshot; there is no fork where the digest is read by path and then another file object is reopened for parsing.

[0136] The index admission record stores the expected current source pointer, expected source byte revision, expected projection version, expected index base version, and next index event sequence number. Before committing an insert, replace, or tombstone event, the current source pointer, the current projection version of the target field, and the index admission status are reread respectively. If the comparison and swap are successful, the admission record is updated in the same atomic state transition and the corresponding event is written to the persistent mailbox; if it fails, neither of these items is written.

[0137] The same atomic state transition only covers the local index admission state and the persistent outgoing mailbox, and does not require external relational indexes, inverted indexes, or vector indexes to participate in the same transaction. After consuming an outgoing mailbox event, the index writer independently adds, replaces, or removes the corresponding machine-retrieval index record; the outgoing mailbox consumer can replay the same idempotent event after an interruption and separately confirm the external write, and outdated or conflicting events must not overwrite the current index state.

[0138] An event scope consists of a candidate object identifier, a projection field identifier, and an index type. The event scope, the indexed event sequence number, and the idempotent event identifier together form an idempotent key. Each scope maintains its own currently applied indexed event sequence number and its idempotent event identifier; consumers use both to distinguish between old events, confirmed replays of the same event, conflicting events with the same sequence number but different events, and new events that can be advanced.

[0139] When inverted index event 11 of field B arrives first and inverted index event 10 of field A arrives later, they belong to different scopes. Event 10 of field A is still compared with the current sequence number of field A and can be applied. Only if an event with a higher sequence number has already been applied to the same index type of field A will the old event be rejected; if an event with the same sequence number has already been applied, the idempotent event identifier must also be compared.

[0140] Within the same candidate object, field, and index type, when replaying event 10 after event 11 has been applied, the consumer rejects event 10 and maintains the replacement or tombstone state of event 11; when replaying an event with the same idempotent event identifier as the already applied event 11, the consumer completes the application confirmation without rewriting; when receiving an event with the same sequence number 11 but a different idempotent event identifier, the consumer records the sequence number conflict and rejects the application; when receiving event 12, the consumer only performs the update and advances the current sequence number after the source byte revision, projection version, and index base version have all passed verification.

[0141] Vector indexing is advanced by field-level events or vector sub-events derived from the same event. Composite vectors are separately bound to a summary of the input field set; when any input field is removed, a new composite input version is created and the current vector record pointer is switched after validation. Old vectors cannot be recovered by replaying events from other scopes.

[0142] The system, electronic devices, and storage media all execute the same snapshot, well-defined version objects, atomic admissions and sender boxes, field-level event scopes, and replacement / tombstone / vector switching chains, without performing candidate identity merging, recruitment task recall, or cloud authorization intersection. Data processing compliance boundaries

[0143] The resumes and candidate data involved in this specification shall be obtained legally and processed within the authorized purpose and scope; evidentiary profiling and searchable projection shall not be used to make recruitment decisions solely based on discriminatory factors prohibited by laws and regulations. This specification does not change the aforementioned technical processes and technical effect judgments regarding immutable snapshots, reconstructable positioning, versioned dependencies, atomic index admission, and field-level event withdrawal and replacement.

Claims

1. A method for constructing a multi-format, multi-language resume evidence profile, characterized in that, include: Establish a candidate object identifier for the resume to be processed and a current source pointer pointing to the current authoritative source byte revision of that candidate object; The source file of the resume to be processed is opened without following symbolic links. All bytes of the source file are read from the same opened file object, and an immutable snapshot is formed when the stable attributes remain consistent before and after the read. A source byte revision identifier covering all bytes of the immutable snapshot is calculated, and the current source pointer is made to point to the source byte revision identifier. The content equivalence identifier used to determine whether the layout changes but the normalized content is equivalent is saved separately from the source byte revision identifier. Document regions and reconstructable positioning relationships are formed from the immutable snapshot according to the file format, and the reconstructable positioning relationships are bound to the source byte revision identifier. For image regions, the source image region object, optical character recognition transcription object, recognition model version, and recognition confidence information are saved separately, making the optical... The character recognition transcription object references the source image region object as a derived object instead of the original bytes of the source file; evidence fragments are formed from the reconstructable positioning relationship, and candidate facts, experienced events, and searchable profile projection fields are formed from the evidence fragments. The searchable profile projection field is saved to the reverse dependency path of the source byte revision identifier of the candidate facts, evidence fragments, reconstructable positioning relationship, and the immutable snapshot, and the applicable version among the parser version, optical character recognition model version, language recognition version, translation model version, normalization rule version, concept system version, fact state rule version, conflict rule version, and index admission rule version used when forming the derived object is saved. Based on the evidence polarity, fact parsing state, and positioning state... The searchable profile projection field is divided into positive attributes, negative evidence, pending verification, conflict, or unindexable partitions. According to the index admission rules, only searchable profile projection fields whose fact-analysis status meets the admission criteria and whose positioning status is valid are determined as writable fields. Searchable profile projection fields in pending verification, conflict, and unindexable partitions cannot form or remain as currently valid machine retrieval index records. An index admission status is maintained for the candidate object identifier, the projection field identifier of each searchable profile projection field, and the index type to be written. The index baseline version in the index admission status is used to identify the currently applied index corresponding to the triple composed of the candidate object identifier, the projection field identifier, and the index type. Before committing a versioned index update event, the current source pointer, the current projection version identified by the projection field, and the index admission status are reread. The current source pointer is compared and exchanged to verify that it still points to the source byte revision identifier used to form the event to be committed, that the current projection version is still equal to the expected projection version, and that the current index base version is still equal to the expected index base version. Only when the comparison and exchange are successful is the index admission status updated in the same atomic state transition, and a versioned index update event carrying the candidate object identifier, the projection field identifier, the index type, the source byte revision identifier, the projection version, the next index event sequence number, and the idempotent event identifier is written to the persistent mailbox.No consumable versioned index update event is generated when the comparison and swap fails; when the source file bytes change, a new immutable snapshot and a new source byte revision identifier are generated, and the old source byte revision identifier is not used because the content equivalence identifiers are the same; the current source pointer is made to point to the new source byte revision identifier, the original reconstructable positioning relationship is reconstructed or mapped on the new immutable snapshot, the affected searchable profile projection fields are determined along the reverse dependency path, and for the same candidate object identifier, projection field identifier, and index type, the same comparison and swap checksum and persistent mailbox atomic state transition are used according to their respective index event sequence numbers, and replacement events are written for fields that still meet the admission conditions, and for fields that no longer meet the admission conditions... The field is written to the tombstone event; the index writer consumes the versioned index update events in the persistent mail box, and adds, replaces, or removes the corresponding index record in the machine retrieval index according to the candidate object identifier, the projection field identifier, and the index type, and rejects outdated or conflicting versioned index update events from overwriting the current index state; and for the vector index record generated by the searchable profile projection field, a vector input version is formed by the projection content summary, the embedded model version, and the vector dimension, and the current vector record pointer is atomically switched after the new vector index record is constructed and verified, and the old vector index record is marked as replaced after the switch, so that repeated, out-of-order, or interrupted replay index update events cannot recover fields that have been removed by the newer version.

2. The method according to claim 1, characterized in that, The source byte revision identifier is calculated by a cryptographic digest algorithm from the first byte to the last byte of the immutable snapshot; the content equivalence identifier is calculated by removing the document container timestamp, non-semantic metadata, or normalized typesetting mark; the content equivalence identifier is only used to select the locator reconstruction strategy and reduce unnecessary full semantic recalculation, and is not used to replace the source byte revision identifier, index base version, or revision binding of the evidence object.

3. The method according to claim 1, characterized in that, Forming the immutable snapshot includes: opening the source file without following symbolic links, recording the object identity and stable attributes of the same opened file object, reading all bytes from the same opened file object, and comparing the object identity, length, modification identifier, and permissions before and after reading; if the comparison is consistent, the read bytes are written as a read-only snapshot or written to the immutable object storage in content-addressed mode; if the comparison is inconsistent, the derived object in this round is discarded; parsing, location, evidence formation, and source byte revision identifier calculation are all based on the immutable snapshot.

4. The method according to claim 1, characterized in that, Portable document format locators include at least page numbers, coordinate regions, character ranges, and content fingerprints; word processing document locators include at least document parts, paragraph identifiers, text execution or table cell identifiers, character ranges, and content fingerprints; spreadsheet locators include at least worksheet identifiers, cell or merged regions, reading modes, and content fingerprints; image locators include at least image page or image object identifiers, pixel regions, and image summaries; the optical character recognition transcription object separately records the recognized text, recognition model version, recognition confidence information, and references to the pixel regions.

5. The method according to claim 1, characterized in that, Each candidate fact stores the source expression, translation value, and normalization value, and records the processing chain from the source image region object or source text range to optical character recognition transcription, language recognition, translation, normalization, concept mapping, candidate fact, and searchable portrait projection field through versioned dependency edge records; When any processing model, rule, or concept system version changes, the derived objects and projected fields that need to be recalculated are determined based on the versioned dependency edges, without invalidating fields that do not depend on that version.

6. The method according to claim 1, characterized in that, Evidence polarity includes at least affirmative and negative; fact analysis status includes at least confirmed, unknown, unverified, and conflicting; and location status includes at least valid, pending reverification, and invalid. These three status dimensions are stored separately. Only fields that are affirmative or negative, have a confirmed fact analysis status, and a valid location status can form currently valid machine retrieval index records. Unknown, unverified, conflicting, pending reverification, or invalid fields are retained in the searchable profile projection but do not form currently valid machine retrieval index records.

7. The method according to claim 1, characterized in that, The versioned index update event, along with the source byte revision identifier, projection version, dependency digest, and expected index baseline version at the time of the event, is written to the persistent mailbox via the same atomic state transition. The index writer uses the candidate object identifier, projection field identifier, and index type to form the event scope, and uses the event scope, index event sequence number, and idempotent event identifier to form the idempotent key. The index writer maintains the currently applied index event sequence number and its idempotent event identifier only for the same candidate object identifier, the same projection field identifier, and the same index type, and compares the index event sequence number and idempotent event identifier of the event to be processed: events with a sequence number smaller than the currently applied index event sequence number are rejected; peers... Events with the same currently applied index event sequence number and idempotent event identifier are not written repeatedly and an application confirmation is returned; events with the same currently applied index event sequence number but different idempotent event identifiers are rejected for application and a sequence number conflict is recorded; only events with a greater than the currently applied index event sequence number that have passed source byte revision, projection version, and index base version verification are updated and the currently applied index event sequence number and its idempotent event identifier are advanced; tombstone events carry the previous valid version of the withdrawn field, and replacement events carry a new projection content summary; for vector indexes, records are first constructed and verified in the new version namespace, and then the switch is completed by comparing and exchanging the current vector record pointers.

8. A multi-format, multi-language resume evidence profiling system, characterized in that, It includes a source snapshot and byte revision module, a content equivalence determination module, a cross-format positioning module, an image and optical character recognition object module, an evidence and fact construction module, a versioned dependency graph module, a stateful projection module, an atomic comparison and exchange admission module, a persistent mailbox, and a field-level versioned index update module; each module is configured to perform the method described in claim 1.

9. An electronic device comprising a processor and a memory, characterized in that, The memory stores a computer program, which, when executed by the processor, causes the electronic device to perform the method according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the method according to any one of claims 1 to 7.

Images