DNative-Twin: Decision Graphs and Digital Twins for Reconstructable Agentic DecisionsThanks: † Corresponding author: Gang Liu (lg@ccut.edu.cn).

We first define the state required to distinguish the two procurement runs introduced above. Let the decision-relevant state of an agentic system at time $t$ be

where $B_{t}$ contains decision objects; $K_{t}$ contains versioned knowledge; $P_{t}$ contains policies, constraints, and authority grants; $T_{t}$ contains tools and their observable states; $H_{t}$ contains authorized human or machine actors and their roles; $A_{t}$ contains agents and bounded skills; and $O_{t}$ contains outcome signals. $\mathcal{S}_{t}$ is the state relevant to one class of decisions. It includes an entity or state when changing that element can alter what an agent or authorized actor should know, do, avoid, escalate, commit, or later revise.

The decision layer is modeled as a temporal attributed heterogeneous multigraph

where $V_{t}$ is the set of nodes observed or valid by time $t$, $E_{t}\subseteq V_{t}\times\mathcal{T}_{E}\times V_{t}$ is the set of typed directed edges, and $X_{t}$ contains node and edge attributes. The maps $\phi:V_{t}\rightarrow\mathcal{T}_{V}$ and $\psi:E_{t}\rightarrow\mathcal{T}_{E}$ assign node and relation types. The metadata map $\rho$ assigns each graph element an environment label, source time, ingestion time, validity interval, version, provenance reference, and confidence when applicable. A multigraph is required because the same entities may participate in several relations or repeated time-indexed interactions.

The graph contains state, execution, authorization, and decision entities. An interaction is represented by nodes and typed edges instead of one overloaded event tuple. For example, a ToolCall node connects to its invoking Agent, input DecisionObject, used EvidenceArtifact, tool version, and produced result. A CommitmentEvent connects a Recommendation to the AuthorizedActor, DecisionRole, and AuthorityGrant that turn it into an action with consequences. Later OutcomeSignal nodes record the observed result. This factorization preserves shared dependencies: one policy can govern several actions, one evidence artifact can support several recommendations, and one authority grant can cover a bounded class of commitments.

The state tuple identifies what must be retained; the graph schema makes those dependencies queryable. Table I gives the smallest set of types used by the invariant checks. A domain may add or refine types while preserving the distinction between context, execution, authorization, and commitment.

Each node used in a decision trajectory records its identity, time, type, environment, and source. Additional metadata is attached only when it is needed to reconstruct a dependency: version references for evidence, execution references for tool calls, and authority references for commitments. The graph may store governed references instead of sensitive source content.

This schema connects what informed a decision, how the mechanism acted, and what authorized the commitment. The procurement case later maps these roles to purchase requests, managers, and approvals. In an automated setting, the same authority path can end at a machine actor operating within a grant issued in advance.

A decision mechanism is denoted by

where $Q$ is a set of typed decision states, $\pi$ is the action policy of participating agents and actors, $\Gamma$ contains transition and path constraints, and $\Lambda$ defines commitment, escalation, and release rules. Keeping $\mathcal{M}$ separate from $\mathcal{G}_{t}$ allows the same mechanism to be replayed against different synchronized states and allows candidate mechanisms to be compared over the same decision object. We decompose the constraint set as

where $\Gamma_{\mathrm{app}}$ contains state-conditioned applicability constraints.

DNative-Twin distinguishes three properties that are often conflated. Traceability establishes the source, provenance, and version of an artifact. Validity establishes whether that artifact was legally or temporally valid when used. Contextual applicability establishes whether a valid artifact applies to the current decision state. For a state-sensitive dependency $v$, we define

Thus, $\operatorname{Valid}(v,t)=1$ does not imply $\operatorname{App}(v,\mathcal{S}_{t})=1$. A purchasing rule may remain the current valid version while applying only below a monetary threshold or outside a high-risk supplier class. The metadata map $\rho$ therefore includes machine-readable scope and precondition fields for state-sensitive policies, evidence, authority grants, skills, tools, and path rules [1]. Whenever natural-language conditions cannot be compiled into explicit predicates, the graph records the unresolved condition and routes the dependency to governed review rather than treating it as applicable by default.

For a decision object $b$, an observation interval $[t_{0},t_{1}]$, and a terminal node $z$ associated with $b$, define the decision trajectory as

where $\phi(z)\in\{\texttt{DecisionEvent},\texttt{CommitmentEvent},\texttt{ReviewEvent}\}$. The set $V_{b,z}$ contains $b$, $z$, all admissible decision ancestors of $z$ in the interval, and any outcome nodes explicitly attributed to $z$. The set $E_{b,z}$ contains the typed relations among those nodes. Admissibility is defined by relations such as uses, supports, invokes, produces, reviews, authorizes, commits, committed_as, and results_in. The boundary rule excludes records that merely share a case identifier but have no decision relation to $z$.

For sequential inspection, the trajectory can be viewed as a time-ordered event sequence:

where $\operatorname{TopoTime}$ returns a time-respecting ordering with stable tie-breaking for concurrent events. This ordered view is useful for inspection, while the graph retains shared evidence, competing recommendations, parallel tool calls, and reviews that resolve several branches.

A recommendation and a consequential commitment are distinct nodes. Let $R$ be the set of Recommendation nodes and $C$ the set of CommitmentEvent nodes. For $a\in C$, the committed trajectory $\mathcal{T}(b,a;[t_{0},t_{1}])$ exists only when the graph contains a recommendation relation and an applicable authority path. All antecedent relations point toward the commitment event:

This definition records an agent recommendation and the action that gives it practical effect as separate events. In human–AI collaboration, an authorized person may accept or modify the recommendation and create a commitment event. A rejection is recorded as a ReviewEvent and produces no commitment event. In automated operation, an authorized machine actor may commit the output within authority granted in advance. Both forms record the source, scope, validity, and constraints of that authority.

With the graph and trajectory established, the technical problem can now be stated. For a commitment event $a$, let $\mathcal{R}_{pre}(a)=\{R_{1},\ldots,R_{m}\}$ be the required antecedent type groups, where each $R_{j}\subseteq\mathcal{T}_{V}$ contains acceptable alternatives for one requirement. A minimal configuration contains the groups $\{\texttt{DecisionObject}\}$, $\{\texttt{EvidenceArtifact}\}$, $\{\texttt{KnowledgeUnit},\texttt{PolicyRule}\}$, $\{\texttt{Agent},\texttt{ToolCall}\}$, $\{\texttt{AuthorizedActor}\}$, and $\{\texttt{AuthorityGrant}\}$. Let $\mathcal{C}(a)$ contain the required temporal, version, applicability, cardinality, confidence, and path constraints.

Let $\operatorname{Anc}_{\mathcal{L}}(a)$ denote nodes reverse-reachable from $a$ through admissible relation types $\mathcal{L}$, and let $\operatorname{Desc}_{\mathcal{L}}(a)$ denote nodes forward-reachable through admissible outcome relations. Outcome coverage is

The pending state records that the outcome is expected but not yet observable. Decision reconstructability is

Given partial observations from heterogeneous systems, the task is to construct a trajectory graph whose commitment events satisfy $\operatorname{Recon}$, preserve the separation between recommendation and commitment, and remain comparable across real, twin, and perturbed environments. This formulation distinguishes three failures. A capture failure occurs when a required entity or relation is absent from the graph. A mechanism failure occurs when a recorded trajectory violates a decision constraint. A divergence occurs when two otherwise valid trajectories differ across environments. The resulting record supports later analysis of correctness, fairness, and causality, each of which requires its own evidence.

Reconstructability establishes what must be present in one trajectory. Comparing the same mechanism across environments additionally requires synchronized state and aligned trajectories. The synchronization contract defines a typed mapping

where a real graph delta is normalized, validated, and projected into the twin with explicit source and ingestion times. The mapping need not preserve identity: production identifiers may be tokenized, sensitive evidence may be represented by governed references, and unavailable tools may use consequence-preserving stubs. The contract must state what is synchronized, with what freshness, under which transformations, and how failed updates are represented.

A scenario operator $W_{\delta}(\mathcal{G}_{twin},\mathcal{M},b)$ applies a typed perturbation $\delta$ and produces a terminal node $z^{\delta}$ and trajectory $\mathcal{T}_{b,z^{\delta}}^{\delta}$. The terminal node may be a CommitmentEvent, ReviewEvent, or another declared DecisionEvent. Terminal nodes from two environments are aligned when they share the decision object, replay lineage, mechanism version, and observation window. We write this condition as $\operatorname{Align}(z^{i},z^{j}\mid b,\mathcal{M},[t_{0},t_{1}])=1$; the terminal-node identifiers and types may differ. For aligned trajectories, the graph-difference operator produces

and compares nodes, edges, attributes, and decision paths across environments [2]. Let $d_{ij}=D(\mathcal{T}_{b,z^{i}}^{i},\mathcal{T}_{b,z^{j}}^{j})$ denote the resulting GraphDiff. Synchronization projects observed state changes into the twin, perturbation applies a declared intervention, and $d_{ij}$ records the resulting trajectory changes. Environment labels keep perturbed data separate from real-world evidence and preserve each divergence for review.

Locating a structural change is not enough to determine its governance effect. The next definitions separate structurally different but governance-equivalent trajectories from changes that alter a required policy, authority, evidence, or outcome condition.

Two executions may retrieve independent evidence in different orders while preserving the same decision dependencies. We define governance equivalence, $\mathcal{T}_{i}\sim_{\mathcal{I}}\mathcal{T}_{j}$, when the trajectories have equivalent required-evidence coverage, applicable-policy set, authority path, critical-invariant vector, commitment class, and outcome constraints. Structural differences inside an equivalence class are benign; differences that change one of these governance-relevant projections are material.

For diagnosis, each change in $d_{ij}$ may receive one or more observable source labels:

The source labels are not mutually exclusive. State labels cover evidence, knowledge, policy, authority, or outcome changes. Configuration labels cover model, prompt, skill, seed, or decoding changes. Tool labels cover version, availability, replay mode, or returned state. Stochastic labels mark residual variation under a fixed replay contract, and mechanism labels mark an intentional revision.

Let $\mathcal{I}$ be the declared invariants and $\mathcal{P}$ the decision policy. A rule-based adjudication function

returns the first applicable label in the following order. It returns unresolved when the available evidence cannot support a governed classification. With sufficient evidence, it returns critical for a mandatory authority, isolation, evidence, or review violation; material for another change to a governance-relevant projection; and benign when the trajectories remain governance-equivalent. This priority makes the four labels mutually exclusive. Frequency does not override a mandatory constraint: a less frequent trajectory may be the valid one when it satisfies a required escalation rule.

Consider the purchase request used throughout the paper. When a new supplier alert arrives, DNative-Twin records the alert and its effect on the request, then copies that state into an isolated twin. The twin first replays the recorded decision and then tests a declared change, such as a budget-tool timeout. Comparing the two paths shows where the decision mechanism changed and whether the change violates a constraint. If adjustment is needed, the proposed revision is tested under the same conditions before release. Figure 1 shows this closed loop from observation to review.

Source connectors capture decision-relevant changes from operational systems and agent activity. A normalization step converts each source record into a typed graph update while preserving its origin and time. The graph can therefore connect a decision to the information and authority on which it depended, as well as to its later outcome.

No single source record normally contains this full path. Table II therefore compares the information retained by common record types. DNative-Twin joins these records around a decision trajectory, which becomes the unit of replay and comparison.

Isolated replay asks whether the same mechanism follows the same governed path when it runs against a synchronized copy of the decision state. For the purchase request, the twin can reuse the recorded supplier alert, policy version, and budget state without issuing another order. Any call that could affect the real environment is replaced by a read-only or simulated call labeled environment=twin. The twin has no authority to commit an external action.

This isolation is useful only when the real and twin runs refer to the same decision. The replay record therefore binds the real object, mechanism version, synchronization cutoff, and any controlled or substituted execution state. Comparison focuses on the resulting decision path and its governed dependencies. Thus, two runs that both approve a request still differ materially if the replay omits a required supplier alert or review. Different internal traces remain governance-equivalent when they satisfy the same declared constraints.

Under these bound conditions, shadow replay re-executes the mechanism against the synchronized state:

The real trajectory $\mathcal{T}_{\mathrm{real}}$ is an attributable comparison reference rather than executable ground truth. The replay contract

groups the replay conditions into four parts: decision identity and cutoff $(b,t_{\mathrm{cut}})$; governed state $(K,P,H)$; execution configuration $(A,T,\Theta)$; and environment $\Omega$. Each unbound or substituted field is recorded as a possible source of divergence.

Tool behavior is the main case in which a replay needs a substitute. The framework supports three modes: reuse the recorded response, execute a read-only copy, or use a stub that preserves the declared result or failure. These modes answer different questions. Reusing a response isolates the downstream mechanism, whereas execution also tests the synchronized tool state. Table III states the interpretation of each mode; the ToolCall node records the selected mode and the information needed to reproduce it.

Replay establishes a baseline; perturbation then tests one declared dependency of that baseline. For example, the purchase-request replay can replace a successful budget check with a timeout. The resulting ScenarioPerturbation identifies the changed dependency and links it to the trajectory that diverges from the baseline.

Each scenario records the intervention in a machine-readable form and remains tied to the original decision and replay state. This link makes the comparison attributable: the observed difference is evaluated against a named change rather than an unspecified change in the environment.

Semantic adjudication determines whether a replay difference affects a declared constraint and whether the mechanism requires adjustment. In the budget-timeout example, a missing escalation path would be classified against the declared invariants. A candidate revision could then add the required fallback for that condition. The graph links the revision to the observed divergence and its verification record [3]. The revision becomes eligible for deployment only after it satisfies the release conditions below.

Release readiness tests whether a candidate mechanism $\mathcal{M}^{\prime}$ remains within its declared constraints. The mandatory scenario suite is $\mathcal{D}_{crit}$. Its pass indicators are $C_{inv}$ for invariants and $C_{scn}$ for critical scenarios. The remaining terms measure material divergence $(r_{mat})$, governance equivalence $(r_{eq})$, twin freshness $(f_{twin})$, and unresolved critical cases $(N_{crit,unres})$ against configured thresholds. We define

Passing these criteria makes the mechanism eligible for authorization under the declared scenario suite and thresholds. The subsequent GovApproves step records the independent authorization decision; release requires both results. Synchronization drift, a policy or tool change, a new incident, or a new critical scenario reopens the revision cycle when it invalidates a release condition. A maximum iteration count and replay budget stop the cycle when the available evidence cannot distinguish candidate mechanisms.

Algorithm 1 summarizes the graph, replay, difference, and adjudication operations defined above. Here, $S$ is the source-record collection and $\Delta_{scn}$ is the set of declared perturbations. The observation window $[t_{0},t_{1}]$ is part of every trajectory comparison.

The architecture becomes technically reviewable when its main claims can be checked. DNative-Twin expresses its declared decision constraints as graph properties. Table IV connects each property to a graph check and a concrete failure. Together, these checks test whether an implementation preserves the distinctions required for reconstruction and replay.

The invariants require six graph operations. Reverse reachability checks the dependencies required by $\operatorname{Recon}$, while constrained path queries verify review and authority paths. Temporal and applicability checks establish whether a recorded dependency was valid for the decision state. Subgraph matching detects prohibited shortcuts, such as a recommendation connected directly to an external action. Graph difference then reports changes between aligned trajectories. A property graph with a rule or query engine is sufficient to implement these operations.

A minimal reproducible artifact should test whether the specification can be executed outside the deployed system. Table V lists the files needed for that test.

The real and twin examples must share a decision object, replay lineage, mechanism version, and observation window. Each graph retains its terminal node, $z_{r}$ or $z_{s}$, so that alignment is checked before graph difference. At least one declared perturbation should then change the synchronized trajectory. The checker returns pass/fail results with witness paths or missing-type diagnostics for I1–I7, and the difference tool reports node, edge, attribute, and path changes. The scenario manifest, release conditions, and evaluation summary supply the remaining inputs to $\operatorname{ReleaseReady}$. Together, these files allow an independent implementer to construct trajectories, verify invariants, classify their differences, and execute the declared release checks without access to the deployed system.

The enterprise evaluation separates four sources of evidence. Public logs test graph construction, while controlled overlays add decision fields that the logs do not contain. Constructed suites isolate replay and release behavior, and external-model probes measure repeated-output variation under recorded request protocols. Each field is labeled as source-observed, derived, overlaid, injected, or model-annotated.

The public-log layer uses OCEL 2.0 Procure-to-Pay [4, 5], BPI Challenge 2020 PermitLog [6], and BPI Challenge 2019 [7]. The logs record process events and object relations. LLM prompts, replay modes, authority grants, and machine-readable applicability rules appear only in the declared overlay or injected layers.

Table VI reports the graph sizes produced by the declared mappings. The BPI 2019 result uses a seed-42 reservoir sample obtained after scanning the full log. An independent operator reran the fixed pipeline on the checksum-verified 728,558,522-byte XES and reproduced all 18 declared checks. The rerun recovered 251,734 traces, 1,595,923 events, the ordered 5,000-case sample, and the graph counts in the table; the sampled case-ID files were byte-identical.

The evaluation asks five questions: whether the graph can represent and retrieve decision dependencies (RQ1), whether replay is stable under a fixed contract (RQ2), whether material and null interventions can be distinguished (RQ3), whether replay-contract and verification information improve adjudication (RQ4), and whether the revision gate rejects an injected defect and accepts its bounded repair (RQ5). The comparison conditions reveal progressively more information: B0 contains only the final output, B1 adds the ordered trace, B2 adds structural GraphDiff, and B3 uses the full graph and its queries. Schema coverage reports which declared types are present; the remaining tests evaluate the behavior of the implementation.

We use a constructed procurement case to show how the enterprise instantiation operates. Purchase request PR-2048 concerns a time-sensitive component from supplier S-17. The request instantiates DecisionObject, the procurement manager instantiates AuthorizedActor, and the recorded approval instantiates CommitmentEvent. In the baseline trajectory, procurement agent A-proc retrieves supplier evidence E-supplier-v12, applies policy P-proc-v7, and receives a successful response from budget tool call TC-budget-91. The agent produces recommendation R-approve-1. Manager H-lee reviews it under authority grant AG-44 and creates commitment event AD-approve-1; the purchasing system later records outcome O-po-issued. This trajectory separates the recommendation from the authorized commitment and its outcome.

Table VII contrasts the baseline record with two replay operations. A call-level execution trace can record input, output, and order. The trajectory graph also retains the dependencies needed to explain why a replay followed a different governed path.

In the perturbed scenario, a regional supplier-risk alert is added as knowledge node K-supplier-alert-v13. The synchronization contract copies its effective time and source reference into the twin. Policy P-proc-v7 remains valid, but the high-risk state activates its escalation rule. Replaying the same request produces R-escalate-2, and the GraphDiff links the changed supplier state to the newly activated path.

The scenario engine next removes the primary manager’s authority. This change exposes a structural defect: the mechanism requires review but has no valid alternate path, so the request remains suspended. The resulting review package links the stalled trajectory to the missing delegation. A candidate revision adds a bounded alternate-approver rule and is replayed against the full scenario suite before release. Two additional scenarios test evidence availability and regional shipping constraints.

The case connects the formal definitions to one complete procurement trajectory. Synchronization introduces a declared knowledge change, shadow execution avoids another purchase order, and perturbation tests a failed condition. The GraphDiff then distinguishes a valid escalation from a missing authority path. The quantitative tests below evaluate the corresponding operations.

Graph construction and dependency queries.

Table VI shows that the implementation instantiated both case-centric and object-centric logs. On OCEL, all 3,371 evaluable commitments passed recommendation–commitment separation and reconstructability reachability, and all 1,598 purchase-order objects contained a Create–Approve–Pay trajectory. Checks that required an absent field were evaluated only after the field was supplied by the declared mapping layer.

Six mappings specified before the held-out evaluation were applied to the same 5,000 BPI 2020 cases. The base mapping produced 225,290 nodes; strict and broad commitment mappings produced 188,093 and 228,761. Removing the overlay policy layer reduced knowledge-policy traceability from 1.0 to 0, while unresolved resource identity reduced the human-approval-path pass rate from 1.0 to 0. The strict-evidence variant equaled the base mapping on this sample. The query results therefore depend on preserving the entities and relations required by each question.

Seven controlled cases answered five dependency questions. Overall query accuracy was 0.06 for B0, 0.14 for B1, 0.20 for B2, and 1.00 for B3. B3 executed graph queries over task-specific cases and overlay ground truth; B0–B2 lacked part of the information available to B3. This experiment shows that the graph queries recover the declared dependencies in the seven constructed cases.

A separate annotation probe tested whether event-log text alone supplied stable governance labels. On 20 BPI 2020 cases, two prompt-separated LLM annotators achieved 0.55 raw agreement ($\kappa=0.5175$).

Replay, perturbation, and adjudication.

Fifty real BPI 2020 case carriers were executed 30 times under a fixed temperature-zero contract. Exact trajectory match and governance-equivalent replay rate were 1.0, and no trajectory variation was observed in this configuration. A separate injected-noise condition produced a flip rate of $0.098\pm 0.014$ while preserving governance equivalence. This condition tests whether governance equivalence remains stable when outputs are deliberately changed; external-model variation is measured separately below. Separately, 38 of the 50 selected carriers passed I5, which measures knowledge-version traceability.

The controlled perturbation suite applied 42 material and 27 null interventions to seven constructed cases. Ground truth used an applicability threshold of 50,000, while the detector used an alert band of 55,000 specified before the evaluation. It detected 36/42 material changes (PS=0.8571; F1=0.9231), and all 27 null changes remained stable (NPS=1.0). The six misses were near-threshold changes from 50,000 to 50,001, which identifies the detector’s boundary sensitivity.

We then injected seven drift types into 40 held-out real BPI 2020 carriers, yielding 280 instances. Sensitivity over material and critical interventions, benign stability, and source localization were each 1.0. A graph-only detector classified all 40 unresolved tool-timeout instances as benign, giving zero unresolved recall and macro-F1 0.6667. An unrepresented tool state leaves no structural evidence from which to determine its consequence.

A three-condition controlled experiment specified before the held-out evaluation isolated the required information. Thirty held-out BPI 2020 carriers were combined with 11 declared scenarios. The critical-timeout scenario required an adopted request above 50,000; all 30 carriers were at or below this threshold, so those instances were excluded. The remaining 300 instances comprised 180 benign, 30 material, and 90 unresolved cases, with no critical case. Condition A used graph signals, Condition B added replay-contract tool state, and Condition C additionally used verification-result fields.

As Table VIII shows, replay-contract state recovered 60 of the 90 injected unresolved instances, and verification-result fields recovered all 90. Condition C uses injected signature-verification results and therefore measures the value of making those outcomes available to adjudication. The reported macro-F1 is averaged over the supported benign, material, and unresolved classes.

The three tool modes clarify why the contract matters. With no drift, response injection, executable replay, and consequence-preserving stubbing agreed. Under budget or supplier drift, injection retained the historical observation, executable replay exposed the current state change, and the stub preserved its decision consequence without a production write. Tool replay mode is therefore part of the meaning of a trajectory comparison.

Revision, runtime, and external-model probes.

The revision demonstration introduced $\mathcal{M}_{0}$, in which a budget timeout had no fallback, and $\mathcal{M}_{1}$, which added bounded escalation. Critical-invariant pass rate increased from 0.7143 to 1.0, material-divergence rate decreased from 0.3333 to 0, governance-equivalent rate increased from 0.7143 to 1.0, and unresolved critical cases decreased from six to zero. Under the four evaluated thresholds, $\mathcal{M}_{0}$ failed and $\mathcal{M}_{1}$ passed. Applying the gate to a release additionally requires synchronization freshness, the complete critical-scenario suite, iteration limits, and replay-budget checks.

Scalability was measured at four BPI 2020 sample sizes with five repetitions and no failed run. Median end-to-end time was 0.794, 1.682, 4.335, and 8.889 seconds at 500, 1,000, 2,500, and 5,000 cases, respectively. At 5,000 cases, median graph construction and invariant checking required 1.797 and 3.846 seconds. These measurements report observed scaling for Python 3.11.15 and NetworkX 3.6.1 [8] on an Apple M5 Pro with 64 GB RAM.

The external-model probes used five repeated calls per case. Baseline agreement is the fraction of repeated outputs that matched the recorded baseline label. The exploratory 20-case DeepSeek probe and the preregistered 100-case probes produced mostly parseable outputs, with exact-repeat rates from 0.70 to 0.96. Table IX reports the full results.

The 100-case probes used the same carrier set and prompt but different models and provider-imposed sampling parameters. The probes therefore characterize repeated-output variation within each recorded protocol. Four Kimi responses were unparseable, and its interrupted run resumed from per-case checkpoints recorded in metadata. The remaining variation motivates repeated replay when output stability is part of the contract.

The evaluation supports three findings. The declared mappings construct typed graphs from the reported enterprise logs. The controlled suites execute replay, perturbation, adjudication, and bounded constraint adjustment under their specified conditions. In the injected protocols, graph structure misses an unrepresented tool failure, while replay-contract state and injected verification results recover the 90 unresolved instances in the three-condition experiment.