Authority management system of interactive equipment

Abstract

The invention discloses an authority management system of interactive equipment, particularly relates to the field of computer authority management, is used for solving the problem that an interface state is disjointed from an authority decision, and is characterized in that a time mark acquisition module is used for acquiring a role context, a process state and an interface operable item on a unified timeline to generate a context snapshot and writing the context snapshot into a time anchor point; the contract construction module establishes interface contracts based on context snapshots to perform homologous binding to form a constraint set, and the mapping evidence solidification module generates permission mapping table expansion constraints in a rendering stage and writes behavior evidence chain solidification presentation basis. The judgment evaluation module calculates a judgment credibility coefficient according to a time anchor point alignment operation event and an approval record to execute local judgment or record through generating a judgment record; and the version revision module executes a minimum change revision mark change on an interface contract according to the judgment record and releases a new permission mapping table to recycle an old version to form a reviewable sequence.

Description

Technical Field

[0001] This invention relates to the field of computer access control, and more specifically, to an access control system for an interactive device. Background Technology

[0002] In the process of access control on interactive computers, existing technologies typically rely on backend logic to determine role assignments and process progression, only presenting the final results to the user interface. This approach is widely used in enterprise resource planning systems, collaborative office platforms, and access control software, where templates are reused by multiple roles to improve efficiency. For example, administrative staff use the same approval template to process purchase requests, while finance staff reuse it to approve expenditures.

[0003] However, this situation has significant drawbacks: the meaning of interface elements lacks accurate labeling as the context changes, resulting in entry points and buttons not converging according to differences in responsibilities; historical interface states are difficult to correlate one-to-one with process logs, leading to gaps between the presented content and actual authorization after long-term operation; operation paths and approval chains gradually deviate, making it impossible for the audit process to accurately reconstruct the true relationship between what was seen on the screen and the operable items at the time. These shortcomings stem from the separate design of existing technology, where backend decision-making is decoupled from frontend presentation, lacking a dynamic binding mechanism, thus affecting management consistency and compliance review.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide an access control system for interactive devices. A time-stamping acquisition module collects role context, process status, and operable interface items on a unified timeline, generating context snapshots and writing them to time anchors as a unified basis for constraint orchestration and traceability. A contract construction module establishes interface contracts based on the context snapshots, binding role semantics, process gating, and interface element permissions to form a searchable constraint set and recording versions and applicable scopes. A mapping and evidence consolidation module generates an access control mapping table based on the interface contracts during the rendering phase, expanding constraints on entry points, buttons, and jump paths, and writing them into a behavioral evidence chain to solidify the presentation basis. An adjudication and evaluation module aligns operation events and approval records according to time anchors, locates unauthorized entry points and semantic drift, calculates adjudication credibility coefficients, and executes on-site adjudication or records based on the hierarchical results, generating adjudication records. A version revision module performs minimal modifications to the interface contracts based on the adjudication records, annotates the reasons for changes and the scope of impact, publishes a new access control mapping table, and reclaims the previous version to form a verifiable version sequence, thereby solving the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: An access control system for an interactive device includes: Time stamp acquisition module: Collects role context, process status and operable items on a unified timeline, generates context snapshots and writes them to time anchors, serving as a unified basis for constraint orchestration and traceability; Contract building module: Based on context snapshots, it establishes interface contracts, binds role semantics, process gating and interface element permissions to the same source, forms a searchable set of constraints and records the version and scope of application; Mapping and Evidence Module: During the rendering phase, a permission mapping table is generated based on the interface contract. Constraints are expanded on the entry point, buttons, and jump paths. At the same time, the mapping results are written into the behavioral evidence chain to solidify the presentation basis. The adjudication evaluation module aligns operation events and approval records by time anchor points, locates unauthorized entry points and semantic drift, calculates the adjudication credibility coefficient, and executes on-site adjudication or records approval and generates adjudication records according to the hierarchical results. Version Revision Module: Based on the adjudication record, perform minimal revisions to the interface contract, indicate the reasons for the changes and the scope of impact, publish a new permission mapping table, and reclaim the previous version to form a verifiable version sequence and end the current round of processing.

[0007] Furthermore, the time stamp acquisition module establishes a unified timeline based on three sources: role context, process status, and operable items on the interface. First, it performs sequence correction and gap filling based on the source timestamps, and then completes three-way alignment based on role identifier, process node identifier, and element identifier, outputting a context snapshot and time anchor with source fingerprints.

[0008] Furthermore, the time-stamped acquisition module generates a context snapshot, which contains three sets of fields: role responsibilities, process node semantics, and element operable attributes, and records the acquisition moment with a time anchor.

[0009] Furthermore, the time-stamped acquisition module constructs a source mapping table to mark the traceable path from the data source to the context snapshot. When multiple entry points conflict at the same time, they are diluted and merged according to the serialization rules of process node priority and role responsibility priority to form a single usable snapshot. Finally, the snapshot index is used to connect the time anchor point and the source mapping table.

[0010] Furthermore, the contract construction module uses context snapshots as input to build interface contracts, introduces role semantic clauses, process gating clauses, and element permission clauses at the clause granularity, and uses element identifiers as the landing point to bind the three types of clauses to a constraint set.

[0011] Furthermore, the contract building module generates a clause landing index, binds each clause to a unique or restricted set of elements, and assigns a scope of application, inheritance relationship and mutual exclusion relationship to each binding. When clause overlap or inheritance chain conflict occurs, semantic re-entry is first eliminated through mutual exclusion pruning rules, and then the inheritance expander is used to expand the specific constraints.

[0012] Furthermore, the mapping and authentication module reads the interface contract during the rendering phase, generates a permission mapping table according to the clause landing point index, expands the entry point, button, and jump path into two categories: executable and non-executable, and writes the source clause and scope of application for each category.

[0013] Furthermore, the mapping and evidence-building module writes the behavioral evidence chain, which consists of three parts: the presentation evidence fingerprint, the source clause fingerprint, and the time anchor. The presentation evidence fingerprint consists of element identifier, interface hierarchy path, and interaction attributes. Then, a constraint conflict scan is performed. If the same element is found to fall into both executable and non-executable partitions, a round of pruning is performed in a fixed order of clause priority, node time sequence priority, and role responsibility priority, and the pruning record is attached to the evidence chain.

[0014] Furthermore, the adjudication evaluation module aligns the operation events with the approval records according to the time anchor point. After locating the overstepping entry point and semantic drift based on the evidence chain, it calculates two domain parameters: the consistency of the contract landing point and the strength of the approval time sequence offset. Then, the two parameters, along with the evidence chain fragments and the clause landing point index, are sent to the responsibility anchor point walking embedder. The walking is organized on the anchor point graph using three types of nodes: role responsibility anchor points, process node anchor points, and element landing point anchor points, and three types of edges: source edges, time sequence edges, and constraint edges. A low-dimensional representation is obtained and the adjudication credibility coefficient is output by a lightweight discriminator.

[0015] Furthermore, the version revision module reads the adjudication record, performs minimal revisions to the interface contract, first locates the affected clauses through the clause landing point index, then uses the mutual exclusion pruning record and inheritance expander to accurately determine the change unit, and generates a difference patch. The difference patch describes the three types of changes—addition, replacement, and removal—in a dual view at the clause level and the landing point level, generating an impact surface view, which is composed of a clause dependency graph and a landing point dependency graph, marking the roles, responsibilities, process nodes, and element sets affected by the changes, and formulating a phased release plan and recall strategy accordingly. During the release phase, the new version fingerprint and presentation basis index are written into the new mapping table, the previous version is marked as frozen and moved to the reproducible version sequence, and finally, a revision description is generated.

[0016] The technical effects and advantages of the permission management system for interactive devices of the present invention are as follows: This invention establishes a unified timeline and generates context snapshots through a time stamp acquisition module, providing a traceability basis for subsequent bindings. Combined with the homologous constraint set of the contract construction module, it achieves dynamic consistency in role semantics, process gating, and element permissions, ensuring that the interface presentation is free from semantic drift. The mapping and evidence consolidation module expands permissions and solidifies the behavioral evidence chain during the rendering phase, further linking with the adjudication and evaluation module's time-series alignment and credibility coefficient calculation to locate unauthorized actions in real time and trigger on-site intervention, preventing the accumulation of operational deviations. The version revision module performs minimal modifications based on the adjudication record and forms a verifiable sequence, closing the entire process. This eliminates the gap between traditional permission decisions and the interface, improves the overall transparency and compliance of the system, significantly reduces audit complexity in multi-role interaction scenarios, and supports efficient behavior verification and risk prevention. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of an interactive device permission management system according to the present invention. Detailed Implementation

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

[0019] Example 1: Figure 1 The present invention provides a permission management system for an interactive device, comprising: Time stamp acquisition module: Collects role context, process status and operable items on a unified timeline, generates context snapshots and writes them to time anchors, serving as a unified basis for constraint orchestration and traceability.

[0020] Contract building module: Based on context snapshots, it establishes interface contracts, binds role semantics, process gating and interface element permissions to the same source, forms a searchable set of constraints and records the version and scope of application.

[0021] Mapping and Evidence Module: During the rendering phase, a permission mapping table is generated based on the interface contract. Constraints are applied to entry points, buttons, and navigation paths. At the same time, the mapping results are written into the behavioral evidence chain to solidify the presentation basis.

[0022] The adjudication evaluation module aligns operation events and approval records by time anchor point, locates unauthorized entry points and semantic drift, calculates the adjudication credibility coefficient, and executes on-site adjudication or records approval and generates adjudication records according to the hierarchical results.

[0023] Version Revision Module: Based on the adjudication record, perform minimal revisions to the interface contract, indicate the reasons for the changes and the scope of impact, publish a new permission mapping table, and reclaim the previous version to form a verifiable version sequence and end the current round of processing.

[0024] In interactive computer access control systems, traditional methods often separate role division, process progression, and interface presentation, leading to a disconnect between interface status and actual permissions, resulting in compliance risks and auditing challenges. Specifically, when multiple roles reuse the same template, the meaning of interface elements becomes ambiguous due to contextual changes, historical states are difficult to correlate with logs, and over time, operational paths and approval chains deviate, compromising management consistency. To address this issue, this invention introduces a time-stamped data collection module as a foundational layer. This module captures dynamic data through a unified timeline, ensuring that subsequent modules can trace the true relationship between the interface and permissions, thereby improving system transparency and verifiability. The module focuses on real-time data collection and alignment, providing a reliable basis for constraint orchestration and preventing semantic drift and exposure of unauthorized access.

[0025] This invention addresses the core problem of the disconnect between interface state and permission decisions in interactive computer management scenarios, emphasizing the need to establish traceable contracts to bind role semantics, process gating, and changes in interface elements. However, before constructing such contracts, a unified timeline must first be established through a time-stamping module to collect data from three sources: role context, process state, and operable interface items. This ensures that context snapshots and time anchors are generated as a unified basis for subsequent constraint orchestration and traceability, thereby providing the entire system with foundational data for consistent binding.

[0026] The specific processing logic of the time stamp acquisition module: 1-1: Establish a unified timeline based on three sources: role context, process status, and interactive interface items.

[0027] Data is extracted from three sources: role context, including the current user's role identifier and responsibility description; process status, encompassing the current process node identifier and its semantic definition; and interface operable items, recording element identifiers and their interaction attributes. First, the timestamps from each source are corrected for order. All data items are sorted by comparing timestamp values. If any timestamps are missing, linear interpolation is used to fill the gaps, for example, by calculating based on the average difference between adjacent timestamps. Specifically, at the moment of data collection, the timestamp of each source is recorded, in Unix timestamp format. All source timestamps are then sorted in ascending order to form a preliminary time series. For the difference between any two adjacent source timestamps in the series, if the difference exceeds a preset threshold (e.g., determined by analyzing the average interval of historical data, such as calculating the arithmetic mean of timestamp differences over the past 24 hours as the threshold benchmark), a virtual timestamp is inserted in the middle. This virtual timestamp is equal to the sum of the previous source timestamp and the next source timestamp divided by two, ensuring the continuity of the sequence. Next, a three-way alignment is performed based on role identifier, process node identifier, and element identifier: The time series is traversed, and the data item associated with each timestamp is matched against the role identifier, process node identifier, and element identifier. If no complete match is found, the value is inherited from the corresponding identifier of the most recent timestamp. A context snapshot (preliminary version) with source fingerprints and time anchors are output. The source fingerprint is a hash concatenation of three types of sources: the role context, process state, and operable items on the interface are concatenated in sequence, and the hash value is calculated. The time anchor is a key-value pair between the current timestamp and the source fingerprint.

[0028] 1-2: Generate a context snapshot.

[0029] Based on the established unified timeline and aligned data, a context snapshot structure is constructed. This structure contains three sets of fields: role responsibility field (describing the semantics of tasks that the current role can perform), process node semantic field (defining the preconditions and expected outputs of the current node), and element operable attribute field (listing the visibility and interaction permissions of interface elements). A time anchor is used to record the moment of collection, ensuring that the snapshot captures the instantaneous state. Specifically, aligned data is populated into the structure to form a context snapshot. This context snapshot is a collection, including role responsibility as a list containing multiple responsibility items, process node semantic as a list containing multiple semantic items, and element operable attributes as a list containing multiple attribute items, where each field is a list to accommodate multiple values. Simultaneously, a time anchor is attached to the context snapshot's metadata as a timestamp for the context snapshot. This generation ensures that subsequent traceability can directly locate the precise state at the moment of collection, rather than relying on scattered sources.

[0030] 1-3: Construct the source mapping table.

[0031] Using the generated context snapshot, a traceable path from the data source to the context snapshot is marked. The source mapping table is a key-value mapping structure, where the key is the source type (role context, process status, interface operable items), and the value is the path description, including the data source identifier and transformation steps. When multiple entry conflicts occur at the same time (i.e., multiple sources provide overlapping data at the same time anchor point), dilution and merging are performed according to the serialization rules of process node priority and role responsibility priority: first, the priority of the semantic field of the process node is checked (defined as node depth, the larger the depth value, the higher the priority); if they are the same, the priority of the role responsibility field is compared (defined as responsibility breadth, the more tasks covered by the breadth value, the higher the priority). Specific implementation: For conflicting items, a priority score is calculated, which is equal to the node depth plus an adjustment factor multiplied by the responsibility breadth. The adjustment factor is determined by simulating historical conflict scenarios, for example, by using the gradient descent method to minimize the merging error rate to obtain the adjustment factor value; the item with the highest priority score is selected and retained, and the others are diluted into a single usable snapshot. This single usable snapshot is formed by merging the selected item and the low-priority conflicting item. The merging adopts field-level coverage, that is, priority is given to covering non-empty fields. The final source mapping table records all paths and merge records, ensuring that the conflict resolution process can be reproduced during tracing.

[0032] 1-4: Use snapshot indexes to connect time anchors with source mapping tables.

[0033] Based on the source map table and context snapshots, a snapshot index is created as a concatenated structure. This index is an ordered list, with each element being a triplet, including a time anchor, a context snapshot hash value, and a source map table reference pointer. The context snapshot hash value is the hash calculation result of the context snapshot, and the source map table reference pointer is the reference address of the source map table. Specifically, all time anchors are traversed, and the snapshot index is built in ascending order of time anchors. To ensure integrity, the hash consistency of each triple is verified; if inconsistent, steps 1-3 are re-merged. Through this concatenation, any subsequent rulings or replays can directly locate the actionable items and their responsibilities at that time through the snapshot index; for example, a query for a time anchor point returns the corresponding context snapshot and source map table.

[0034] The time stamp acquisition module collects three types of sources on a unified timeline: role context, process status, and operable items on the interface. First, it performs sequence correction and gap filling based on the source timestamp. Then, it completes three-way alignment based on role identifier, process node identifier, and element identifier, and outputs a context snapshot with source fingerprint and time anchor. Subsequently, it constructs a source mapping table to mark the traceable path from the data source to the context snapshot. When multiple entry conflicts occur at the same time, they are diluted and merged according to the serialization rules of process node priority and role responsibility priority to form a single usable snapshot. Finally, the snapshot index is used to connect the time anchor and the source mapping table.

[0035] In interactive management, traceable contracts are established to bind multi-source data. However, after the time-stamped acquisition module outputs a context snapshot, it must be transformed into an interface contract through the contract building module to achieve the same-source binding of role semantics, process gating and element permissions, forming a constraint set as the retrieval basis for subsequent mapping and evaluation, thereby eliminating permission gaps and supporting version traceability.

[0036] The specific processing logic of the contract construction module: 2-1: Build the UI contract using a context snapshot as input.

[0037] A context snapshot is obtained from the time-stamped acquisition module. This snapshot contains three sets of fields: role responsibilities, process node semantics, and element operability attributes. Three types of constraints are introduced at the clause granularity: role semantic clauses (extracted from the role responsibility field, defining the semantic rules of the role in the current context), process gating clauses (extracted from the process node semantic field, specifying the gating conditions for process advancement), and element permission clauses (extracted from the element operability attribute field, specifying the access permissions of the element). Using the element identifier as the endpoint, the three types of clauses are bound together into a constraint set. The fields in the context snapshot are parsed to generate a list of role semantic clauses (clause 1, which includes responsibility semantic binding), a list of process gating clauses (clause 1, which includes node gating conditions), and a list of element permission clauses (clause 1, which includes permission rules). Then, these lists are aggregated by element identifier to form a constraint set, namely, the role semantic sub-clause, process gating sub-clause, and element permission sub-clause corresponding to element identifier 1, ensuring that each set of clauses shares the same source fingerprint to maintain homogeneity. This binding process lays the foundation for subsequent indexing and avoids semantic silos.

[0038] 2-2: Generate the clause landing point index.

[0039] Based on the constraint set formed above, each clause is bound to a unique or restricted set of elements, and each binding is assigned a scope of application (defined as the effective context boundary of role-process-element), inheritance relationship (describing the rule chain inherited by the clause from the parent element or node), and mutual exclusion relationship (identifying conflicting pairs that cannot coexist between clauses). The clause landing point index is a multi-level mapping structure, with the clause identifier as the key and the landing point element group and its attributes as the value. Each element identifier in the constraint set is traversed, and attributes are assigned to the associated clauses: the scope of application is determined by scanning the time anchor point of the context snapshot; the inheritance relationship is constructed as a directed graph, with nodes representing clauses and edges representing inheritance dependencies; the mutual exclusion relationship is a list of pairs, such as the conflict reasons corresponding to clause A and clause B. If the binding involves multiple elements, the group size is limited to a preset threshold (for example, the threshold is determined by statistically analyzing the historical constraint density, such as calculating the average number of landing points in the past constraint set as the upper limit of the threshold to prevent index bloat). This index ensures that the bindings are searchable and supports conflict detection.

[0040] 2-3: Handling situations where there are overlapping clauses or conflicting inheritance chains.

[0041] The generated clause landing index is used to detect overlaps (multiple clauses under the same element identifier covering the same semantics) or inheritance chain conflicts (cycles or contradictions in the inheritance relationship). Semantic re-entry is first eliminated using a mutual exclusion pruning rule, i.e., clauses with duplicate semantics are removed. Then, an inheritance expander is used to expand the specific constraints without changing the original semantics, converting abstract inheritance into concrete clauses. Specific implementation: The clause landing index is scanned. If overlap is found, a mutual exclusion pruning rule is applied: the semantic similarity of the clauses is compared, which is equal to the number of common lexical units divided by the total number of lexical units, where the number of common lexical units is the size of the intersection of the clause texts, and the total number of lexical units is the size of the union. If the similarity is greater than a threshold (e.g., determined by testing on sample constraints using a trained semantic model, such as using cross-validation to minimize the false positive rate), low-priority clauses are eliminated (priority is based on the depth of the process node). For inheritance chain conflicts, the inheritance expander recursively expands the inheritance relationship: starting from the leaf node, the parent clause attributes are copied to the child clauses, forming the expanded constraint, i.e., the union of the child clauses and the parent clause minus the re-entry portion. This process resolves conflicts and ensures the purity of the constraint set.

[0042] In this invention, the inheritance expander is designed as an algorithmic module to process abstract clauses in constraint inheritance chains, ensuring that inheritance relationships are transformed into concrete constraints without altering the original semantics. The core function of this module is to recursively traverse the inheritance chain, copying attributes from parent clauses to child clauses while avoiding semantic reentrancy, thereby generating a set of expanded concrete clauses. This design is suitable for contract construction and version revision processes in interactive computer permission management systems, particularly in handling overlapping or conflicting clauses, ensuring the purity and consistency of the constraint set.

[0043] Construction Process: The inheritance expander is constructed using a modular structure. First, an input interface is defined, which receives the inheritance relationship (a chain of rules describing which clauses inherit from parent elements or nodes) and the original set of clauses. The internal implementation includes a recursive function stack to handle nested inheritance levels and a semantic checker to verify semantic consistency before and after expansion. Specifically, during function stack initialization, a directed graph representation of the inheritance relationship is loaded, where nodes are clause identifiers and edges represent inheritance dependencies. The semantic checker ensures that copying attributes does not introduce new semantics by comparing the hash values ​​or keyword sets of the clause text. The entire module is implemented using a programming language such as Python, relying on basic data structures such as dictionaries and lists to store clause attributes (including role semantics, process gating, and element permissions). During construction, the module is ensured to be stateless for easy reuse in multi-threaded environments, and the upper limit of inheritance depth is parameterized to prevent infinite loops.

[0044] How it works: The inheritance expander operates based on a depth-first search algorithm, expanding the inheritance chain layer by layer. Specifically, it starts from a leaf node (a clause without children), backtracks to the root node, copies parent attributes to children, and removes duplicates. Reentrancy detection is achieved by comparing the intersection of attribute sets; if duplicates are found, they are retained only once. This principle ensures that the original semantics remain unchanged. For example, if a parent clause defines a general permission rule, the expanded child clause inherits this rule and concretizes it based on its own context, without modifying the parent definition. This mechanism resolves inheritance chain conflicts during contract construction, precisely locates change units during version revisions, and supports the principle of minimal modification.

[0045] Processing Steps: The inheritance expander's processing steps are divided into initialization, recursive expansion, and output verification. First, the initialization phase loads the inheritance relationship and original clauses, identifying the starting leaf node. Second, the recursive expansion phase starts from the leaf node, copying the parent clause attributes to the current clause to form temporary expansion constraints. Duplicate parts (such as repeated permission attributes) are removed using set difference operations, and the semantic fields of the child clauses are updated. Iteration continues to the root node, generating the complete set of expansion constraints. Finally, the output verification phase compares the semantic fingerprints (text hashes) of the clauses before and after expansion. If they are inconsistent, a rollback is performed to ensure the output conforms to the original semantics. This sequence of steps guarantees the reversibility of the expansion process and supports audit traceability.

[0046] Parameter settings and optimization: Parameter settings include inheritance depth threshold (default 5 layers, optimized through historical data simulation) and reentry threshold (semantic similarity 0.8, determined through sample testing). Optimization employs an iterative testing method, evaluating unrolling efficiency and accuracy on a simulated constraint set, and adjusting the recursion stack size to minimize memory usage. This module's implementation ensures real-time response during system operation, making it suitable for high-concurrency scenarios.

[0047] 2-4: Calculate the contract version fingerprint.

[0048] Based on the processed constraint set and clause landing point index, a contract version fingerprint is generated for version tracking and difference location. The fingerprint consists of three concatenated parts: a text hash of the clause set (hash after sorting all clause texts), an ordered traversal hash of the landing point set (hash of the landing point group by element identifier traversing the clause landing point index), and a scope hash (hash after serializing all scopes). Specifically, the clause text hash is calculated first, i.e., the hash value after sorting all clause texts; then the landing point hash is the hash value of the element identifier and landing point of the ordered traversal of the clause landing point index; the scope hash is the hash value of serialized all scopes; finally, the contract version fingerprint equals the clause text hash concatenated with the landing point hash concatenated with the scope hash, where concatenation represents string concatenation. This fingerprint calculation guarantees version uniqueness and supports fast comparison.

[0049] 2-5: The final output is an interface contract with version fingerprint, clause landing point index, and mutual exclusion pruning record.

[0050] The interface contract integrates the contract version fingerprint, clause placement index, and mutual exclusion pruning records from steps 2-3 (a log list recording the removed clauses and their reasons). The interface contract is a composite structure containing these components, ensuring that role semantics, process gating, and element permissions maintain semantic and data-level consistency. Specific implementation: Assembling the interface contract includes the contract version fingerprint, clause placement index, mutual exclusion pruning records, and constraint sets. Consistency verification includes checking whether the clause placement index covers all constraint sets. The output is used to map the input to the validation module. This output solidifies the binding results for easy subsequent traceability.

[0051] The contract construction module establishes interface contracts based on context snapshots. At the clause granularity, it introduces role semantic clauses, process gating clauses, and element permission clauses, and uses element identifiers as the landing point same-origin binding as the constraint set. It generates clause landing point indexes to assign applicable scope, inheritance relationship, and mutual exclusion relationship. When clauses overlap or inheritance chain conflicts, it removes semantic re-entry through mutual exclusion pruning rules and uses the inheritance expander to expand the specific constraints. Then, it calculates the contract version fingerprint by concatenating the clause set text hash, the landing point set ordered traversal hash, and the applicable scope hash. Finally, it outputs an interface contract with version fingerprint, clause landing point index, and mutual exclusion pruning record.

[0052] The front-end module collects and constructs traceable contracts to bind multi-source semantics. However, after the interface contract is output, the mapping and evidence consolidation module must be used to expand the constraints to generate a permission table during the rendering stage and solidify behavioral evidence, thereby providing a fixed query basis for subsequent adjudication and evaluation and eliminating the deviation between presentation and authorization.

[0053] The specific processing logic of the mapping and proof module: 3-1: During the rendering phase, read the interface contract and generate a permission mapping table according to the index of the clauses.

[0054] The interface contract is obtained from the contract construction module. This contract contains a set of constraints and clause landing point indices. Element identifiers are traversed according to the clause landing point indices to generate a permission mapping table. This table has a partitioned structure, categorizing interface elements. Specific implementation: The interface contract is loaded, and the landing points in the clause landing point indices are extracted and bound to the clauses. For each element identifier, the permission status is evaluated based on the associated role semantic clauses, process gating clauses, and element permission clauses, forming a permission mapping table. That is, each element identifier corresponds to an executable partition (including entry points, buttons, etc.), and a non-executable partition (including jump paths, etc.). The partitions are divided according to the permission rules of the clauses, ensuring that the mapping directly originates from the clause landing point indices to maintain consistency. This generation process provides a structured foundation for subsequent development.

[0055] 3-2: Expand the entry point, buttons, and jump paths into two categories: executable and non-executable, and write the source terms and scope of application for each category.

[0056] Based on the permission mapping table, constraints are applied to each entry point (interface access point), button (interactive control), and navigation path (navigation link). These elements are assigned to executable partitions (allowed operations) or non-executable partitions (prohibited operations), and the source clauses (clause identifier and type) and scope of application are written. Specific implementation: Iterate through each element identifier in the permission mapping table, checking associated clauses: if the process gating clause meets the gating conditions and the element permission clause allows it, place it in the executable partition; otherwise, place it in the non-executable partition; append a list of source clauses to each partition item, namely, the role semantic clause identifier, the process gating clause identifier, the element permission clause identifier, and the scope of application value. This expansion ensures accurate partitioning and prepares traceable data for the evidence chain, avoiding permission ambiguity.

[0057] 3-3: Write the behavioral evidence chain.

[0058] Using the updated permission mapping table, a behavioral evidence chain is generated as the sequence structure for solidifying the presentation. The evidence chain consists of three parts: presentation evidence fingerprint (capturing the current presentation state), source clause fingerprint (clause hash), and time anchors. The presentation evidence fingerprint comprises element identifier, interface hierarchy path (the element's position sequence in the interface tree), and interaction attributes (visible, clickable, etc.). For each partition item in the permission mapping table, a presentation evidence fingerprint is calculated—the hash value of the element identifier concatenated with the interface hierarchy path and the interaction attributes. The source clause fingerprint is the hash value of the source clause list. Then, the behavioral evidence chain is assembled: presentation evidence fingerprint one corresponds to source clause fingerprint one, which corresponds to time anchor one; presentation evidence fingerprint two corresponds to source clause fingerprint two, which corresponds to time anchor two, and so on. The time anchors are derived from the context snapshot. This is written to the solidified rendering state, supporting audit and recovery.

[0059] 3-4: Perform constraint conflict scan.

[0060] Based on the behavioral evidence chain and permission mapping table, the system scans for cases where the same element falls into both executable and non-executable partitions. If a conflict is found, a round of trimming is performed in a fixed order: clause priority (based on the semantic depth of role semantic clauses, process gating clauses, and element permission clauses), node sequence priority (process node sequence order), and role responsibility priority (responsibility breadth). The trimming record is then attached to the behavioral evidence chain. The permission mapping table is traversed. If an element identifier appears in both partitions, the priority is sorted as follows: first, clause priority (semantic depth equal to the number of clause nesting levels); second, node sequence priority (process node sequence value); and finally, role responsibility priority (number of responsibility coverage items). A comprehensive priority is calculated as semantic depth × (node ​​sequence priority + role responsibility priority). The partition with the highest comprehensive priority is retained, and others are removed. A trimming record is generated, containing the conflicting element identifier, the removed partition, and the priority basis, and is attached to the behavioral evidence chain. This scan resolves conflicts and ensures the mapping table is consistent.

[0061] 3-5: After rendering, output the presentation basis index with the mapping table hash and evidence chain sequence number.

[0062] The integrated permission mapping table and behavioral evidence chain are used to generate a presentation basis index, which serves as the output structure. The mapping table hash (i.e., the hash value of the permission mapping table) is calculated, and the evidence chain sequence number is the incrementing counter value (based on historical rendering counts). Specific implementation: Verify that the behavioral evidence chain covers all permission mapping table entries; assemble the presentation basis index, which includes the mapping table hash, evidence chain sequence number, behavioral evidence chain reference pointer, and permission mapping table reference pointer, where the reference pointer is a reference address; output the presentation basis index, ensuring that what is seen (presentation status), what can be done (permission partition), and why it can be done (source clause) are fixed and queried within the same index, used as input for the adjudication and evaluation module. This output completes the rendering evidence consolidation.

[0063] During the rendering phase, the mapping and evidence module reads the interface contract, generates a permission mapping table according to the clause landing point index, expands the entry point, button, and jump path into two categories: executable and non-executable, and writes the source clause and scope of application. The behavioral evidence chain consists of the presentation evidence fingerprint, the source clause fingerprint, and the time anchor. Then, a constraint conflict scan is performed. If the same element is found to be conflicting, it is trimmed in the order of clause priority, node time sequence priority, and role responsibility priority, and the trimming record is attached. After the rendering is completed, the presentation basis index with the mapping table hash and the evidence chain sequence number is output.

[0064] The basis for querying has been solidified in the previous module. However, after the permission mapping output, the operation and approval must be aligned and evaluated by the adjudication evaluation module to locate the deviation and calculate the credibility coefficient, thereby triggering the action or archiving, and realizing transparent intervention in the whole chain.

[0065] The specific processing logic of the adjudication assessment module: 4-1: Align operation events with approval records by time anchor point.

[0066] The behavioral evidence chain and presentation basis index are obtained from the mapping and evidence consolidation module, and operation events (user interaction logs) and approval records (backend decision logs) are read. These records are sorted and aligned by time anchors, and the unauthorized entry points (unauthorized operation items) and semantic drift (discrepancies between clause semantics and actual presentation) are located based on the behavioral evidence chain. Specifically: timestamps in operation events are extracted and matched with time anchors. If the offset exceeds a threshold (e.g., the threshold is determined by analyzing the average alignment error of historical logs, such as calculating the confidence interval of alignment success rate on sample data to set the threshold limit), an intermediate anchor is inserted to adjust the sequence; subsequently, the presentation evidence fingerprints in the behavioral evidence chain are scanned, and operation events are compared with approval records. Unauthorized entry points are identified as items in non-executable partitions of the permission mapping table that are operated on, and semantic drift is the deviation between the binding relationship in the clause landing point index and the actual landing point. This alignment process establishes the basis for subsequent calculations, ensuring the integrity of the event sequence.

[0067] 4-2: Based on the evidence chain to locate the entry point of unauthorized access and semantic drift, calculate the consistency of contract landing point and the strength of approval time sequence offset.

[0068] Using the aligned records and positioning results, two domain parameters are calculated. Contract placement consistency is derived from the binding and coverage relationship between clause placements and actual presentation placements; approval timeline offset strength is derived from the degree of offset between operation events and approval events within the workflow activity window. Specific implementation: For contract placement consistency, it is defined as the matching ratio between the set of clause placements in the clause placement index and the set of actual presentation placements in the behavioral evidence chain. The calculation method is the number of common placements divided by the total number of unique placements, ensuring the result is a dimensionless ratio. For approval timeline offset strength, it is defined as the relative deviation between the operation event timestamp and the corresponding approval event timestamp. The calculation method is a negative time difference minus a natural exponent divided by the duration of the workflow activity window, where the time difference is an absolute value, and the exponential form ensures the offset strength gradually increases from zero to a certain range. This calculation quantifies the deviation, preparing numerical indicators for the embedder input.

[0069] 4-3: Send the two parameters, along with the evidence chain fragment and the clause landing index, into the liability anchor wandering embedder.

[0070] Based on the consistency of contract placement and the strength of approval timeline offset, relevant fragments (conflict-related parts) of the behavioral evidence chain and clause placement indices are selected. These are then fed into a responsibility anchor point walking embedder, which organizes the walking on the anchor point graph: the graph consists of three types of nodes: role responsibility anchor points (responsibility nodes), process node anchor points (node ​​sequences), and element placement anchor points (element bindings), and three types of edges: source edges (data source links), time sequence edges (time order links), and constraint edges (authority constraint links). Detailed Implementation: An anchor graph is constructed, consisting of a node set including role / responsibility anchors, process node anchors, and element landing point anchors; an edge set includes source edges, temporal edges, and constraint edges. Contract landing point consistency, approval temporal offset strength, behavioral evidence chain fragments, and clause landing point indexes are injected into the nodes as starting features. A random walk is performed, starting from the role / responsibility anchor, traversing along the edges to generate a path sequence. The path length does not exceed a threshold (e.g., the threshold is determined through connectivity testing at the scale of a simulated graph, such as optimizing the walk depth on the training graph to maximize embedding discriminability). A low-dimensional representation vector is obtained. By aggregating path features, a lightweight discriminator (simple multilayer perceptron) outputs a decision confidence coefficient, which is the result of applying the sigmoid function to the linearly transformed low-dimensional representation vector. The sigmoid function ensures the output is within a range of zero. This embedding process integrates parameters to achieve coefficient quantization.

[0071] The following is a detailed explanation of the construction, optimization, and parameter settings of the lightweight discriminator: In this invention, the lightweight discriminator is designed as a simple multilayer perceptron (MLP). Its core function is to convert the low-dimensional representation vector generated by the responsibility anchor walking embedder into a decision confidence coefficient. The discriminator processes the input vector through linear transformation and nonlinear activation, and finally applies a sigmoid activation function to output a probability value between zero and one, used to quantify the confidence level of the decision. This design emphasizes lightweightness to ensure efficient real-time computation in interactive computer access control systems without introducing excessive computational overhead.

[0072] Construction Process: The lightweight discriminator is built using a modular approach. First, an input layer is defined, which receives a low-dimensional representation vector (the dimension is typically the output size of the embedder, e.g., 128 dimensions, to match the feature dimension after walkthrough aggregation). Then, one or two hidden layers are added, each including a fully connected linear transformation and a ReLU activation function to introduce non-linearity and capture complex patterns. Specifically, the first hidden layer maps the input vector to an intermediate dimension (e.g., 64 dimensions), achieving dimensionality reduction and feature extraction through matrix multiplication; the second hidden layer further compresses to an even lower dimension (e.g., 32 dimensions), enhancing the discriminator's generalization ability. Finally, the output layer is a single-neuron fully connected layer that applies a sigmoid function after a linear transformation of the previous layer's output to generate a decision confidence coefficient. This sigmoid function ensures that the output value is between zero and one, with zero representing low confidence and one representing high confidence, facilitating subsequent interval grading. The entire structure avoids complex components such as convolutions or attention mechanisms to maintain lightweight characteristics, keeping the total number of parameters below a few thousand, making it easy to deploy in resource-constrained environments.

[0073] Optimization Method: The optimization process uses gradient descent to adjust the discriminator's weights and biases by minimizing the loss function. A binary cross-entropy loss function is used to match the probabilistic characteristics of the sigmoid output, ensuring the model focuses on correctly distinguishing between high-confidence and low-confidence samples during training. Training data is derived from historical adjudication records, including a set of embedded vector samples labeled as safe or alert. An Adam variant optimizer is chosen, which combines momentum and adaptive learning rate to quickly converge to local optima. Specific optimization steps include forward propagation to calculate prediction coefficients, backpropagation to calculate gradients, updating parameters, and evaluating validation set accuracy after each epoch. An early stopping mechanism is introduced, stopping training when the validation loss shows no improvement for three consecutive epochs to prevent overfitting. The batch size is set to 32 to balance memory usage and gradient stability, and the entire optimization is completed within a small number of iterations (e.g., 50-100 epochs) to ensure the model efficiently adapts to system dynamics.

[0074] Parameter Settings: Parameter settings are based on empirical tuning and cross-validation to ensure the discriminator's robustness in real-world scenarios. The input dimension is fixed to the embedder output size (default 128); the hidden layer dimension is set to half and a quarter of the input dimension (e.g., 64 and 32) to progressively compress features; the activation function is uniformly set to ReLU to introduce non-linearity and avoid gradient vanishing. The learning rate is initially set to 0.001 and gradually reduced to 0.0001 during training using cosine annealing to ensure stable convergence. Weights are initialized using a uniform Xavier distribution to ensure balanced initial gradients. The L2 regularization coefficient is set to 0.0001 to slightly penalize complex weights and prevent overfitting. The dropout rate can be optionally set to 0.1 and applied only to hidden layers to randomly drop neurons and improve generalization. In parameter tuning, a grid search is used to cross-validate historical datasets, and evaluation metrics include accuracy and F1 score to ensure consistent performance across different workflow contexts. These settings can be fine-tuned based on specific deployment environments, such as further reducing hidden layers to reduce latency in high-load scenarios.

[0075] 4-4: Calculate the credibility coefficient of the ruling and execute the on-site ruling or record the passage according to the classification results.

[0076] Based on the decision credibility coefficient output from the previous step, the system is categorized into preset intervals: Alarm Interval (determined by backtesting historical decision accuracy, such as using receiver operation characteristic curves to balance false positives and false negatives); Safe Interval (determined by decision credibility coefficient greater than or equal to the threshold). When entering the Alarm Interval, an on-site decision is executed, applying actions to the permission mapping table such as entry downgrading (lowering priority), button disabling (removing interaction), and redirection blocking (interrupting the path). Specifically, if the decision credibility coefficient is in the Alarm Interval, conflicting items in the permission mapping table are scanned, and action instructions are generated based on the conflict list (a deviation list extracted from the clause endpoint index), such as disabling a specific button; otherwise, in the Safe Interval, only approval is recorded, and the approval record is merged with the index into an archive file. This categorization ensures timely response.

[0077] 4-5: Generate the ruling record.

[0078] Integrating the above-mentioned actions or records, an adjudication record is generated, containing fragments of the behavioral evidence chain, a list of conflict points (details of unauthorized actions and drift), and action instructions (if applicable). When adjudicating on-site, the record includes action details; otherwise, only the context is archived. Specific implementation: Assembling the adjudication record includes fragments of the behavioral evidence chain, a list of conflict points (element identifiers corresponding to conflict descriptions), and action instructions (instructions corresponding to entry point downgrades); the output adjudication record is used as input for the version revision module. This generation completes the evaluation cycle, providing a reliable basis for revision.

[0079] The adjudication evaluation module aligns operation events with approval records based on time anchors. After locating the unauthorized entry point and semantic drift based on the evidence chain, it calculates the consistency of contract landing point and the strength of approval time sequence offset. These two parameters, along with evidence chain fragments and clause landing point indexes, are fed into the responsibility anchor point walking embedder to organize a walk on the anchor point graph to obtain a low-dimensional representation. The lightweight discriminator then outputs the adjudication credibility coefficient. When the adjudication credibility coefficient enters the alarm range, it performs actions such as entry point downgrading, button disabling, and jump blocking on the permission mapping table and generates an adjudication record containing evidence chain fragments, a landing point conflict list, and handling instructions. When the adjudication credibility coefficient is within the safe range, the record is approved, and the presentation basis index and approval record are merged and archived.

[0080] After the assessment is completed, these records must be applied using the version revision module to make minimal changes, thereby marking the impact and releasing an update to complete the closed-loop error correction process.

[0081] The specific processing logic of the version revision module: 5-1 Read the ruling record and perform minimal revisions to the interface contract.

[0082] The adjudication record is retrieved from the adjudication evaluation module. This record contains fragments of the behavioral evidence chain, a list of conflict points, and disposition instructions. Affected clauses are located using the clause conflict point index, i.e., the clause identifiers mentioned in the conflict list. Mutual exclusion pruning records (removal logs extracted from the interface contract) and an inheritance expander (a tool for expanding inheritance relationships) are used to precisely identify the change units, which are the smallest sets of changes, such as individual clauses or conflict points. The conflict point list in the adjudication record is parsed to match the corresponding clauses in the clause conflict point index; the inheritance expander is applied recursively to expand the affected inheritance relationships, forming expansion constraints; and re-entry is filtered using the mutual exclusion pruning records, outputting a list of change units, i.e., clause identifiers and corresponding change types. This location ensures targeted revisions and avoids global refactoring.

[0083] 5-2: Generate the difference patch.

[0084] Based on the previous modification units, a difference patch is generated. This patch describes three types of changes—addition, replacement, and removal—using a dual view: clause-level (semantic rule changes) and endpoint-level (element binding adjustments). Specifically, the modification units are traversed, and for each unit, the original interface contract is compared with the changed state: addition introduces new clauses, replacement updates semantics, and removal deletes conflicting items. This is structured as a difference patch, where the clause view includes newly added clauses, replaced clauses, and removed clauses, and the endpoint view includes newly added endpoints, replaced endpoints, and removed endpoints. This generation provides a precise description of the changes, supporting subsequent view construction.

[0085] 5-3: Generate the influence surface view.

[0086] Using the difference patch from the previous step, an impact surface view is generated. This view is constructed by merging a clause dependency graph (a graph showing dependencies between clauses) and a landing point dependency graph (a graph showing relationships between landing points), marking the roles, responsibilities, process nodes, and element sets affected by the changes. Specific implementation: Change items are extracted from the difference patch, and a clause dependency graph (i.e., the dependency edges corresponding to clause nodes) and a landing point dependency graph (i.e., the relationships between landing point nodes) are constructed. These are then merged into an impact surface view, which is the union of the clause dependency graph and the landing point dependency graph. A breadth-first search is performed starting from the change node, calculating the reach set (role responsibilities corresponding to responsibilities of the first rank), the process node corresponding to the first rank, and the element set corresponding to the first rank element identifier, with the search depth not exceeding a threshold (e.g., the threshold is determined by simulating the dependency chain length statistics of historical revision data, such as calculating the average chain length plus one as the upper limit to cover typical impacts). This view quantifies the propagation scope, facilitating planning.

[0087] 5-4: Based on this, formulate a phased release plan and recall strategy.

[0088] Based on the impact profile view from the previous step, a phased release plan (progressive update sequence) and a retrieval strategy (rules for handling old versions) are formulated. Specific implementation: The reach set in the impact profile is analyzed, and phases are prioritized according to role responsibilities: Phase 1 updates the core element set, Phase 2 handles process nodes, etc.; the release plan includes the update item list for Phase 1, Phase 2, etc.; the retrieval strategy involves marking the previous version as frozen and moving it to the sequence, determining the retrieval threshold based on the size of the reach set. If the reach set exceeds the threshold (e.g., by assessing the impact scale of past revisions, such as using the median impact as a boundary using percentile methods), retrieval is performed immediately; otherwise, it is delayed. This approach ensures smooth updates and reduces interruptions.

[0089] 5-5: During the release phase, the new version fingerprint and presentation basis index are written to the new mapping table.

[0090] Integrating the previous release plan, the new permission mapping table (generated based on the revised interface contract) is written with a new version fingerprint (similar to the calculation of contract version fingerprints) and a presentation basis index; the previous version is marked as frozen and moved to the verifiable version sequence, which retains the complete index of each version. Specific implementation: Calculate the hash value of the new version fingerprint, i.e., the revised interface contract; update the new permission mapping table to include the presentation basis index; execute the phased writing of the release plan; mark the old permission mapping table as frozen and append it to the verifiable version sequence, i.e., the index and evidence chain corresponding to version one, version two, etc., and the frozen version. This release is a fixed update and supports retrospection.

[0091] 5-6: Generate revision notes.

[0092] Based on the version sequence and impact surface view published in the previous step, a revision description is generated. This description includes the reason for the change (extracted from the adjudication record), the impact surface (a summary of the impact surface view), the action result (update details), and a replay entry (version query link). Specifically: the action instructions from the adjudication record are summarized as the reason for the change; the reach set is extracted from the impact surface view as the impact surface; the action result is a summary of the difference patch; the replay entry is the access pointer to the version sequence; and the revision description is output as an audit document. This generation completes the revision and provides full-chain evidence.

[0093] The version revision module performs minimal changes to the interface contract based on the adjudication record. First, it locates the affected clauses through the clause landing point index, and then uses the mutual exclusion pruning record and inheritance expander to determine the change unit and generate difference patches. It generates an impact surface view and combines the clause dependency graph and the landing point dependency graph to mark the roles, responsibilities, process nodes, and element sets affected by the changes. Based on this, it formulates a phased release plan and recall strategy. In the release phase, it writes the new version fingerprint and presentation basis index into the new mapping table, and then marks the previous version as frozen and moves it to the retrievable version sequence. Finally, it generates a revision description that includes the reason for the change, the impact surface, the handling results, and the replay entry.

[0094] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

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

[0096] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0097] It should be noted that, in this document, the use of relational terms such as "first" and "second" is merely to distinguish one entity or operation from another, and does not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

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

Claims

1. A permission management system of an interactive device, characterized by, Comprise: Time scale acquisition module: collect role context, process state and interface operable item on unified timeline, generate context snapshot and write into time anchor point, as the unified basis for constraint arrangement and traceability; Contract construction module: establish interface contract based on context snapshot, homologous binding of role semantics, process gate and interface element permission, form a searchable constraint set and record version and scope of application; Mapping and solidification module: generate permission mapping table according to interface contract in rendering stage, execute constraint expansion on entry, button and jump path, and write mapping results into behavior evidence chain to solidify presentation basis; Judgment evaluation module: align operation events and approval records according to time anchor point, locate unauthorized entry and semantic drift, calculate judgment confidence coefficient, and execute on-site judgment or record pass according to hierarchical results and generate judgment record; Version revision module: perform minimum change revision on interface contract according to judgment record, mark change reason and impact scope and release new permission mapping table, and recycle the previous version to form a reviewable version sequence and end this round of processing.

2. The interactive device permission management system of claim 1, wherein: The time scale acquisition module establishes a unified timeline around three sources of role context, process state and interface operable item, first corrects the order and fills in the gaps with source timestamps, and then completes three-way alignment according to role identification, process node identification and element identification, outputs context snapshot with source fingerprints and time anchor point.

3. The interactive device permission management system of claim 2, wherein: The time scale acquisition module generates context snapshot, which contains three groups of fields of role responsibility, process node semantics and element operable attribute, and records the snapshot instant with time anchor point.

4. The interactive device permission management system of claim 3, wherein: The time scale acquisition module constructs a source mapping table to mark the traceable path from data source to context snapshot, and when multiple entries conflict in the same period, it performs dilution and merging according to the serialization rules of process node priority and role responsibility priority to form a single available snapshot, and finally concatenates the snapshot index, time anchor point and source mapping table.

5. The interactive device permission management system of claim 4, wherein: The contract construction module constructs the interface contract with the context snapshot as input, introduces role semantic clause, process gate clause and element permission clause at the clause granularity, and homologous binds the three types of clauses as constraint set with element identification as landing point.

6. The interactive device permission management system of claim 5, wherein: The contract construction module generates clause landing point index, binds each clause with a unique or limited set of elements, and assigns each binding with applicable scope, inheritance relationship and mutual exclusion relationship, and when there is clause overlap or inheritance chain conflict, it first removes semantic reentry through mutual exclusion pruning rules, and then uses inheritance expander to expand and materialize the constraints.

7. The interactive device permission management system of claim 6, wherein: The mapping and fixing module reads the interface contract in the rendering stage, generates a permission mapping table according to the clause landing index, expands the entry, button, and jump path into two types of partitions, namely executable and non-executable, and writes the source clause and applicable scope for each partition.

8. The permission management system of an interactive device according to claim 7, wherein: The mapping and fixing module writes a behavior evidence chain, which consists of three parts, namely presentation evidence fingerprint, source clause fingerprint, and time anchor, wherein the presentation evidence fingerprint consists of element identification, interface level path, and interaction attribute, and then performs constraint conflict scanning, if the same element falls into both executable and non-executable partitions, a round of pruning is performed in a fixed order of clause priority, node time sequence priority, and role responsibility priority, and the pruning record is attached to the evidence chain.

9. The permission management system of an interactive device according to claim 8, wherein: The adjudication evaluation module aligns the operation event and the approval record according to the time anchor, locates the unauthorized entry and semantic drift based on the evidence chain, calculates two field parameters, namely contract landing consistency and approval time sequence offset strength, then sends the two parameters, evidence chain fragments, and clause landing index to the responsibility anchor walker embedder, organizes the walk on the anchor graph with three types of nodes, namely role responsibility anchor, process node anchor, and element landing anchor, and three types of edges, namely source edge, time sequence edge, and constraint edge, obtains a low-dimensional representation, and outputs the adjudication credibility coefficient through a lightweight discriminator.

10. The permission management system of an interactive device according to claim 9, wherein: The version revision module reads the adjudication record, performs minimal change revision on the interface contract, locates the affected clauses through the clause landing index, accurately determines the change unit using the mutually exclusive pruning record and inheritance expander, generates a difference patch, describes the three types of changes, namely addition, replacement, and removal, at the clause level and landing level, generates an impact view, merges the clause dependency graph and landing dependency graph, marks the role responsibility, process node, and element set reached by the changes, and accordingly formulates a phased release plan and recovery strategy, releases the new mapping table, writes the new version fingerprint and presentation basis index, moves the last version to the reviewable version sequence, and finally generates a revision note.

Images