Source-linked AI summary
EnvOS: Auditing Computer-Use Agents When the World Moves On : Phenomenon-Based Task Construction, Certification, and Evidence-Based Evaluation
Ankush Kadu, Athira Gopal, Niharika Singh, Arpit Jain, Aswanth Krishnan
TL;DR
Computer-use agents act in applications whose authoritative state can change during a task, making it difficult to distinguish agent failures from invalid interventions, missing observations, or scoring errors. EnvOS constructs and certifies changing environments and audits episode verdicts from archived evidence. In two stale-information workflows, outcomes varied by model and review interface; the prospective study does not establish performance in unrestricted native computer use.
Problem
Evaluating agents in changing applications requires distinguishing agent decisions from failures in the intervention, observation delivery, or grading machinery.
Source: §1 · p. 1Method
EnvOS links phenomenon-based task construction with executable certification and auditable outcome analysis, using archived evidence to reconstruct supported verdicts.
Source: §1 · p. 2Results
Direct clinic-location disclosure improved Opus 5 over a verification reminder and source link (LIVE–CUE paper-wide p = 0.00293), while insurance results varied by model and adjustment.
Source: §1 · p. 2, §12 · p. 17Takeaways & Limitations
The tested stale-information outcomes depended on model configuration and review-time information, and do not support a general model ranking.
Source: §1 · p. 2, §12 · p. 17The prospective evaluation covers two synthetic-workplace workflows under a controlled semantic-browser interface, not unrestricted native computer use or naturally occurring change-time distributions.
Source: §11 · p. 16
Abstract
from arXiv · showhide
Computer-use agents built on large language models (LLMs) work in software that can change while they act: an appointment moves, a policy is revised, a record is updated. Testing agents under such changes is harder than it looks. When an agent fails, the cause may be the agent, but it may also be a change that did not fire as intended, an update the agent never received, or a grader that scored the episode wrongly. We introduce EnvOS, a framework for building and certifying environments that change mid-task. Before any agent runs, EnvOS checks that each change fires correctly, that the task remains solvable, and that the grader separates correct from incorrect behavior; after each run, separate code re-checks the verdict from archived evidence. We apply it to stale information, where a value the agent has already seen changes before the agent acts on it. In clinic booking, Claude Opus 5 succeeds on 0/16 tasks when nothing extra is shown, 2/16 when reminded to re-check the source, and 15/16 when the updated value is shown; the gain over the reminder holds after correcting for all tests (p = 0.00293). In insurance-claim approval, Opus 5 re-checks on its own and succeeds on 10/10, whereas Claude Sonnet 5 rises from 1/10 to 9/10 when the current policy is shown again, a gain significant in its pre-registered test but not after correcting for all tests. Whether an agent caught a change thus varied with the model and the interface. We also stress-test the grading itself: on corrupted episodes designed blind from the rules, the EnvOS pipeline accepted none of 26 as clean, and on an externally generated set it caught 25 of 39, against 4 for simple log checks. Because every EnvOS environment is generated from a seed and graded by an audited automatic verifier, the same environments are natural candidates for training agents with reinforcement learning from verifiable rewards.
1 Introduction
EnvOS addresses the difficulty of determining whether failures in changing applications reflect agent behavior or flaws in the intervention, observation delivery, or grading. It separates authoritative state changes from what agents see and combines certification with evidence-based evaluation.
1 Introduction
- Failures can be misattributed when an intended change does not occur, assigned observations do not reach the agent, or the scorer lacks evidential support.A terminal pass/fail label alone cannot distinguish these validity problems from an agent’s decision failure.Source: §1 · pp. 1–2
- EnvOS links application-independent phenomena to executable, exposure-conditioned interventions and audits outcomes after prospective experiments freeze their rules.Its checks cover state transitions, observation consistency, feasibility, behavioral discrimination, and scorer robustness.Source: §1 · p. 2
- A stale-information episode requires a value to be served before a later state mutation, while service, model delivery, and comprehension remain distinct events.The application’s authoritative state determines the committed outcome; review displays change information, not the underlying mutation.Source: §1 · pp. 2–3, Figure 1 · p. 3
- The prospective study finds configuration-dependent results: direct clinic-location disclosure improves Opus 5 over a source link, while insurance outcomes differ by model and adjustment.The clinic advantage holds after paper-wide correction; Sonnet 5’s insurance benefit does not, and the configurations do not support a model ranking.Source: §1 · p. 2
- Seeded environments and state-based verifiers are proposed as reusable verifiable-reward settings, while supplementary phenomenon families remain separate from the principal experiments.Evaluator challenges also delineate where automated verifiers could mis-reward episodes.Source: §1 · p. 2
2 EnvOS Framework
EnvOS constructs candidate tasks, certifies them against specified obligations, and audits admitted episodes using archived evidence. Pre-run admission and run-level verification answer different questions and neither guarantees every later episode is valid.
2 EnvOS Framework
- EnvOS couples state-changing task construction with executable assurance and auditable outcomes because a working mutation alone does not establish solvability, observation delivery, or correct scoring.Its workflow constructs a candidate, certifies it, then executes admitted instances with auditable outcomes.Source: §2 · p. 3
2.1 Construction of Evaluation Instances
- A candidate evaluation artifact combines a task, seeded world, executable perturbation, permitted observations, registered success invariants, and scorer.Task semantics are author-specified; EnvOS automates instance construction, execution, and checking rather than unrestricted generation of objectives.Source: §2.1 · p. 3
2.2 Certification Before Model Execution
- Pre-run certification checks intervention validity, observation consistency, feasibility, behavioral discrimination, and scorer robustness before admitting an instance.Checks can be repeated on frozen generated instances; an unassessable obligation is not a pass, and admission does not guarantee every future episode’s validity.Source: §2.2 · pp. 3–4, Figure 2 · p. 4
2.3 Controlled Execution and Adjudication
- Run-level adjudication determines episode validity before scoring task invariants against authoritative application state at the agent’s consequential commit.This ordering prevents faulty interventions or missing inputs from being counted as agent failures, while valid unsuccessful episodes remain failures under the protocol.Source: §2.3 · p. 4
2.4 Evidence Reconstruction and Audit
- Separate implementations reconstruct supported validity and endpoint terms from archived evidence, and evaluator challenges test detection of corrupted evidence and retention of valid controls.Unresolved terms remain unresolved when the archive is insufficient; challenges test evaluator reliability, not agent capability.Source: §2.4 · p. 4
2.5 Assurance Scope and Provenance
- Pre-run certification and run-level verification are complementary assurance stages, and passing one does not imply that another was checked.The versioned manifest links the task, intervention, disclosure conditions, and evaluator; supplementary phenomenon work does not necessarily share every implementation detail.Source: §2.4 · p. 4, §2.5 · pp. 4–5, Table 1 · p. 5
3 Phenomena and Perturbations
EnvOS distinguishes application-independent changes to authoritative state from their application-specific executable implementations. Its perturbation and admissibility rules make the intended state transition, timing, observation, and post-change feasibility explicit.
3.1 Phenomenon Specification
- An environmental phenomenon is a class of changes to authoritative application state, distinct from the task objective and from any model-visible notification.The prospective workflows instantiate this broad phenomenon as session-location and reimbursement-policy-limit updates.Source: §3.1 · p. 5
3.2 Executable Perturbation Model
- A perturbation encodes a state operator, trigger, disclosure channel, and once-only guard, keeping the state transition distinct from its disclosure.For stale information, the original-value serve arms the trigger and a later eligible request applies the update; the delivered frame is separately recorded.Source: §3.2 · p. 5
3.3 Intervention Admissibility
- Admissible interventions change the intended record at the specified boundary, avoid unintended state changes, follow assigned disclosures, and leave a feasible post-change task.The prospective paired conditions hold the authoritative transition fixed, so comparisons concern review-time information rather than the causal effect of introducing environmental change.Source: §3.3 · pp. 5–6
4 Tasks and Evaluation Conditions
The prospective evaluation uses clinic booking and insurance approval to test decisions after authoritative records change. In each principal comparison, the change is held constant while review-time information varies.
4.1 Clinic Booking
- Clinic booking combines mail, calendar, and portal information; after the session location changes, success requires a compatible appointment correctly committed in the application.The source remains accessible, but success does not require a particular source-revisiting action.Source: §4.1 · p. 6
4.2 Insurance Claim Approval
- Insurance approval requires an amount consistent with the policy limit authoritative at approval, and some instances require calculation beyond looking up the current limit.Unlike the clinic instructions, the claims task explicitly refers to the policy in force at approval.Source: §4.2 · p. 6
4.3 Experimental Conditions
- Principal paired conditions retain the same task-relevant state change and accessible source while varying information shown before the final action.Clinic compares direct current-location disclosure with a cue-and-link and with no added information; insurance compares policy re-exposure with no added policy information.Source: §4.3 · p. 6, Table 3 · p. 7
4.4 Endpoints and Trajectory Measures
- Task success is measured from committed application state and registered invariants, while source revisits and re-queries are separate trajectory measures rather than success requirements.The workflows test distinct requirements—selection under a superseded value and calculation from an updated policy—so results are analyzed by workflow and model configuration.Source: §4.4 · p. 7
5 Intervention Timeline and Agent Rollout
EnvOS records the sequence from an agent’s first exposure to a value through the state change, review, and final commit. Archived evidence separates what changed, what the agent received, and how the task was scored.
5 Intervention Timeline and Agent Rollout
- The original value is served first; the next eligible request triggers a single authoritative mutation before updated review information is rendered and the agent continues.The mutation occurs in every principal paired condition, source revisiting remains possible, and the agent acts under a fixed action budget.Source: §5 · p. 7
- Episodes archive the state-change event, model-facing observations, browser actions, commit, and final report; outcomes are validity-classified before scoring the committed record.Archived events also support independent reconstruction and targeted corruption tests.Source: §5 · p. 7
5.1 Episode-Level Evidence
- Separate episode evidence tracks the original serve, delivered observation, mutation, assigned disclosure, and final commit because none of these events proves another.A server log does not establish model delivery, and delivery does not establish comprehension or reliance.Source: §5.1 · p. 7
5.2 Evaluation Harness
- The prospective testbed has 14 containerized services, but only the clinic-booking and insurance-claim workflows are evaluated.The policy receives screenshot and text observations through a controlled semantic-browser interface and acts through a fixed schema.Source: §5.2 · pp. 7–8
- The clinic and claims tasks allow 48 and 40 actions, respectively, and the interface is not unrestricted operating-system-level computer use.The policy is invoked statelessly with a short memo and recent-action history; matched conditions share instance data and instructions.Source: §5.2 · p. 8
6 Certification and Evidence Auditing
EnvOS separates certification of a proposed changing environment from auditing each model rollout. It checks authoritative-state changes, observation delivery, feasibility, scoring, and the evidence supporting the final verdict.
6 Certification and Evidence Auditing
- Pre-run certification tests the candidate environment, while post-run auditing checks whether the recorded trajectory supports its validity classification and outcome.Both are necessary: an admissible candidate can still yield an invalid rollout, and a correct final record cannot establish the intended stale-world sequence.Source: §6 · p. 8
6.1 Authoritative State and Observation Channels
- A phenomenon specifies an application-independent class of authoritative-state changes, while a perturbation implements one environment-specific change with an operator, trigger, observation channel, and once-only guard.The application database is the source of truth; pages and messages are observations derived from it.Source: §6.1 · p. 8
6.2 Perturbation Admissibility
- Admissibility checks test timing, state scope, observation delivery, and endpoint evaluation, and an episode may satisfy some requirements while failing others.A terminal success flag alone cannot certify the full intervention history.Source: §6.2 · p. 8
6.3 Exposure-Conditioned Interventions
- An initial serve arms the trigger; the next eligible request applies the mutation as an application-side transaction, while the source remains accessible afterward.For valid episodes, endpoint checks include target state, a single commit, no collateral changes, required continuation where applicable, and consistency of the final report with the committed state.Source: §6.3 · p. 8
6.4 Pre-run Certification
- Pre-run certification exercises the environment and scorer on frozen instances, testing event sequence, target scope, observation delivery, feasible completion, behavioral discrimination, and known corruptions.Checks are scoped to tested scripted routes and generated instances; they do not guarantee coverage of unknown defects, and an unavailable check blocks admission.Source: §6.4 · pp. 8–9, Table 4 · p. 9
6.5 Outcome Reconstruction
- Separate code paths reconstruct supported validity and endpoint terms from archived evidence, but clinic calendar compatibility relies on generator and state-preservation conditions.The claims endpoint has broader independent reconstruction coverage; the separate code paths were developed by the same team and use the same archived evidence.Source: §6.5 · p. 9
6.6 Audit Coverage
- The operational audit records six stages: certification, policy isolation, frozen rules, validity-first counting, independent re-derivation, and targeted challenges.Each stage addresses a distinct failure mode.Source: §6.6 · p. 9
6.7 Policy Isolation and Observation Delivery
- Policy isolation uses a separate operating-system account, restricted permissions, specified browser origins, and access probes to bound access under the declared harness configuration.These measures do not reconstruct all provider-side inputs.Source: §6.7 · p. 9
7 Experimental Design
EnvOS freezes task and analysis rules before model evaluation, then compares matched conditions using validity-first outcomes and registered tests. Its inference is conditional on the fixed instances and sampled rollouts, and does not estimate the effect of introducing the phenomenon itself.
7 Experimental Design
- A reliable score first determines whether an episode belongs in the analysis, then whether its committed outcome passes; comparison rules are fixed before results are observed.EnvOS documents decisions per model–workflow block rather than searching across models for a single leaderboard score.Source: §7 · pp. 9–10
7.1 Preregistration and Validity
- Before rollout, each block freezes its instances, conditions, contrasts, budgets, validity rules, stopping rules, analysis, endpoint invariants, and interpretation templates.Runs are rejected if hashed artifacts drift, and amendments or departures are dated and reported.Source: §7.1 · p. 10
7.2 Matched-Instance Comparisons
- Inference is block-specific and conditional on fixed instances and one sampled rollout per condition; intervals and p-values omit task-population and repeated-sampling variation.The retrospective paper-wide Holm family is a sensitivity analysis, not a replacement for prospective claims registration.Source: §7.2 · p. 10, Table 6 · p. 11
7.3 Inference and Assumptions
- The paired difference counts treatment-only successes minus reference-only successes over n; the sign test uses discordant pairs, and the comparison cannot estimate the effect of the phenomenon itself.Because the phenomenon is injected in both conditions, the design also cannot isolate mediation through rechecking from other mechanisms.Source: §7.3 · p. 11
8 Results
The prospective results compare review-time information while holding each workflow’s underlying state change fixed. Outcomes differ across model–workflow configurations, and the clinic LIVE–CUE contrast remains significant after paper-wide adjustment.
8.1 Clinic Booking
- 15/16 Claude Opus 5 clinic instances succeeded with the updated location shown, versus 2/16 with a reminder and source link; LIVE–CUE remained significant after paper-wide correction (adjusted p = 0.00293).The matched outcomes are shown by instance; the comparison is the registered LIVE–CUE contrast.Source: §8.1 · p. 12, Figure 3 · p. 12
- Only 1/16 clinic verification-reminder trajectories followed the supplied link; the separately registered Sonnet clinic block was incomplete at cutoff, with 21 of 51 cells counted and no inferential interpretation.Following the link was a descriptive process count, not a separate success criterion.Source: §8.1 · p. 12
- The clinic LIVE–CUE contrast estimates the total effect of the interface choice at 48 actions, not value understanding with navigation cost removed.Avoiding navigation may explain the result, but the proposed mechanisms were not tested as mediators.Source: §8.1 · pp. 12–13
8.2 Insurance Claim Approval
- 9/10 Claude Sonnet 5 claims instances met the full approval endpoint with policy re-exposure, versus 1/10 without it; the registered block-local result did not survive paper-wide adjustment (adjusted p = 0.0781).The interface presents the current policy record, not the calculated approval amount.Source: §8.2 · p. 13
- 10/10 Claude Opus 5 claims instances succeeded both without additional policy information and with re-exposure, so its registered rescue-opportunity gate was not met and no panel-effect claim is made.Opus requested the policy record after the change in all 10 OFF-A runs; this is a descriptive process count.Source: §8.2 · p. 13
- On the 10 reused claims instances, Gemini 3.1 Pro Preview failed OFF-A on 10/10, but re-exposure did not meet its registered effect criterion (5 rescues, 0 harms, 5 ties; exact paired p = 0.0625).The non-rejection is not evidence of no effect; provider, invocation, and frame-delivery differences prevent isolating model or vendor effects.Source: §8.2 · p. 13
9 Evaluator Audits
EnvOS audits evaluator behavior using preserved episodes with known expected verdicts and distinct checks for outcomes, validity, and replay. Challenges expose both detection capability and residual errors, but are not independent-team or population-level accuracy estimates.
9 Evaluator Audits
- The sealed 28-case challenge met 28/28 outcome-scorer expectations, 24/28 validity-re-derivation expectations, and 10/28 archived-evaluator-replay expectations, unrepaired.The challenge was white-box to its builder and unseen by the Claude agents that built the pipeline, so it was not blind validation.Source: §9 · p. 14
- 0 of 26 rule-only corruptions were counted as clean: the pipeline caught 24, returned no verdict on 2, and accepted all 10 controls.Only case design was blind; authors instantiated the cases, clinic coverage was thin, and the outcome scorer alone counted 10 corruptions.Source: §9 · p. 14
- 25 of 39 external corruptions were caught across claims and clinic, compared with 4 caught by raw-log baselines; the pipeline also counted 12 corruptions as clean and rejected 3 of 16 controls.The external challenge was designed by a Gemini CLI agent, but expectations were disputed and it was not an independent-team audit.Source: §9 · p. 14
9.1 Challenge Coverage and Failure Modes
- Challenge reporting separates caught corruptions, corruptions accepted as clean, no-verdict cases, rejected controls, and disputed expectations rather than treating them as one reliability score.On the external challenge, 12 of 39 designated corruptions were counted clean, three of 16 controls were rejected, and 19 expectations were disputed.Source: §9 · p. 14, §9.1 · p. 15
- The post-hoc raw-log comparison rejected 11 of 12 clinic corruptions for both approaches, while on claims the pipeline rejected 10 and the baseline 6 of 12.The author-built comparison is diagnostic, not an unbiased detection-rate estimate; EnvOS checks a broader surface including delivery, served arm, and collateral state.Source: §9 · p. 14, §9.1 · p. 15
- Certification, re-derivation, and audits surfaced 11 defects, seven of which had already affected a previously scored archive; repairs do not retroactively validate earlier verdicts.Undetected corruptions, unevaluable archive terms, and incomplete provider-side traces leave evaluator reliability bounded to stated checks.Source: §9.1 · p. 15
10 Related Work
EnvOS situates its contribution among work on dynamic environments, observation, task generation, and verifier reliability. It emphasizes a specific exposure-and-delivery contract and evidence checks around authoritative mid-task changes, rather than claiming dynamic interventions or generation are unprecedented.
Dynamic environments and adaptation
- EnvOS’s specific contribution is an application value first served to an agent, then superseded, with matched review-time disclosure conditions and archive checks of that sequence.The paper characterizes this as a benign time-of-check–time-of-use gap, not a newly identified phenomenon.Source: §10 · pp. 15–16
Observation and stale-state reasoning
- Unlike work on invalidated memories, re-querying, or richer observations, EnvOS tests durable task actions under an unchanged instruction across no extra information, a source link, and direct disclosure of the current value.A prior serve does not establish that the agent comprehended the value.Source: §10 · p. 16
Task generation and perturbation design
- EnvOS complements CUA-Gym’s generation of tasks, states, and verifiable rewards by certifying that a mid-episode change and verifier behave as specified.The study uses authored phenomenon specifications and an implemented perturbation in a bounded synthetic testbed; it does not establish autonomous discovery or synthesis of change classes.Source: §10 · p. 16
Evaluation validity and verifier reliability
- EnvOS combines established techniques around the timing, disclosure, and scoring of authoritative mid-task changes, framing the comparison as one of focus and evidence coverage rather than universal novelty.The paper does not claim other benchmarks lack validation or that this feature combination is unprecedented.Source: §10 · p. 16
11 Limitations
The prospective study is bounded to two synthetic-workplace workflows under a controlled semantic-browser interface. Its evidence and generalization claims have additional limits, and it does not test agent training.
11 Limitations
- The evaluation covers two synthetic-workplace workflows under a controlled semantic-browser interface, with fixed counterbalanced orders and one sampled rollout per condition.It does not establish performance in unrestricted native computer use or naturally occurring change-time distributions, nor estimate the causal effect of environmental change itself.Source: §11 · p. 16
- The paper evaluates agents but does not train them, leaving untested whether certified non-stationary environments improve reinforcement-learning-trained computer-use agents.Prospective inferential claims rest on Claude-model blocks; the non-Anthropic block is a separate follow-up on reused instances.Source: §11 · p. 16
- Served pages and delivered frames do not establish agent comprehension, and clinic calendar compatibility is not independently reconstructed from archived records.Some provider-side inputs and historical endpoints are incomplete; archive challenges show residual false acceptance and control-rejection errors and are not population-level error-rate estimates.Source: §11 · p. 16
12 Conclusion
EnvOS separates authoritative state changes from what agents observe and audits episode validity before interpreting task success. The stale-information results vary by model and review-time information, while the paper identifies certified environments as candidates for verifiable-reward training.
12 Conclusion
- EnvOS combines phenomenon-based task construction, intervention certification, controlled evaluation, and evidence-based auditing, separating episode validity from task success.The framework distinguishes authoritative state transitions from their observation channels.Source: §12 · p. 17
- Clinic value display improved Opus 5 booking over the cue-and-link panel (paper-wide p = 0.00293); Sonnet’s policy re-exposure benefit did not survive paper-wide correction (p = 0.0781).Opus 5 succeeded 10/10 in insurance approval without review-step re-exposure; these contrasts do not establish a general model ranking.Source: §12 · p. 17
- Certified EnvOS environments are proposed as non-stationary, verifiable-reward settings for reinforcement learning, with audits helping guard rewards against hacking.The paper presents this as a natural next step.Source: §12 · p. 17
Reproducibility statement
- The supplement packages sources, preregistrations, archives, and a no-network, no-model script to recompute reported tables, figures, tests, and audit counts; some evidence remains unreconstructable.The paper identifies missing historical slot occupancy and unarchived CLI defaults as examples.Source: Reproducibility statement · p. 17
Ethics statement
- The office-v1 testbed is synthetic, with no human subjects, personal data, or production systems; evaluated commercial models ran under their providers’ terms.A prior result is reported as a non-replication, with earlier evidence retained in the supplement.Source: Ethics statement · p. 17
AI use statement
- LLMs contributed to implementation, methodology, evaluation infrastructure, and writing, but the paper says no measurement or experimental outcome was produced, altered, or selected by an LLM.Reported numbers are mechanically derived from archived artifacts by the claim ledger.Source: AI use statement · p. 18
Supplementary Evidence and Reproducibility
The supplement organizes material around checking results, evaluator reliability, reproduction, and development history. Its validity-table materials also document replacement rules and distinguish several failure categories.
Supplementary Evidence and Reproducibility
- Reported-results materials include the validity table, paper-wide multiplicity family, interpretation templates, independent-scorer coverage, and exposure-attribution checks.Source: Supplementary Evidence and… · p. 20
- Evaluator-reliability materials cover certificates, mutation testing, scorer and leak audits, raw-log comparisons, adversarial challenges, and a defect table.Source: Supplementary Evidence and… · p. 20
- Reproduction materials include the policy interface, invoker specification, manifests, claims ledger, and video index; separate materials record protocol development and historical provenance.Source: Supplementary Evidence and… · p. 20
A Validity table
- The validity-table excerpt says seven verdicts were replaced and four outcomes counted, and contrasts below 6/8 are not headlined under the stated rule.The excerpt also notes four historical validity-failure replacements.Source: A Validity table · p. 20
- Validity-table fragments distinguish behavioral control failures, provider or CLI rejection, infrastructure and verifier failures, arm mismatches, undelivered observations, and budget-limited failures.Source: A Validity table · p. 20
B Registered versus implemented rules
This section reconciles registered and implemented rules, examines how those choices affect reported outcomes, and documents certification and verifier checks. It also notes unresolved scoring and truth checks in archived evidence, a leak audit that passed with no channels leaked, and limits on what the mutation challenges can establish.
B Registered versus implemented rules
- ADDENDA 10, 11, and 16 changed delivery classifications or checkpoints and signatures, but none changed a verdict.The pre-ADDENDUM 10 classifier would have voided 25 silent-arm model failures; ADDENDUM 11 changed 4 signatures, and ADDENDUM 16 flipped 7 checkpoints and changed 4 signatures.Source: B Registered versus implemented rules · pp. 21–22
- Under validity-first application of the original delivery rules, 9 of 53 success rows would be voided: 8 current-block rows and 1 superseded-block row.Voided rows are unobserved, with no replacement outcomes imputed; the original screenshot rule would leave Block BS with 8 invalid attempts against a reserve of 6, while Block B is unchanged under every reading.Source: B Registered versus implemented rules · pp. 22–23, Table 10 · p. 24
- For Sonnet, all 3 stale FRX-ON-A failures had page-text delivery without a screenshot opening, while all 6 rescues involved opening the screenshot.The pre-registered rule would void those failures and successful FRX-ON-I controls (7 rows); the unobserved FRX-ON-A result is 6/7 (p = 0.0312), and neither rule voids Block B rows.Source: B Registered versus implemented rules · p. 22
C Certificates, mutation battery, independent scorer, leak audit
- The 9 certificates governing historical model blocks had 30–50 checks each, with zero failed checks and zero monitor errors; feasibility checks passed for 34/34 Block A2 and 44/44 Block B episodes.All 11 development mutations met their expected outcomes; an independent scorer re-scored 76 certification episodes with 0 contradictions, while noting 46 unresolved terms on 15 episodes of two deficient scripted policies.Source: C Certificates, mutation battery,… · pp. 23, 24, 26, 27
- The held-out mutation challenge met 8 of 10 frozen expectations: all 5 instantiated corruptions were rejected, and all 4 instantiated valid cases were accepted.One valid case could not be instantiated; the challenge was sealed but not blind, and its result does not establish general verifier soundness.Source: C Certificates, mutation battery,… · pp. 24–25, Table 11 · p. 25
- The sealed archive challenge met 24 of 28 frozen expectations: 14 of 18 instantiated corruptions were rejected and 10 of 10 valid cases were accepted.The challenge was built by a different model but was white-box to its builder; the evaluator’s archive-replay path met 10 expectations and missed 18, so the result bounds performance on this challenge family rather than establishing universal correctness.Source: C Certificates, mutation battery,… · pp. 25–26, Table 12 · p. 25, Table 13 · p. 26
- Archived evidence could not fully recount archived reward.passed (13) or recompute dense reward (13), and could not resolve invariant I3 or clinic truth (1).Source: C Certificates, mutation battery,… · p. 27
- The leak audit passed with 0 channels leaked across 5 canaries, 15 operating-system attempts, 8 browser attempts, and 5 model-read attempts.Source: C Certificates, mutation battery,… · p. 27
C.1 Independent-scorer coverage of every model episode
The independent audits distinguish intervention validity from whether archived episodes support the scored outcome. They confirm the archived validity verdicts under the implemented rules, but incomplete slot evidence prevents full verification of many successes.
C.1 Independent-scorer coverage of every model episode
- 46 of 78 counted episodes had unresolved target-state correctness because archived evidence could not establish the nearest available slot; all 32 fully resolved episodes were failures.The post-change clinic term was resolved for all 73 episodes that booked a row: correct on 46 successes and wrong on 27 failures.Source: §C.1 · p. 27, Table 17 · p. 29
- One repeated control notice was an injection-audit contradiction, not an invariant contradiction; the change fired once and the episode remained a success.The notice was dismissed, shown again before commit, and concerned an unchanged clinic.Source: §C.1 · p. 28
- 0 of 82 attempts supplied complete same-episode evidence for the nearest-slot term, because occupancy records were incomplete and every committing attempt wrote after its last occupancy read.Closing the gap requires new rollouts that archive the date’s appointment rows at the harness’s snapshot points.Source: §C.1 · p. 28
- A post-hoc fingerprint rule supported the selected slot in one success, but did not establish the full endpoint or independently verify the fingerprint’s date and clinic fields.Neither reconstruction rule recovered patient calendar conflicts, another required endpoint component.Source: §C.1 · p. 28
- Independent code agreed with the archive’s validity verdict on 82 of 82 attempts under implemented rules, but registered-rule interpretation counted only 71.The re-derivation used portal logs and harness records, and two interpretations were fixed after archive inspection.Source: §C.1 · p. 29
D Post-hoc checks against simple raw-log baselines, a crosswalk and fresh cases (author-built, not blind)
Post-hoc checks compared EnvOS’s claims pipeline with simpler raw-log checks and tested a reconstruction on fresh cases. The pipeline covered more corruption classes in claims, while the clinic baseline matched it within its narrower scope.
D Post-hoc checks against simple raw-log baselines, a crosswalk and fresh cases (author-built, not blind)
- The claims-path challenge used 29 cases copied from six archives, with every changed fact copied consistently and recorded digests recomputed before a single sealed run.The baseline checked policy-change timing and approval amount, but not delivery, collateral changes, reports, or archive completeness.Source: D Post-hoc checks against simple… · p. 30
- 16 of 19 claims corruptions were kept from a clean score by the pipeline, versus 6 by the raw-log baseline; the pipeline missed 3, while the baseline missed 11 and left 2 outside scope.The baseline-only catch was a duplicate commit that the registered I2 term accepted.Source: D Post-hoc checks against simple… · p. 31
- The crosswalk shows that the tools check different properties: the clinic re-derivation adds stale-page and notice-text checks, while claims checks commit-before-change order.Archive completeness is partial in every crosswalk column.Source: D Post-hoc checks against simple… · p. 31
- The challenge results are per case, not rates; its cases came from six archives of two models and one instance family, with 16 of 19 corruptions from one Opus OFF-A archive.The baseline was written after its author read the pipeline, although its source was sealed before the run and not tuned afterward.Source: D Post-hoc checks against simple… · p. 32
- The clinic raw-log baseline matched the protocol within its scope, while the claims comparison showed broader checked properties and a more robust causal chain, not that simple checks cannot match it.The clinic baseline did not check delivery, collateral rows, confirm state, or archive completeness.Source: D Post-hoc checks against simple… · p. 32
- 0 of 15 corruptions were missed by the reconstruction on fresh cases, compared with 7 by the frozen pipeline and 6 by the repaired checker.The 24 author-built cases used unused archive bases, but were not independent or blind because the authors knew the fault classes.Source: D Post-hoc checks against simple… · pp. 32–33, Table 20 · p. 33
E Rule-only case-design challenge (cases and expectations specified by GPT-6 without the implementation)
The rule-only and externally generated challenges tested whether EnvOS caught corrupted episodes, while the cue-versus-value blocks tested stale-information recovery. The results show both stronger pipeline coverage than simpler checks on some suites and substantial differences by model and interface.
E Rule-only case-design challenge (cases and expectations specified by GPT-6 without the implementation)
- 24 of 26 rule-only corruptions were rejected or flagged by the combined pipeline, none was counted as clean, and 2 received no verdict; all 10 controls were accepted.One corruption was assigned the wrong class, so 24/26 is not a clean detection count.Source: E Rule-only case-design challenge… · p. 34, Table 21 · p. 35
F Externally built challenge (cases, expectations and generator by an external model agent)
- On undisputed externally generated cases, the pipeline caught 14/16 claims corruptions and 11/13 clinic corruptions, while accepting every undisputed control.The baseline caught 1/16 claims and 2/13 clinic corruptions; the counts are per case, not detection rates.Source: F Externally built challenge (cases,… · p. 37, Table 23 · p. 38
- The externally generated challenge had 19 disputable expectations among 56, and its authors selected the rules, archives, instructions, and tools; results therefore apply to this suite, not pooled detection rates.The model constructor was not an independent research team, and it was also a policy under test elsewhere in the paper.Source: F Externally built challenge (cases,… · p. 37
G The cue-versus-value blocks (BC, BCS, BGC; BG2)
- Claude Opus 5 passed 0/16 OFF-A, 2/16 CUE-A, and 15/16 LIVE-A clinic tasks; LIVE versus CUE remained significant after paper-wide Holm correction (adjusted p = 0.00293).The comparison tested a reminder and source link against the same panel displaying the current location.Source: G The cue-versus-value blocks (BC,… · p. 39
- The CUE–OFF contrast did not reject, which does not establish absence of a cue effect; the fixed 48-action budget includes navigation effort saved by displaying the value.Contradiction, salience, and reduced verification effort remain possible explanations.Source: G The cue-versus-value blocks (BC,… · p. 39
- BCS ended incomplete and contributed no inferential result; BGC was not run because launch preconditions were unmet, and the BG2 fallback was not triggered.BCS rows are reported as an execution record only.Source: G The cue-versus-value blocks (BC,… · p. 40
H The claims blocks (CLM-B, CLM-BS)
This section documents how the claims-block tasks, interventions, interfaces, episode evidence, and interpretation rules are specified and audited, then reports the associated findings with validity and multiplicity qualifications. It distinguishes prospective results from historical and exploratory evidence, and records diagnostics, procedural changes, defects, reproducibility evidence, and interface limits.
H The claims blocks (CLM-B, CLM-BS)
- Opus 5 succeeded 10/10 with or without review, while Sonnet 5 rose from 1/10 to 9/10; Sonnet’s contrast was not significant after Holm correction.The review panel’s total effect does not isolate its verification cue, current-value display, draft disagreement, or reduced lookup effort. Sonnet passed the derived-decision gate on 3/3 threshold-crossing increases; one ON-A failure approved the correct amount but failed the report-format term.Source: H The claims blocks (CLM-B, CLM-BS) · pp. 41–42
I Block CLM-BG: a pre-registered non-Anthropic configuration follow-up (Gemini)
- Gemini’s net paired difference was +0.50 [0.12, 0.76] (Newcombe method 10), but its reading was R3 because only 1/3 threshold-crossing increases passed.The nominal within-block p was 0.0625, with no paper-wide family-wise claim; the follow-up was outcome-informed in its existence and intervention family, though its rollouts and analysis were prospective. Provider, model, invoker, tools, and frame delivery varied together, so the comparison does not establish a vendor effect.Source: I Block CLM-BG: a pre-registered… · pp. 42–43
J The claims task: instruction, instances, interface census and per-episode reconstruction
- The claims task required approval of min(eligible amount, policy limit at approval), and an approval could not be changed after submission.A standard-library reconstruction used raw episode evidence rather than archived verdict fields; among armed episodes, no post-change Policy records page was served in 15, and a looser report parser would have counted one additional Sonnet rescue (9 discordant pairs, exact p = 0.00391).Source: J The claims task: instruction,… · pp. 44–46
K Pre-scripted interpretation templates
- Interpretation templates were sealed before prospective block outcomes and selected readings by registered rules, including CLM-B R2 and CLM-BS R1.A dated erratum clarifies that shared files were compared with the closest surviving benchmark version, not a surviving claims-worktree base; the added-line count is an upper bound that includes benchmark-side drift.Source: K Pre-scripted interpretation templates · pp. 47–48
- The registered local interpretation is that review-time information increased full-task success, with paired outcomes and the net interval reported for the sealed instance pairs.The template separately reports the pass fractions with and without review-time information and the paired rescue, harm, and tie counts; the supplied passages contain placeholders rather than instantiated values.Source: K Pre-scripted interpretation templates · p. 49
- A local paired success difference does not support a transfer claim when the registered control-credibility criterion is unmet.The templates also state that failure to meet the derived-decision gate does not establish performance beyond the scalar-copy shortcut.Source: K Pre-scripted interpretation templates · p. 49
- Without the review display, the agent may succeed under silent supersession without meeting the registered rescue-opportunity threshold.The alternative template reports failures without review and does not establish a positive local effect; another records the possibility that review reduces success.Source: K Pre-scripted interpretation templates · p. 49
- Independent scoring re-derives outcome terms and validity verdicts against archived records, while readiness or execution failures yield no admissible model-effect result.The supplied template says outcome terms agree on a placeholder fraction of counted rollouts and validity re-derivation agrees on a placeholder number of attempts.Source: K Pre-scripted interpretation templates · p. 49
- The claims task reuses the clinic task’s scaffold, harness, invoker, and vendor, making it a second decision rule for the same intervention rather than an independent environment.No cue or announcement was varied in the claims task.Source: K Pre-scripted interpretation templates · pp. 49–50
- In CLM-B, review-time information increased Claude Opus 5’s full-task success locally, but control-credibility and derived-decision gates failed, so transfer beyond scalar copying was not established.The registered rescue-opportunity threshold was also not met, and the independent audit verified no historical success in full.Source: K Pre-scripted interpretation templates · p. 51
L The paper-wide multiplicity family
- The paper-wide Holm family contained 12 resolved tests; its adjustment of the claims tests was retrospective, while BC’s block-local adjustment remained prospective.The claims tests were individually pre-registered before rollout, but the paper-wide family was finalized after those outcomes existed.Source: L The paper-wide multiplicity family · p. 52, Table 31 · p. 52
M Decisions taken in the final night, disclosed
- A disclosed CLM-BS deviation restored the sealed reading rule and resumed the block without rerunning counted rows, but the block ended incomplete and both family slots became p = 1 placeholders.The halt followed an operator error that changed the sealed rule’s source digest; the operator had seen verdicts from the first four attempts, but resumption depended on none of them.Source: M Decisions taken in the final night,… · p. 53
N Diagnostic invariant-completion fraction and exposure attribution of the claims blocks
- For Sonnet 5, invariant completion rose from 30/40 (0.75) without review-time information to 39/40 (0.98) with it; OFF-A had 9 failed-after-exposure rollouts and 1 handled rollout.These are descriptive diagnostics derived from archived scorer and validity records, not tests or readings; a handled rollout may still miss another endpoint term.Source: N Diagnostic invariant-completion… · p. 54, Table 32 · p. 54
O The policy interface compared with other harnesses
- EnvOS uses a controlled semantic browser harness that reduces low-level perception and pointer-control variance, but its constrained actions and structured inputs limit direct score comparisons with other benchmarks.The paired arms share the same interface, supporting within-interface intervention contrasts; transfer to other interfaces remains an external-validity question.Source: O The policy interface compared with… · p. 54, Table 33 · p. 54
P The protocol as a minimal abstraction, and continuous change
- An EnvOS intervention is a tuple specifying the decision-relevant variable, exposure, trigger, control, validity rules, invariants, and interpretation map.Certification and audit checks test these components; the semantic-browser interface is not part of the tuple, and portability to another harness remains untested.Source: P The protocol as a minimal… · p. 55
- For asynchronous or continuous change, versioned authoritative state can distinguish acting on an old value from committing against the current version.A continuously drifting quantity also needs a decision-relevant threshold or stated tolerance; this extension has not been implemented, and the protocol requires versioned state.Source: P The protocol as a minimal… · p. 55
Q Task text and generator
- A salted digest of seed and split determines each instance’s task elements, while neutral mailbox and calendar work stays identical across treatment levels.The clinic pair and dropdown positions are counterbalanced; five salted splits partition the seed space, and later replication blocks reuse instances already seen by the experimenter.Source: Q Task text and generator · pp. 55–56
R Policy interface and invoker specification
- The harness-authored prompt and instruction were archived, but the CLI’s built-in system prompt, tool definitions, decoding defaults, and some per-step observation details were unavailable.The instruction matched the generator’s output byte for byte on all 82 archived rollouts.Source: R Policy interface and invoker… · pp. 56–57
- The archived interface accepted JSON actions across seven action types, with optional memos, and returned text observations; screenshot reading was optional, and episodes were capped at 48 policy steps in every block.Each action had a 15-second timeout. Text was clipped on 0 of 2,548 archived steps, and the frame was read on 2,305 of 2,548 model steps.Source: R Policy interface and invoker… · p. 57
S Observability, sensitivity and the within-episode timeline
- In historical Block A2, all 7 successful changed runs re-read the authoritative page before selecting, while the single failure did not.The figure describes the within-episode change, notice, re-read, selection, and commit sequence; these blocks used a predecessor protocol and were not pooled with prospective blocks.Source: Figure 6 · p. 62, T Historical, hypothesis-generating… · p. 63
T Historical, hypothesis-generating evidence (predecessor protocol)
- 10/10 paired instances had correct booked-clinic outcomes with value shown at review time, versus 0/10 without additional information.This historical contrast is hypothesis-generating, not confirmatory; full endpoint correctness could not be verified because slot occupancy was not archived.Source: Figure 7 · p. 62, T Historical, hypothesis-generating… · p. 63
U Historical records and registration provenance (supplementary files)
- Historical blocks are provenance only, not quantitative claims; their records and registration chronology are supplied as generated supplementary files.The files are written from pinned artifacts, macros, and generated tables, while registered-versus-implemented rules and final prospective specifications are documented in appendices.Source: U Historical records and registration… · p. 63
V Exploratory corpus (Stack B)
- Stack B covered 32 arms and 93 Opus 5 rollouts, but its per-arm rates are withheld because its trigger, validity, and verifier records were unreliable.The separately built exploratory corpus included 27 hand-written phenomena and 5 controls; it lacked certificates, used hand-coded triggers, handled turn caps inconsistently, and changed verifier versions during its lifetime.Source: V Exploratory corpus (Stack B) · pp. 63–64
W Full defect table
- Among 11 defects with archived evidence, 7 already had an archived search-log row scored under the defect carrying a success or model_failure verdict; the other 4 were caught before any model-scored row existed.Source: W Full defect table · pp. 64–65
X Extended related work
- EnvOS studies changes fired after an observed value and certifies exposure, contrasting with benchmarks such as STT-Arena (Hui et al., 2026) and stale-belief studies such as TOCTOU-Bench (Lilienthal et al., 2025).The related-work discussion distinguishes world-state changes from goal or interface perturbations and positions re-exposure as an environment-side counterpart to EnvProbe (Song et al., 2026).Source: X Extended related work · p. 66
Y Manifests and the claims ledger
- The packaged offline build re-derived all 2,319 ledger entries and 61 generated tables, and passed its claims, challenge, and prospective verification targets.The supplement reports 85 claims checks, 31 challenge checks, and 174 prospective checks; some evidence is permanently missing, including Block BS’s first manifest and archived interface and model records.Source: Y Manifests and the claims ledger · pp. 68–69
Z Video index
- Archived videos show Opus 5 committing a superseded clinic under FRX-OFF-A and changing its selection after review-time re-exposure under FRX-ON-A.The index also identifies a Sonnet 5 counterpart in which re-exposure does not rescue the agent, plus videos of the announced arm and its single failure.Source: Z Video index · p. 69
S1.1 General phenomenon model and executable perturbations
- A phenomenon is an application-independent class of real authoritative-state changes, implemented as a perturbation comprising a state operator, trigger, observation channel, and one-shot guard.Supplementary task manifests bind the base task, application state, phenomenon, perturbation, channel, checker, and reward; human authors specify scenarios and policies.Source: S1.1 General phenomenon model and… · p. 71
S1.2 Four-layer certification in the supplementary environments
- The bounded certifier uses 389 assertions across 19 suites to check world validity, consistent channel facts, and checker robustness, but admission does not prove global soundness.Checks include state-before-channel ordering and paired positive and near-miss examples for failure signatures.Source: S1.2 Four-layer certification in the… · pp. 71–72
- Certification requires a reference policy to solve clean and changed tasks while a deficient policy solves only the clean task, providing a constructive witness for that policy pair.This does not establish that arbitrary agents notice changes or that an instance measures only one latent capability.Source: S1.2 Four-layer certification in the… · p. 72
S1.3 Trajectory diagnosis and reward in the exploratory corpus
- Trajectory checkpoints track acquisition through terminal state, while failure signatures distinguish missed changes from recognized discrepancies followed by forbidden repairs.Dense reward is diagnostic rather than proof of full correctness; the primary stale-world experiments retain state-based success invariants and do not inherit the supplementary corpus’s dense scores or inferential sampling scheme.Source: S1.3 Trajectory diagnosis and reward… · p. 72
S1.4 Exploratory environments, variants and certified outcomes
- 17 variants were handled successfully in 53/55 rollouts, while the remaining nine difficult-family variants succeeded in 3/23 rollouts.Across 32 variants and 93 rollouts, these exploratory results are descriptive, not prospective stale-world results; the difficult families were selected from observed failures.Source: Table 42 · p. 72, S1.4 Exploratory environments,… · pp. 72–73
S1.6 Why perturbation certification alone does not establish prior-value exposure
- Certification found five nondiscriminative instances, six checker false-negatives, and early clinic episodes contaminated by a mail store; these are observed construction defects, not estimates of future-defect sensitivity.Archived rollouts were rescored after checker revisions, and supplementary rates concern injected changes that do not necessarily establish prior exposure to the superseded value.Source: S1.4 Exploratory environments,… · p. 73, S1.6 Why perturbation certification… · p. 73
S1.5 Ghost Commit: a detection–recovery distinction
- 7/7 pre-commitment clinic rollouts recovered successfully, versus 0/3 post-commitment rollouts, despite the agent detecting the altered value in all compared rollouts.The post-commitment agent attempted a prohibited repair despite an allowed reporting route; the comparison is descriptive because each timing arm is one frozen variant.Source: S1.5 Ghost Commit: a… · p. 73
S2.2 The execution loop
- The event trace separates evidence that the old value was served from proof it reached the policy, and records authoritative state transitions independently of screenshots.The harness captures delivered frames and application events; the application-side request handler performs the mutation before serving the triggered response, rather than injecting a changed value into the prompt.Source: S2.1 An event-level trace and its… · pp. 73–74, Table 43 · p. 74, S2.2 The execution loop · p. 74
Related papers
This paper cites
- OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments2024
- $τ$-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains2024
- Gaia2: Benchmarking LLM Agents on Dynamic and Asynchronous Environments2026
- OpenComputer: Verifiable Software Worlds for Computer-Use Agents2026
- Beyond Static Leaderboards: Predictive Validity for the Evaluation of LLM Agents2026