Method and apparatus for analyzing human resource compliance influence of policy change perception

Abstract

The application discloses a kind of human resource compliance influence analysis method and device based on policy change perception.Therein, the human resource policy text and annex of multiple countries or regions are collected, version fingerprint is generated, and evidence positioning, de-duplication and conflict marking are carried out;Through the constrained large language model combined with rule checker, policy entity, compliance obligation, trigger condition, deadline, penalty and other information are extracted, policy rule vector and obligation condition graph are formed;The current rule is different from historical rule multidimensional, and rule change factor is obtained;Business object is mapped to uniform rule element space, and business object reverse index is constructed;According to rule change factor, affected object is searched and impact score is calculated, compliance task is generated and audit library is rewritten.The application can quickly and explainably locate policy changes to specific business objects, improve compliance impact identification, task sequencing and audit traceability efficiency.

Description

Technical Field

[0001] This invention relates to the fields of human resource compliance management, natural language processing, knowledge graph, rule engine, vector retrieval, inverted index, robotic process automation, and business process management. In particular, it relates to a human resource compliance impact analysis method and apparatus that automatically identifies policy changes, locates affected business entities, calculates impact priorities, generates executable tasks, and audits and writes back the task execution results when policies change across countries or regions.

[0002] This invention is applicable to scenarios such as global employment services, human resources outsourcing, payroll outsourcing, visa and immigration services, social insurance and benefits management, labor relations management, contract compliance review, customer success operations, and maintenance of internal corporate compliance knowledge bases. Background Technology

[0003] In human resources outsourcing, global hiring, payroll, visa services, social security payment, and labor relations management, labor laws, tax rules, visa application requirements, minimum wage standards, social security contribution rates, payroll filing deadlines, and regulatory interpretations frequently change across different countries and regions. These policy changes are characterized by dispersed sources, diverse languages, irregular release times, complex applicable conditions, short implementation windows, and unclear boundaries of responsibility.

[0004] Existing business systems typically store data such as customers, employees, contracts, work orders, knowledge base articles, and historical processing records. However, this data is mostly stored centered around business objects and lacks a calculable mapping relationship with policy and rule elements. Even if compliance personnel have discovered a policy change, they often need to manually search customer contracts, employee information, unfinished work orders, payroll settings, and knowledge base articles to determine which specific objects are affected.

[0005] In actual operation, a large number of historical work orders have accumulated expert judgments, handling actions, and customer communication experience. However, this experience usually exists in the form of natural language notes, email records, or attachments, making it difficult to directly reuse in existing systems. The judgment of the impact of policy changes still relies heavily on expert experience, which may lead to inconsistent handling standards for similar policy changes across different teams, regions, and customers.

[0006] Furthermore, policy changes often involve time constraints. For example, the effective date of the minimum wage, the deadline for submitting supplementary visa application materials, the social security declaration date, and the payroll settlement deadline can all directly affect customer service plans. If the system cannot establish a unified priority based on the urgency of deadlines, the severity of penalties, customer size, target exposure, and historical delay risks, high-risk cases may be delayed, while low-risk cases consume excessive human resources.

[0007] Therefore, a technical solution is needed that can transform policy changes into machine-readable rules, reverse map rule changes to specific business objects, calculate impact scores by combining historical work order experience and time-limit factors, and generate executable tasks to shorten the time gap between policy discovery and business execution updates. Summary of the Invention

[0008] The purpose of this invention is to provide a method and apparatus for analyzing the impact of policy change perception on human resource compliance, so as to solve the problems in the background art.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a method for analyzing the impact of policy change perception on human resource compliance, characterized by comprising the following steps: S101, collecting source texts of human resource policies from at least one country or region, and generating policy version fingerprints for the source texts; S102, performing language recognition, text extraction, attachment parsing, evidence location, deduplication and merging, and conflict marking on the source texts to obtain credible policy texts; S103, extracting policy entities, compliance obligations, triggering conditions, applicable subjects, effective time, deadline, penalty information, evidence fragments, and confidence levels from the credible policy texts using a constrained large language model, rule validator, and manual confirmation status, generating policy rule vectors and obligation condition diagrams; S104, performing difference calculations between the current policy rule vector and historical policy rule vectors to obtain rule change factors; S105, based on customer feedback... S106. Construct a reverse index for business objects, including objects such as images, employee objects, contract objects, work order objects, knowledge base article objects, salary configuration objects, and historical processing record objects; S107. Generate a retrieval plan based on the rule change factors, including exact key retrieval, range key retrieval, semantic key retrieval, and relational propagation retrieval, and retrieve the reverse index for business objects to obtain a set of candidate affected objects; S108. Perform structured matching, relational propagation, historical experience matching, knowledge base obsolescence calculation, and deadline urgency calculation on the set of candidate affected objects to obtain a set of affected objects and an impact score; S109. Generate tasks to be updated, explanations of reasons, recommended actions, responsible persons, deadlines, approval status, execution systems, and write-back addresses based on the impact scores; S100. Write back the task execution results to the audit records, and calibrate the rule confidence, differential threshold, retrieval scope, and impact score parameters based on the task execution results.

[0010] The policy source text includes at least one of the following: government official website announcements, immigration agency notices, tax authority rules, social security agency notices, Payroll calendars, court or regulatory interpretations, legal service provider updates, summaries of international organization rules, and the company's internal compliance rule library; the policy version fingerprint includes at least the source address, issuing entity, publication time, capture time, content hash, attachment hash, language identifier, applicable region, source level, collection channel, parsing status, parser version, evidence page number, and manual confirmation status.

[0011] Step S102 includes: extracting the main text from the webpage, PDF attachments, table attachments, and image attachments respectively; recording the paragraph number, page number, heading level, citation anchor point, and original text coordinates for the extraction results; when multiple sources have the same or similar policy content, deduplicating and merging them according to source level, publication time, content hash, and text similarity; when rule fields from multiple sources conflict, marking conflicting evidence fragments as pending review and reducing the confidence level of the corresponding policy rule vector.

[0012] In step S103, the constrained large language model outputs structured parsing results according to preset field patterns. The field patterns include at least region, jurisdiction, applicable subject, employment status, visa or permit type, salary cycle, social security or tax items, obligatory actions, effective date, expiration date, penalty, exception conditions, evidence fragments, and confidence level. The rule validator performs mandatory field validation, date validity validation, numerical unit validation, enumeration value validation, evidence reference validation, and conflict validation on the structured parsing results. Parsing results that fail the validation are marked as awaiting manual review.

[0013] The policy rule vector is represented as: The source_evidence is associated with the evidence fragment identifier, page number, or paragraph number in the credible policy text, while confidence is calculated based on the source level, field validation results, conflict status, and manual confirmation status.

[0014] The obligation condition graph includes obligation nodes, condition nodes, exception nodes, deadline nodes, responsible entity nodes, penalty nodes, evidence nodes, and business action nodes; the edges in the obligation condition graph include applicable edges, triggering edges, exclusion edges, deadline edges, responsibility edges, referencing edges, evidence edges, and action edges; the difference calculation includes text semantic difference, structured field difference, time constraint difference, condition graph difference, and source credibility difference, and is performed according to... Calculate the overall differential strength.

[0015] The reverse index for the business object uses the rule element key as the index key and the business object identifier, object type, object attribute summary, update time, evidence field, source system, relationship edge, data sensitivity level, and index version number as the index value. The rule element key includes at least one of the following: region key, subject key, obligation key, time limit key, visa key, salary cycle key, salary threshold key, social security project key, contract clause key, work order tag key, knowledge base topic key, and historical processing action key.

[0016] When constructing the inverted index of the business object, the customer contract service scope, employee work location, employee nationality, visa status, salary payment cycle, salary amount range, social security registration status, unfinished work order tags, work order processing actions, knowledge base article topics, salary calculation template fields, and customer risk level are mapped to the same rule element space. When a business object is added, deleted, has fields changed, or has relationship edges changed, an event-driven incremental index update mechanism is used to update the corresponding index key and index value.

[0017] The search plan includes exact key search, range key search, semantic key search, and relation propagation search. Exact key search is used for matching by region, visa type, employment status, and social security program; range key search is used for matching by salary threshold, date range, and employee size; semantic key search is used for matching policy obligations with work order descriptions, contract terms, or knowledge base topics; and relation propagation search is used to expand the list of potentially affected entities based on the associations between customers, employees, contracts, work orders, salary templates, and knowledge base articles.

[0018] The impact score Calculated based on the structured matching term M, relationship graph propagation term G, historical experience transfer term H, knowledge base obsolescence term K, deadline urgency term T, object exposure term E, source credibility term S, and uncertainty penalty term U, and satisfying the following conditions. Each weight is calibrated based on policy type, region, business line, historical manual review results, and task execution results.

[0019] The historical experience transfer item H is determined based on the similarity of historical work order texts, consistency of processing actions, consistency of object types, and final processing results; the knowledge base obsolescence item K is determined based on the policy version cited in the knowledge base articles, article update time, access frequency, and records of complaints or corrections; the uncertainty penalty item U is determined based on at least one of the following: policy source conflict, missing business fields, low model parsing confidence, and semantic hits without structured field support.

[0020] The explanations of causes include policy evidence explanations, business object hit explanations, relationship propagation path explanations, scoring factor explanations, and recommendation action explanations; among which, policy evidence explanations include evidence fragments, source levels, page numbers or paragraph numbers, business object hit explanations include the hit rule element keys and object fields, and relationship propagation path explanations include the relationship edges from directly hit objects to indirectly affected objects.

[0021] The task to be updated includes at least the task number, object type, object identifier, policy change summary, reason for impact, evidence fragment, hit field, priority, recommended action, responsible person, deadline, approval status, execution system, execution result, and write-back status; the task to be updated is sent to at least one of the following systems: customer success system, human resources information system, contract management system, work order system, knowledge base management system, RPA execution platform, payroll calculation system, and message notification system.

[0022] The task execution result includes at least one of the following: completed, no processing required, requires manual review, policy source conflict, missing object data, processing failure, customer confirmation in progress, and automatic execution success; the task execution result is used to update historical processing records, knowledge base version status, rule confidence, differential threshold, scoring model parameters, and the update time of the business object reverse index.

[0023] This includes access control, privacy protection, and audit control steps: recording the operator, operation time, changes, and source evidence for the policy rule base, business object inverted index, task execution records, and model parameter records; employing field anonymization, least privilege access, partitioned storage, and usage restrictions for data involving personal information; and displaying only necessary fields and evidence anchors related to the policy impact assessment when outputting explanations.

[0024] It includes a policy collection module, a text preprocessing module, a structured parsing module, a rule differential module, a reverse indexing module, a candidate retrieval module, an impact scoring module, a task generation module, an audit write-back module, an interface linkage module, and a permission auditing module; wherein each module is configured to perform the method described in any one of claims 1 to 15.

[0025] The reverse indexing module includes a rule element standardization unit, an index key generation unit, an inverted item maintenance unit, a relation edge maintenance unit, and an incremental update unit; the influence scoring module includes a matching feature calculation unit, a propagation path calculation unit, a historical experience matching unit, a deadline urgency calculation unit, an uncertainty penalty unit, and a scoring parameter calibration unit.

[0026] Compared with the prior art, the present invention has at least the following beneficial effects: First, it can transform changes in natural language policies into changes in structured rules, reducing the cost of manual reading and comparison; Second, by using reverse indexing of business objects, rules can be quickly located to objects, reducing full scans and manual investigations. Third, improve the interpretability of impact judgments by combining historical work order experience and the obsolescence of the knowledge base; Fourth, establish a unified priority based on the urgency of deadlines and the severity of penalties to reduce the probability of overlooking high-risk matters; Fifth, by writing back the task execution, an audit loop is formed, providing data for subsequent rule thresholds and scoring model calibration. Attached Figure Description Figure 1 This is a schematic diagram illustrating the closed-loop process from policy change to business execution update provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the module structure of the human resources compliance impact analysis device provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of the electronic device structure provided in an embodiment of the present invention. Detailed Implementation

[0027] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are used to explain the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. All equivalent substitutions, partial adjustments, or combinations made based on the concept of the present invention are within the scope of protection of the present invention.

[0028] Compared to the reference draft, this implementation further defines the data input and output between each layer, avoiding descriptions of system functions solely based on business concepts. The policy evidence layer outputs policy version fingerprints, evidence fragment identifiers, and trusted text blocks; the rule calculation layer outputs rule vectors, obligation condition graphs, and difference factors; the object index layer outputs hit objects, hit fields, and propagation paths; the task execution layer outputs task status, execution system response, and write-back address; and the audit feedback layer outputs manual confirmation tags, false recall tags, and parameter calibration samples. All of the above inputs and outputs can be stored as structured records, enabling each impact judgment to be reviewed.

[0029] In practical deployment, the policy evidence layer, rule calculation layer, and object indexing layer can exchange events via message queues. Event types include policy version addition, policy version update, policy parsing failure, business object field change, index reconstruction completion, task execution success, task execution failure, and manual review completion. Each event carries an event identifier, tenant identifier, region identifier, version number, and retry count. Through the event identifier and version number, the system can avoid repeatedly consuming the same policy change and can re-trigger the impact scoring after manual review.

[0030] In a preferred embodiment, the system employs a five-layer data flow: a policy evidence layer, a rule calculation layer, an object index layer, a task execution layer, and an audit feedback layer. The policy evidence layer only stores the original text, attachments, page numbers, paragraph numbers, and coordinates, without directly generating business conclusions. The rule calculation layer generates rule vectors, obligation condition diagrams, and rule change factors based on the evidence layer. The object index layer standardizes business object fields into rule element keys. The task execution layer generates executable items based on impact scores. The audit feedback layer records the results of manual review and external system write-back. Through this layering, a traceable chain of evidence exists between policy sources, model inference, business object matching, and task execution, reducing the risk of unauditable conclusions caused by "the model directly providing conclusions."

[0031] To enable those skilled in the art to implement this architecture, data can be exchanged between layers through a unified event object. This unified event object includes event type, event time, trigger source, associated policy version fingerprint, associated rule vector identifier, associated object identifier, processing status, and error code. Policy version changes, changes to business object fields, task execution write-backs, and manual reviews can all be entered into the system as events, ensuring the inverted index and scoring model are continuously updated.

[0032] like Figure 1 As shown, the human resources compliance impact analysis system in this embodiment includes a policy acquisition layer, a rule understanding layer, a rule difference layer, a business object indexing layer, an impact scoring layer, a task execution layer, and an audit feedback layer. The policy acquisition layer is responsible for obtaining source policy texts from government websites, immigration authorities, tax authorities, social security agencies, payroll calendars, regulatory interpretations, and internal rule bases. The rule understanding layer is responsible for converting natural language policy texts into policy rule vectors and obligation condition diagrams. The rule difference layer is responsible for comparing new and old policy rules. The business object indexing layer is responsible for maintaining the mapping between customers, employees, contracts, work orders, knowledge base articles, salary configurations, and historical processing records and rule elements. The impact scoring layer is responsible for generating object-level impact scores and causal explanations. The task execution layer is responsible for issuing tasks to external business systems. The audit feedback layer is responsible for receiving execution results and writing back model calibration data.

[0033] The aforementioned layers can be deployed on the same server or deployed separately in a microservices manner. The policy collection layer and business object indexing layer can be triggered by scheduled tasks, message queues, or event subscriptions; the rule understanding layer can call a locally deployed large language model or an external language model encapsulated through a security gateway; the rule difference layering and impact scoring layer can be implemented collaboratively using a rule engine, vector retrieval engine, relational graph database, and machine learning model; the task execution layer can connect to the customer success system, human resources information system, contract management system, work order system, and knowledge base system through REST interfaces, message queues, RPA robots, or database views.

[0034] The policy version fingerprinting optimization adopts a two-level hash structure. The first level is the source file hash, used to identify whether the original text of web page text, PDF attachments, table attachments, or image attachments has changed. The second level is the normalized content hash, used to identify whether the substantive content has changed after removing headers, footers, line breaks, and formatting noise. When the source file hash changes but the normalized content hash does not change, the system can simply record the collected version without triggering rule differentiation; when the normalized content hash changes, the system enters the structured parsing and differentiation process.

[0035] Regarding the credibility of policy sources, the system can set source levels based on the issuing entity, data collection channel, historical consistency, and manual verification status. For example, the source level of original announcements from government authorities is higher than that of third-party legal summaries; if the same source is repeatedly verified in historical tasks as having mistranslation or lag, its source credibility can be reduced. Source credibility not only participates in the handling of evidence conflicts but also influences the source credibility item S in the scoring.

[0036] In step S101, the system pre-configures a policy source list. Each policy source record includes the source name, source address, source type, applicable country or region, language, crawling frequency, source level, and responsible person. The collection module performs crawling or subscription based on the policy source list and performs text extraction, noise filtering, attachment parsing, and metadata completion on the acquired text. For web page announcements, the system records the title, text, publication time, update time, and page link; for PDF or image attachments, the system records the page number, attachment hash, and OCR confidence score; for updates from third-party legal service providers, the system also records the service provider's name and the original policy source cited.

[0037] The system generates a policy version fingerprint for each policy text. The policy version fingerprint may include fields such as source_id, source_url, publisher, publish_time, fetch_time, content_hash, attachment_hash, language, country, jurisdiction, source_level, parser_version, and confirm_status. content_hash is used to determine if the text has undergone substantial changes, attachment_hash is used to determine if attachments have been replaced, parser_version is used to trace the versions of the text extraction and structured parsing algorithms, and confirm_status indicates whether the policy has been confirmed by compliance personnel.

[0038] When the same policy appears from multiple sources, the system merges them based on source level, publication time, content hash, and text similarity. If the content from the government website and a third-party supplier is identical, the government website is used as the primary source of evidence, and the third-party supplier as a secondary source. If the two sources differ in their descriptions of the effective date, applicable subjects, or penalties, the system generates a policy source conflict event and marks the relevant rule vectors as pending manual review. This approach allows subsequent impact analysis to carry explicit evidence, rather than relying solely on abstract text.

[0039] Credible policy text preprocessing also includes evidence segmentation. The system generates evidence_ids based on heading level, clause number, table rows and columns, appendix page numbers, and original text coordinates. Each evidence_id includes at least policy_version_id, page_no, paragraph_no, bounding box, text_hash, language, translated_text, and confidence. The source_evidence field in subsequent rule vectors references this evidence_id, rather than just the entire policy document, thus ensuring that causal explanations can pinpoint specific evidence segments.

[0040] When policy texts contain multiple language versions, the system retains both the original and translated texts, using the translation as an auxiliary field in the parsing process. If the original and translated texts are inconsistent in terms of values, dates, or obligations, the rule validator marks the corresponding field as "translation_conflict." This marking increases the uncertainty penalty item U and prioritizes the corresponding task for manual review.

[0041] In step S102, the text preprocessing module performs language recognition, paragraph segmentation, text extraction, attachment parsing, table structure restoration, and evidence location on the policy source text. For multilingual text, the system first identifies the original language and then decides whether to generate a machine-translated version based on business configuration. Even if a translated version is generated, the system retains the original sentences, page numbers, and paragraph positions so that auditors can return to the original evidence during review.

[0042] The preprocessing result can be represented as a set of evidence fragments. Each piece of evidence includes a fragment identifier, original text, translated text, page number, paragraph number, start and end character positions, table coordinates, attachment identifier, and extraction confidence level. For tabular policies, such as minimum wage tables or social security contribution rate tables, the system restores the table rows and columns to structured fields and associates each field with the original cell coordinates.

[0043] To prevent subsequent large language models from generating rules without evidence, the preprocessing module outputs an evidence whitelist to the structured parsing module. The structured parsing module can only use fragments from the evidence whitelist to generate rule fields. When the obligatory action, effective time, or applicable subject output by the model cannot be located in the evidence fragment, the rule validator marks the field as a no-evidence field and lowers the rule confidence or requires manual review.

[0044] The constrained large language model does not directly output the final business conclusion, but only outputs candidate rules that conform to the field pattern. The field pattern can be implemented using JSON Schema, table structure fields, or protocol buffer objects. Each field sets the field type, enumeration range, evidence reference requirements, and confidence threshold. For example, the effective time field must be able to reference evidence fragments containing dates or relative periods; the salary threshold field must contain a number, currency, and period simultaneously; the obligation action field must belong to a preset set of actions such as submission, notification, payment, registration, update, record retention, suspension of execution, or manual review.

[0045] The obligation condition diagram is used to express the applicable logic of policy rules. If the policy text states, "Employees holding A-type work visas and undergoing renewal must submit proof of employment within 30 days from the date of publication, except for those who have already completed the approval process under the old rules," the system generates nodes for: A-type visa holders, renewal applicants, those obligated to submit proof of employment, those within 30 days, and those who have completed the approval process (exceptions). It also establishes trigger edges, deadline edges, and exclusion edges. Through the graph structure, the system can identify different change types during differential processing, such as adding conditions, deleting exceptions, bringing forward deadlines, and increasing the intensity of obligations.

[0046] During the structured parsing phase, the system does not simply input free text into the large language model and receive natural language summaries. Instead, it inputs constrained field patterns, enumeration tables, example formats, and prohibited items into the model. Field patterns require the model to output, item by item, the region, applicable subject, obligatory action, effective date, deadline, penalty, exception conditions, and evidence fragment identifier. Prohibited items require the model not to output fields that cannot be traced back to the original text evidence. After the model outputs, the rule validator checks each field to see if a corresponding anchor can be found in the evidence fragment set; fields that cannot be traced back are not included in the formal rule vector.

[0047] For time fields, the system standardizes natural language expressions such as "date of publication," "next reporting cycle," and "from September 1, 2026" into computable time constraints, while retaining the original expressions before standardization. When a specific date cannot be determined for a time expression, the system marks the field as a relative time or a time pending review and adds an uncertainty penalty to the impact score. For numerical fields, the system records the original unit, standardized unit, and conversion rules. For example, it maps monthly salary, hourly wage, social security contribution rate, and the number of days in advance for reporting to different numerical types to avoid erroneous comparisons between different units.

[0048] In step S103, the structured parsing module performs entity identification and obligation extraction on the credible policy text. Entity identification objects include country or region, jurisdiction, applicable entity, employment status, visa type, salary cycle, minimum wage, social security items, tax items, reporting deadline, penalties, exceptions, responsible entity, and effective date. Obligation extraction objects include mandatory actions, prohibited actions, required materials, recipients to be notified, amounts or proportions to be adjusted, and business configurations to be updated.

[0049] The structured parsing module calls the large language model to generate candidate rules. To reduce the risk of model illusion, the system limits the output fields, field enumerations, evidence fragment positions, and confidence calculation methods in the prompt words, and requires the model to output the source sentence for each obligation. Subsequently, the rule validator performs field integrity checks, enumeration validity checks, date format checks, numerical unit checks, and evidence existence checks on the model output. Fields that fail the checks are entered into a queue for review.

[0050] The policy rule vector can be represented as In a scenario involving a change in minimum wage policy, `country` can be the target country code, `subject` can be a full-time employee, `obligation_action` can be a salary not lower than the minimum wage standard, `effective_time` can be the policy's effective date, `penalty` can be a high penalty, and `source_evidence` can point to a sentence in the original policy announcement.

[0051] For complex policies, the system further constructs an obligation condition graph. Nodes in the obligation condition graph include obligation nodes, condition nodes, exception nodes, time-limit nodes, responsible entity nodes, penalty nodes, and evidence nodes; edges include applicable edges, triggering edges, exclusion edges, time-limit edges, responsible edges, citation edges, and evidence edges. For example, a visa policy stipulates that "applicants currently processing visa renewals must also submit proof of employment, except for short-term business visas." The system represents submitting proof of employment as an obligation node, processing visa renewals as a triggering condition node, and short-term business visas as an exception node, and establishes triggering edges and exclusion edges for each.

[0052] Rule difference calculation can be divided into two stages: candidate matching and difference quantization. The candidate matching stage first pairs the current rule with historical rules based on region, applicable subject, obligatory action, and evidentiary subject, avoiding misjudging different policy subjects as version changes of the same rule. The difference quantization stage calculates the semantic difference separately. Field Difference Time difference Conditional graph difference Difference between source and source .

[0053] in, It can calculate based on field additions, field deletions, and changes in field values; It can be calculated based on the number of days the effective date is advanced, the number of days the deadline is shortened, and changes in the application cycle; It can be calculated based on the node edit distance and edge edit distance in the obligation condition graph. If the differential strength... If the threshold is less than the low threshold, the system only generates observation records; if the threshold is between the low and high thresholds, the system generates ordinary impact analysis tasks; if the threshold is higher than the high threshold and the penalty intensity is high, the system generates high-priority impact analysis tasks.

[0054] Rule-based differentiation is not a simple full-text similarity comparison. The system first identifies historical versions of the same or similar policies based on policy version fingerprints, and then aligns them at the rule vector field level. If field names are the same but values ​​are different, a structured field differentiation is generated; if the expressions of obligations are different but the semantic vectors are similar, a semantic differentiation is generated; if the effective time, deadline, or reporting cycle changes, a time constraint differentiation is generated; if triggering edges, exclusion edges, responsibility edges, or evidence edges in the obligation condition graph are added, deleted, or their direction changes, a condition graph differentiation is generated.

[0055] Each rule change factor stores the difference source and evidence. The difference source includes the old rule vector identifier, the new rule vector identifier, the old evidence fragment, the new evidence fragment, the field name, the old value, the new value, the difference type, and the difference strength. By retaining this difference object, subsequent task explanations can explain "why a change was considered to have occurred," rather than just "why action was needed after the change."

[0056] In step S104, the rule differentiation module reads historical rule vectors from the rule base for the same region, the same subject, and the same obligation, and compares them with the current rule vectors. The comparison dimensions include semantic differentiation, structured field differentiation, time constraint differentiation, condition graph differentiation, and source credibility differentiation. Semantic differentiation is used to detect whether the meaning of policy statements has changed; structured field differentiation is used to detect whether numerical values, subjects, document types, salary cycles, or social security items have changed; time constraint differentiation is used to detect whether the effective date and deadline have been advanced or postponed; condition graph differentiation is used to detect whether the applicable conditions, exception conditions, and responsible subjects have changed; and source credibility differentiation is used to detect whether the source level or manual confirmation status has changed.

[0057] The rule change factor Delta_r should include at least the change type, changed field, old value, new value, evidence fragment, effective window, affected region, credibility, conflict status, and review status. The overall differential strength can be determined according to... Calculation, where to It can be configured according to policy type. For example, time constraint differential weights are higher when the payroll deadline changes; structured field differential weights are higher when the minimum wage changes; and semantic differential and conditional graph differential weights are higher when regulatory interpretations change.

[0058] When the differential strength is below the first threshold, the system only records version updates; when the differential strength is above the first threshold but below the second threshold, the system generates a low-priority knowledge base review task; when the differential strength is above the second threshold, or involves high penalties, short time limits, expanded scope of application, changes in responsible entities, or policy source conflicts, the system triggers a reverse retrieval of business objects. This hierarchical mechanism can avoid minor text changes causing a large number of tasks, while ensuring that substantive compliance risks are promptly addressed in the processing flow.

[0059] The core of inverted indexes is not simple keyword indexing, but rule-based feature space indexing. The system first standardizes policy rule fields into rule feature keys, and then maps business object fields to the same key space. Taking a salary threshold policy as an example, rule feature keys can include country: target country, subject: full_time_employee, pay_cycle: monthly, salary_range: [old_value, new_value], and obligation: min_wage. After an employee's work location, employment status, pay cycle, and salary range are mapped to the above key space, they can be quickly located using range indexing.

[0060] To reduce the cost of a full rebuild, the inverted index uses an incremental update mechanism. When a business object field change event occurs, the system first reads the object snapshot and compares the set of rule element keys before and after the change; for keys that have disappeared, the inverted item is deleted; for newly added keys, the inverted item is written; and for keys that have not changed, only the object summary version number is updated. If the object relationship edges change, such as an employee being transferred to a new customer or a knowledge base article updating its citation policy, the system simultaneously updates the relationship edges and edge weights in the graph index.

[0061] The core of reverse indexes lies in mapping object fields, which are originally scattered across different business systems, to rule-based element keys. For example, the workplace field in the employee system, the service region field in the contract system, the country tag in the work order system, and the region topic in the knowledge base article can all be mapped to region keys; visa type, visa status, renewal date, and immigration service work order tags can be mapped to visa keys and duration keys; and salary amount, salary cycle, Payroll calendar, and salary template fields can be mapped to salary threshold keys and salary cycle keys.

[0062] To avoid index leakage of sensitive information, the index values ​​prioritize storing object identifiers, object types, necessary field summaries, and evidence field identifiers, rather than complete personal data. When viewing the complete object is required, the task execution system performs a secondary read based on permissions. This supports both fast retrieval and meets the requirements of least privilege access and auditing.

[0063] In step S105, the system maps business objects to a unified rule element space. Key fields for customer objects may include the customer's country, service country, service scope, contract effective date, contract terms, customer size, customer risk level, and customer contact person; key fields for employee objects may include work location, nationality, employment status, visa type, visa expiry date, salary amount, salary cycle, social security registration status, and benefits; key fields for contract objects may include service scope, liability boundaries, notification obligations, fee adjustment clauses, and applicable law; key fields for work order objects may include work order type, work order tag, processing status, deadline, historical processing actions, and expert remarks; key fields for knowledge base articles may include topic, applicable region, cited policy version, update time, and access frequency; key fields for salary configuration objects may include salary template, tax items, social security ratio, reporting cycle, and account closure date.

[0064] The index key for an inverted index can be generated by combining rule elements. For example, a region key can be represented as `country:SG` or `jurisdiction:US-CA`; a visa key as `permit:A`; a pay cycle key as `pay_cycle:monthly`; an obligation key as `obligation:min_wage` or `obligation:visa_material`; a deadline key as `due_window:2026-09`; a contract clause key as `contract_clause:notice_duty`; and a knowledge base topic key as `kb_topic:minimum_wage`. Index values ​​include the business object identifier, object type, object attribute summary, update time, evidence field, source system, relation edges, and data sensitivity level.

[0065] To improve retrieval efficiency, inverted indexes can simultaneously maintain exact indexes, range indexes, semantic indexes, and graph indexes. Exact indexes are used for discrete fields such as region, visa type, and employment status; range indexes are used for salary ranges, date ranges, and employee size; semantic indexes are used for work order descriptions, contract terms, and knowledge base text; and graph indexes are used to propagate relationships between customers, employees, contracts, work orders, knowledge base articles, and salary templates. Multiple types of indexes can share a unified object identifier, enabling different search results to be merged and deduplicated within the same candidate set.

[0066] When a business object changes, the interface module receives an event message. This message can include the object type, object identifier, changed fields, old value, new value, change time, and source system. The reverse index module recalculates the relevant rule element keys based on the changed fields and updates only the affected index entries. For example, a change in employee visa status only requires updating the index entries related to the visa key, duration key, and work order relationship edge; a change in customer contract service scope only requires updating the contract terms key, region key, and customer service scope key. Through incremental updates, the system maintains index real-time performance while reducing the computational cost of rebuilding the index.

[0067] The search plan is dynamically generated based on rule change types. For explicit fields such as region, visa type, and social security program, exact key searches are prioritized; for salary thresholds, deadlines, and employee size, range key searches are used; for contract terms, work order descriptions, and knowledge base text, semantic key searches are used; and for indirect influences between customers, employees, contracts, work orders, and the knowledge base, relational propagation searches are used. Each search branch outputs candidate objects, hit keys, hit fields, and initial confidence scores.

[0068] Relationship propagation sets propagation depth and attenuation coefficients. Directly targeted employees can propagate to their respective clients, related contracts, outstanding work orders, and corresponding salary templates; directly targeted policies and rules can propagate to knowledge base articles that reference those rules; directly targeted contract clauses can propagate to successful client tasks and historical disputed work orders. The longer the propagation path, the lower the propagation weight; however, if historical work order similarity is high or the client's risk level is high, the propagation weight can be appropriately increased.

[0069] In step S106, the system generates a search plan based on the rule change factors. If the rule change factors include region, applicable subject, and obligation, the system first performs an exact key search; if the rule change factors involve minimum wage, social security contribution rate, or expiration date, the system performs a range key search; if the rule change factors involve natural language obligations or regulatory interpretations, the system performs a semantic key search; if the initial hit object has a business relationship with other objects, the system performs a relationship propagation search.

[0070] The candidate object retrieval results can include directly hit objects and propagated hit objects. Directly hit objects are those whose object fields directly satisfy the rule change factor, such as employees whose workplace is located in the target country and whose salary is below the new threshold. Propagated hit objects are objects obtained through relational edge expansion, such as customer contracts, outstanding work orders, salary templates, and knowledge base articles related to affected employees. The system records the path length, edge type, and propagation reason for each propagation path to distinguish between direct and indirect impacts during subsequent scoring.

[0071] To avoid an excessively large candidate set, the system can set search filtering conditions. For example, in scenarios involving changes in visa application requirements, the system first filters employees by region and visa type, and then filters employees who are in the visa renewal window or have outstanding visa work orders; in scenarios involving changes in minimum wage, the system first searches for workplace and salary range, and then filters employees whose salaries are below or close to the new threshold; in scenarios involving changes in regulatory interpretations, the system first searches for contracts that include the relevant service scope, and then expands the potential objects through work orders and semantic indexes in the knowledge base.

[0072] The structured matching term M can be calculated based on the number of hit fields, key field weights, and field consistency; the relationship graph propagation term G can be calculated based on propagation distance, edge type, and edge weight; the historical experience transfer term H can be calculated based on the similarity of historical work order texts, consistency of processing actions, and final processing results; the knowledge base obsolescence term K can be calculated based on the difference between the policy version cited in the knowledge base articles and the current policy version; the deadline urgency term T can be calculated based on the remaining processing days and the safety buffer days; and the object exposure term E can be calculated based on the number of employees, customer size, contract amount, or business frequency.

[0073] Explanations and scores are generated simultaneously. For each output object, the system saves at least three levels of explanation: the first level is the policy change explanation, describing the policy fields and evidence fragments that have changed; the second level is the object hit explanation, explaining which fields of the object hit the rule element keys; and the third level is the action suggestion explanation, explaining why a notification, verification, configuration update, knowledge base revision, or manual review task is generated. The explanation content must not deviate from the evidence fragments and object fields, and should avoid outputting only model inferences.

[0074] The impact of the scoring output is not displayed as a standalone black-box result, but is saved together with the explanation of the cause, the hit fields, and evidence fragments. The system can break down the score into several sub-items, such as structured field hit score, relationship propagation score, historical experience score, deadline urgency score, and uncertainty deduction value. When business personnel view the task, they can see why the object was hit, why it has a high priority, which fields have uncertainty, and whether manual review is required.

[0075] When the impact score exceeds the automatic execution threshold and the uncertainty penalty is below the preset threshold, the system can generate an automated execution task. When the impact score is high but there are policy source conflicts, missing object fields, or low model resolution confidence, the system prioritizes generating a review task rather than directly executing the task. This strategy can improve the level of automation while avoiding high-risk erroneous execution.

[0076] In step S107, the influence scoring module calculates an influence score for each candidate object. The influence score can be represented as... Where M represents the structured matching strength, G represents the relationship graph propagation term, H represents the historical experience transfer term, K represents the knowledge base obsolescence term, T represents the deadline urgency term, E represents the object exposure term, S represents the source credibility term, and U represents the uncertainty penalty term.

[0077] Structured matching strength can be calculated based on the number of matched rule fields, the weight of key fields, and the distance between field values. For example, employee work location, visa type, and salary amount are high-weight fields; the closer the salary amount is to the new minimum wage threshold, the higher the matching strength. Relationship graph propagation items can be calculated based on propagation path length and edge type, with direct-hit objects scoring higher than two-hop propagation objects; historical experience transfer items can be calculated based on historical work order text similarity, consistency of processing actions, and final processing results; knowledge base obsolescence items can be calculated based on the policy version cited in the article, update time, and access frequency; and deadline urgency items can be calculated based on the remaining days between the current date and the policy's effective date or expiration date.

[0078] Uncertainty penalty items are used to reduce the scores of candidates with missing data, conflicting evidence, or low model resolution confidence. For example, if the employee salary field is missing, the system cannot directly determine the impact of the minimum wage and needs to increase the priority of manual review but reduce the reliability of automatic execution; if there is a policy source conflict, the system can generate a review task instead of directly generating a customer notification; if the semantic index is hit but lacks structured field support, the system indicates in the explanation of cause that the hit is semantically relevant rather than having a definite impact.

[0079] The scoring module simultaneously generates a causal explanation. This explanation includes the matched rule elements, matched business object fields, similar historical work orders, evidence fragments, time windows, and sources of uncertainty. For example, the system might output, "This employee works in the target country, has a Category A visa, and is currently processing a visa renewal work order. New policy requirements for Category A visa renewal materials have been added, and the submission deadline is only 10 days away. Therefore, a high-priority document supplementation task is generated." The causal explanation, along with the scoring, is entered into the task object, allowing business personnel to quickly understand the task's origin.

[0080] Task templates are pre-configured according to object type. Employee tasks may include data supplementation, salary verification, visa status confirmation, and social security registration confirmation; customer tasks may include customer notification, service scope confirmation, and contract term review; knowledge base tasks may include policy version replacement, operation guide updates, and expired content removal; system configuration tasks may include salary template parameter updates, Payroll calendar updates, and RPA process parameter updates.

[0081] For automated task execution, the system checks approval status, data integrity, and idempotency keys before execution. Idempotency keys are generated from the task number, object identifier, policy version number, and recommended action to avoid repeated updates to external systems for the same policy change. After execution, the external system returns the execution result, execution time, execution account or robot identifier, error code, and write-back address. If execution fails, the system chooses to retry, transfer to manual intervention, or generate an operation and maintenance task based on the error type.

[0082] In step S108, the task generation module generates tasks to be updated based on the object type and impact score. For customer objects, tasks may include customer notification, service scope confirmation, contract supplement confirmation, or successful customer follow-up; for employee objects, tasks may include data supplementation, salary verification, visa status confirmation, or social security registration verification; for contract objects, tasks may include clause review, responsibility boundary confirmation, or cost adjustment reminders; for work order objects, tasks may include processing path updates, priority upgrades, or supplementary evidence; for knowledge base articles, tasks may include policy citation version updates, operation guide revisions, or removal of invalid articles; for salary configuration objects, tasks may include salary template adjustments, social security ratio updates, or Payroll calendar adjustments.

[0083] Each task must include at least a task number, object type, object identifier, policy change summary, reason for impact, evidence snippets, priority, recommended action, responsible person, deadline, approval status, execution system, and write-back status. The task generation module can match task templates based on task type. For example, a visa material change task template includes an employee list, material list, submission deadline, and communication script; a minimum wage change task template includes employee salary difference, client contract service scope, salary adjustment verification action, and client notification draft; and a payroll deadline change task template includes a new deadline, safety buffer period, client confirmation status, and internal account closure arrangements.

[0084] When the recommended action is a low-risk, standardized operation, the system can invoke an RPA execution platform to complete it automatically. For example, replacing policy citations in knowledge base articles, updating Payroll calendar reminder dates, supplementing work order template fields, and generating draft customer notifications can all be performed by RPA or process automation tools. For high-risk operations involving contract clause modifications, formal customer notifications, employee data processing, or salary adjustments, the system only generates suggestions and drafts, which must be confirmed by authorized personnel before execution.

[0085] The approval mechanism can be configured based on the risk level of the target, the severity of policy penalties, and the type of task. High-risk tasks require approval from the compliance officer, medium-risk tasks require confirmation from the business officer, and low-risk knowledge base update tasks can be automatically routed. Approval results and opinions are recorded in the task audit form and used as training samples for subsequent model calibration.

[0086] Audit write-back not only saves the final state but also a snapshot of the features used in the impact assessment process. This snapshot includes rule differential strength, hit rule element keys, propagation paths, historical similar work order identifiers, remaining processing days, source credibility, and reasons for uncertainty penalties. Even if subsequent business object fields change, auditors can still review why the system made that impact assessment at the time.

[0087] Parameter calibration can employ a tiered calibration strategy. Global-level parameters are applicable to all regions and policy types; regional-level parameters are applicable to specific countries or regions; and business line-level parameters are applicable to different scenarios such as salaries, visas, social security, contracts, or knowledge bases. When manual review results show that the false recall rate for a certain region is too high, the system only adjusts the weights for that region or business line, without affecting the scoring models that are already running stably in other regions.

[0088] In step S109, the audit write-back module receives the task execution result. The execution result may include completed, no processing required, manual review required, policy source conflict, missing object data, processing failed, customer confirmation in progress, and automatic execution successful. The system writes the execution result to the audit log and updates the historical processing record, knowledge base version status, rule confidence, differential threshold, and impact scoring model parameters.

[0089] If a large number of tasks of a certain type are manually marked as not requiring processing, it indicates that the rule elements or scoring weights of that type may be too broad, and the system can reduce the weight of the corresponding search key or propagation edge; if a certain type of object is frequently manually upgraded to high risk under low scores, it indicates that the scoring model underestimates certain business factors, and the system can increase the weight of the corresponding field; if policy source conflicts occur frequently, the system can increase the review priority of that source or reduce its source credibility.

[0090] Model calibration can employ a combination of expert rule calibration and machine learning calibration. During the initial deployment phase, weights are configured by compliance experts according to policy type. After running for a period, the system uses historical policy changes, manual review results, and task execution results to form training samples. Positive samples include objects that experts confirmed required processing and were ultimately completed, while negative samples include objects that experts confirmed did not require processing or were mistakenly recalled. Training features include rule difference strength, number of structured matching fields, relationship propagation distance, historical work order similarity, object risk level, knowledge base access frequency, remaining processing days, and source confidence.

[0091] Access control employs a separation of rule-based evidence permissions and business object permissions. Compliance experts can view policy evidence and rule vectors, but are not required to view complete employee profiles; customer success personnel can view the tasks and necessary hit fields for their assigned clients, but cannot view sensitive fields for other clients or unrelated employees; model training tasks only read anonymized object identifiers, rule element keys, and human feedback labels.

[0092] When outputting the explanation of causes, the system anonymizes fields such as ID card number, address, bank account number, complete date of birth, and personal contact information. If the impact assessment only requires salary range, workplace, visa type, or social security status, the system does not read or display other personal fields. Through the minimum necessary fields and evidence anchoring mechanism, the system can balance compliance impact analysis and personal information protection.

[0093] The system is equipped with access control and audit control. The policy rule base, business object inverted index, task execution records, and model parameters all record the operator, operation time, changes, and source evidence. For data involving personal information, the system employs field anonymization, least privilege access, and partitioned storage to ensure that impact analysis only reads the necessary fields relevant to compliance judgments.

[0094] Business object indexes can use object snapshot summaries instead of complete personal profiles. Employee object snapshots can save only work location, employment status, visa type, salary range, social security status, and relevant work order identifiers, excluding complete ID numbers, addresses, or bank account numbers. When outputting explanations, the system only displays the hit fields and evidence anchors, excluding sensitive information unrelated to policy impact assessments.

[0095] For cross-country or cross-regional deployment scenarios, the system can store indexes and task records by region. Policy rules can be shared across regions, but employee personal information and sensitive fields in customer contracts are stored in their respective regions according to data residency requirements. Cross-regional impact analysis only transmits rule element keys, object anonymization identifiers, and risk summaries to avoid unnecessary cross-border data transfer.

[0096] In a more specific table structure, the rule vector table includes rule_id, policy_version_id, judgment, subject, obligation_action, effective_time, due_time, penalty_level, exception_condition, evidence_id, confidence, and review_status; the inverted index table includes index_key, object_type, object_id, matched_field, object_snapshot_version, relation_group_id, and updated_at; and the task evidence table includes task_id, rule_id, evidence_id, object_id, matched_field, explanation_text, and evidence_hash.

[0097] For ease of implementation, the above tables can be stored in relational databases, document databases, graph databases, or search engines. Exact keys and range keys can be stored in relational databases or search engines; semantic keys can be stored in vector retrieval services; and relation edges can be stored in graph databases or relational tables. Different storage formats are linked through rule_id, object_id, and evidence_id to ensure that search results return to the same audit path.

[0098] In one implementation, the policy rule base includes a policy version table, an evidence fragment table, a rule vector table, an obligation condition graph, and a rule difference table. The policy version table stores the version fingerprints of the policy sources; the evidence fragment table stores the original sentences, translated text, page numbers, and coordinates; the rule vector table stores the structured rule fields; the obligation condition graph stores the nodes and edges; and the rule difference table stores the difference results between the old and new rules.

[0099] The business object index includes an index key table, an inverted index table, an object snapshot table, and an object relationship table. The index key table stores the region key, obligation key, term key, visa key, salary key, social security item key, and contract term key; the inverted index table stores the mapping relationship between index keys and business object identifiers; the object snapshot table stores a summary of necessary fields used for impact analysis; and the object relationship table stores the association edges between customers and employees, employees and work orders, contracts and customers, knowledge base articles and policy rules, and salary templates and customers.

[0100] The task audit database includes a task table, a task evidence table, an approval record table, an execution result table, and a model feedback table. The task table stores basic task information; the task evidence table stores policy evidence and business object evidence; the approval record table stores the approver, approval opinion, and approval time; the execution result table stores the external system write-back status; and the model feedback table stores manual review labels and model calibration features. This table structure supports subsequent auditing, review, and model training.

[0101] The interface linkage preferably adopts the adapter pattern. Each external system adapter is responsible for field mapping, authentication, rate limiting, error code conversion, and write-back confirmation. For example, the payroll system adapter converts the payroll template identifier, payroll cycle, and new percentage fields in the system task into payroll system interface parameters; the knowledge base adapter converts the policy version number, evidence fragment, and expired paragraph identifier into an article revision task; and the work order system adapter converts the reason explanation and recommended action into a work order description, tag, and deadline.

[0102] When external systems lack stable interfaces, the RPA execution platform can read execution script templates and parameters from the task table, simulating manual login to complete queries, data entry, or updates. The RPA execution results still need to be written back to the task audit database, including screenshots or log addresses, execution steps, success indicators, and failure reasons. This ensures that even if different customers or regions have varying system integration capabilities, it does not affect the closed loop of policy changes to business execution.

[0103] The interface module can connect to external systems via REST interfaces, message queues, database views, or file exchange. Each task deployment carries a task identifier, object identifier, evidence fragment, recommended action, and write-back address, facilitating the external system to send back processing results upon task completion. For systems that cannot directly expose interfaces, the RPA execution platform can simulate manual operations to complete queries, data entry, and updates.

[0104] The interface module is also used to receive business object change events from external systems. For example, changes in employee visa status, customer contract renewals, knowledge base article publications, work order closures, salary cycle adjustments, and social security configuration updates can all trigger incremental updates to the inverted index. Through this event-driven approach, the business object inverted index can maintain high real-time performance, avoiding the use of expired object data for impact analysis when policy changes occur.

[0105] When an external system becomes unavailable, the task execution layer sets the task status to "pending retry" and records the interface error code, request time, and number of retries. If the maximum number of retries is exceeded, the system generates an operation and maintenance task or manually exports a list. Through this exception handling mechanism, policy impact analysis will not lose its audit chain due to the temporary unavailability of a single external system.

[0106] like Figure 2As shown, the present invention also provides a human resources compliance impact analysis device. This device includes a policy acquisition module, a text preprocessing module, a structured parsing module, a rule differentiation module, a reverse indexing module, a candidate retrieval module, an impact scoring module, a task generation module, an audit write-back module, an interface linkage module, and a permission auditing module.

[0107] The policy acquisition module collects source policy texts and generates policy version fingerprints. The text preprocessing module extracts the main text, performs language recognition, deduplication and merging, parses attachments, and locates evidence in the source policy texts. The structured parsing module generates policy rule vectors and obligation condition graphs using a large language model and rule validator. The rule differencing module compares current rules with historical rules and generates rule change factors. The reverse indexing module maps business objects to a unified rule element space and maintains precise indexes, range indexes, semantic indexes, and graph indexes.

[0108] The candidate retrieval module retrieves a set of candidate affected objects based on rule-based change factors. The impact scoring module calculates the impact score and causal explanation for each candidate object. The task generation module generates tasks to be updated, recommended actions, responsible persons, and deadlines according to object type. The audit write-back module records task execution results and uses them for rule confidence, differential thresholds, and scoring model parameter calibration. The interface linkage module interacts with customer success systems, human resource information systems, contract management systems, work order systems, knowledge base management systems, payroll calculation systems, RPA execution platforms, and message notification systems. The access control audit module performs field anonymization, access control, operation auditing, and evidence tracing.

[0109] In practical deployment, electronic devices can be single servers, server clusters, cloud servers, or private deployment environments within an enterprise. When the processor executes computer programs, it can invoke databases, object storage, vector retrieval services, graph databases, message queues, and RPA execution services. In addition to storing program code, the memory can also store policy version tables, evidence fragment tables, rule vector tables, obligation condition diagrams, index key tables, inverted item tables, object snapshot tables, task tables, approval record tables, and model feedback tables.

[0110] Computer-readable storage media can store program instructions for performing the above methods. When the program instructions are executed by the processor, the processor executes them in the following order: policy collection, evidence location, structured parsing, rule differentiation, index retrieval, relation propagation, impact scoring, task generation, audit write-back, and model calibration. Alternatively, policy collection, business object index updating, and historical work order vectorization can be performed in parallel without affecting the final result.

[0111] like Figure 3As shown, the present invention also provides an electronic device, including at least one processor, at least one memory, a network interface, and a business system interface. The memory stores a computer program, a policy rule base, a business object index, historical processing records, and task audit records. When the computer program is executed by the processor, the processor implements the steps in any of the above method embodiments.

[0112] The present invention also provides a computer-readable storage medium on which a computer program is stored. When executed by a processor, the computer program performs steps such as policy source acquisition, structured parsing, rule differentiation, reverse index retrieval, impact scoring, task generation, and audit write-back. The computer-readable storage medium may be a read-only memory, random access memory, disk, optical disk, flash memory, or other media capable of storing program code.

[0113] It should be understood that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. Those skilled in the art can make equivalent substitutions or modifications to the rule vector field, difference model, index structure, scoring model, task template, interface method, and system deployment method without departing from the concept of the present invention, and all such substitutions or modifications should fall within the scope of protection of the present invention.

Claims

1. A method for analyzing the impact of policy change perception on human resource compliance, characterized in that, The process includes the following steps: S101, collecting source texts of human resources policies from at least one country or region, and generating policy version fingerprints for the source texts; S102, performing language recognition, text extraction, attachment parsing, evidence location, deduplication and merging, and conflict marking on the source texts to obtain credible policy texts; S103, using a constrained large language model, rule validator, and manual confirmation status, extracting policy entities, compliance obligations, triggering conditions, applicable subjects, effective time, deadline, penalty information, evidence fragments, and confidence levels from the credible policy texts to generate policy rule vectors and obligation condition diagrams; S104, performing difference calculations between the current policy rule vector and historical policy rule vectors to obtain rule change factors; S105, based on customer objects, employee objects, contract objects, work order objects, knowledge base article objects, ... S106: Construct a reverse index for business objects based on salary configuration objects and historical processing record objects; S107: Generate a retrieval plan including exact key retrieval, range key retrieval, semantic key retrieval, and relational propagation retrieval based on the rule change factor, and retrieve the reverse index for business objects to obtain a set of candidate affected objects; S108: Perform structured matching, relational propagation, historical experience matching, knowledge base obsolescence calculation, and deadline urgency calculation on the set of candidate affected objects to obtain a set of affected objects and an impact score; S109: Generate tasks to be updated, explanations of reasons, recommended actions, responsible persons, deadlines, approval status, execution systems, and write-back addresses based on the impact scores; S100: Write back the task execution results to the audit records, and calibrate the rule confidence, differential threshold, retrieval scope, and impact score parameters based on the task execution results.

2. The method according to claim 1, characterized in that, The policy source text includes at least one of the following: government official website announcements, immigration agency notices, tax authority rules, social security agency notices, Payroll calendars, court or regulatory interpretations, legal service provider updates, summaries of international organization rules, and the company's internal compliance rule library; the policy version fingerprint includes at least the source address, issuing entity, publication time, capture time, content hash, attachment hash, language identifier, applicable region, source level, collection channel, parsing status, parser version, evidence page number, and manual confirmation status.

3. The method according to claim 1, characterized in that, Step S102 includes: extracting the main text from the webpage, PDF attachments, table attachments, and image attachments respectively; recording the paragraph number, page number, heading level, citation anchor point, and original text coordinates for the extraction results; when multiple sources have the same or similar policy content, deduplicating and merging them according to source level, publication time, content hash, and text similarity; when rule fields from multiple sources conflict, marking conflicting evidence fragments as pending review and reducing the confidence level of the corresponding policy rule vector.

4. The method according to claim 1, characterized in that, In step S103, the constrained large language model outputs structured parsing results according to preset field patterns. The field patterns include at least region, jurisdiction, applicable subject, employment status, visa or permit type, salary cycle, social security or tax items, obligatory actions, effective date, expiration date, penalty, exception conditions, evidence fragments, and confidence level. The rule validator performs mandatory field validation, date validity validation, numerical unit validation, enumeration value validation, evidence reference validation, and conflict validation on the structured parsing results. Parsing results that fail the validation are marked as awaiting manual review.

5. The method according to claim 1, characterized in that, The policy rule vector is represented as: v r = c o u n t r y j u r i s d i c t i o n s u b j e c t e m p l o y m e n t _ t y p e p e r m i t _ t y p e p a y _ c y c l e b e n e f i t _ i t e m o b l i g a t i o n _ a c t i o n e f f e c t i v e _ t i m e d u e _ t i m e p e n a l t y s o u r c e _ e v i d e n c e e x c e p t i o n _ c o n d i t i o n c o n f i d e n c e The source_evidence is associated with the evidence fragment identifier, page number, or paragraph number in the credible policy text, while confidence is calculated based on the source level, field validation results, conflict status, and manual confirmation status.

6. The method according to claim 1, characterized in that, The obligation condition graph includes obligation nodes, condition nodes, exception nodes, deadline nodes, responsible entity nodes, penalty nodes, evidence nodes, and business action nodes; the edges in the obligation condition graph include applicable edges, triggering edges, exclusion edges, deadline edges, responsibility edges, referencing edges, evidence edges, and action edges; the difference calculation includes text semantic difference, structured field difference, time constraint difference, condition graph difference, and source credibility difference, and is performed according to... Calculate the overall differential strength.

7. The method according to claim 1, characterized in that, The reverse index for the business object uses the rule element key as the index key and the business object identifier, object type, object attribute summary, update time, evidence field, source system, relationship edge, data sensitivity level, and index version number as the index value. The rule element key includes at least one of the following: region key, subject key, obligation key, time limit key, visa key, salary cycle key, salary threshold key, social security project key, contract clause key, work order tag key, knowledge base topic key, and historical processing action key.

8. The method according to claim 7, characterized in that, When constructing the inverted index of the business object, the customer contract service scope, employee work location, employee nationality, visa status, salary payment cycle, salary amount range, social security registration status, unfinished work order tags, work order processing actions, knowledge base article topics, salary calculation template fields, and customer risk level are mapped to the same rule element space. When a business object is added, deleted, has fields changed, or has relationship edges changed, an event-driven incremental index update mechanism is used to update the corresponding index key and index value.

9. The method according to claim 1, characterized in that, The search plan includes exact key search, range key search, semantic key search, and relation propagation search. Exact key search is used for matching by region, visa type, employment status, and social security program; range key search is used for matching by salary threshold, date range, and employee size; semantic key search is used for matching policy obligations with work order descriptions, contract terms, or knowledge base topics; and relation propagation search is used to expand the list of potentially affected entities based on the associations between customers, employees, contracts, work orders, salary templates, and knowledge base articles.

10. The method according to claim 1, characterized in that, The impact score Calculated based on the structured matching term M, relationship graph propagation term G, historical experience transfer term H, knowledge base obsolescence term K, deadline urgency term T, object exposure term E, source credibility term S, and uncertainty penalty term U, and satisfying the following conditions. Each weight is calibrated based on policy type, region, business line, historical manual review results, and task execution results.

11. The method according to claim 10, characterized in that, The historical experience transfer item H is determined based on the similarity of historical work order texts, consistency of processing actions, consistency of object types, and final processing results; the knowledge base obsolescence item K is determined based on the policy version cited in the knowledge base articles, article update time, access frequency, and records of complaints or corrections; the uncertainty penalty item U is determined based on at least one of the following: policy source conflict, missing business fields, low model parsing confidence, and semantic hits without structured field support.

12. The method according to claim 1, characterized in that, The explanations of causes include policy evidence explanations, business object hit explanations, relationship propagation path explanations, scoring factor explanations, and recommendation action explanations; among which, policy evidence explanations include evidence fragments, source levels, page numbers or paragraph numbers, business object hit explanations include the hit rule element keys and object fields, and relationship propagation path explanations include the relationship edges from directly hit objects to indirectly affected objects.

13. The method according to claim 1, characterized in that, The task to be updated includes at least the task number, object type, object identifier, policy change summary, reason for impact, evidence fragment, hit field, priority, recommended action, responsible person, deadline, approval status, execution system, execution result, and write-back status; the task to be updated is sent to at least one of the following systems: customer success system, human resources information system, contract management system, work order system, knowledge base management system, RPA execution platform, payroll calculation system, and message notification system.

14. The method according to claim 1, characterized in that, The task execution result includes at least one of the following: completed, no processing required, requires manual review, policy source conflict, missing object data, processing failure, customer confirmation in progress, and automatic execution success; the task execution result is used to update historical processing records, knowledge base version status, rule confidence, differential threshold, scoring model parameters, and the update time of the business object reverse index.

15. The method according to claim 1, characterized in that, It also includes access control, privacy protection, and audit control steps: recording the operator, operation time, change content, and source evidence for the policy rule base, business object reverse index, task execution record, and model parameter record; employing field anonymization, least privilege access, partitioned storage, and usage restrictions for data involving personal information; and displaying only the necessary fields and evidence anchors related to the policy impact assessment when outputting explanations of the reasons.

16. A method and apparatus for analyzing the impact of policy change perception on human resource compliance, characterized in that, It includes a policy collection module, a text preprocessing module, a structured parsing module, a rule differential module, a reverse indexing module, a candidate retrieval module, an impact scoring module, a task generation module, an audit write-back module, an interface linkage module, and a permission auditing module; wherein each module is configured to perform the method described in any one of claims 1 to 15.

17. The apparatus according to claim 16, characterized in that, The reverse indexing module includes a rule element standardization unit, an index key generation unit, an inverted item maintenance unit, a relation edge maintenance unit, and an incremental update unit; the influence scoring module includes a matching feature calculation unit, a propagation path calculation unit, a historical experience matching unit, a deadline urgency calculation unit, an uncertainty penalty unit, and a scoring parameter calibration unit.

18. An electronic device comprising at least one processor, at least one memory, a network interface, and a business system interface, wherein the memory stores computer programs, a policy rule base, a business object reverse index, historical processing records, and task audit records, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 15.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 15.

Images