Simulation & System Improvement
Evidence-governed loops from failure to transfer
00 / ABSTRACT
Improvement is a comparison, not a feeling of progress.
We study how a system can improve through controlled interaction with a simulated environment. The object of improvement may be an agent, a workflow, a tool policy or a collaborative process. The central unit is a versioned experiment: a reproducible failure, a falsifiable hypothesis, a bounded intervention and an evaluation that is not rewritten to favor the candidate.
This working paper generalizes methodological lessons from the lab’s private AlphaSim work and the Agent Foundry development workflow. It separates environment validity, evaluator validity, local repair, held-out transfer and deployment authority. It introduces a proposed protocol and synthetic illustrations, not a new empirical benchmark or a claim that any system can improve autonomously.
Contributions of this edition
- A contract separating the system, simulated world, evaluator and exposure history.
- A bounded improvement loop with retain, reject, acquire-evidence and stop outcomes.
- A transfer protocol that keeps offline evidence distinct from real-world qualification.
- 01
Reproduce the issue on a fixed parent.
- 02
Name a cause and a discriminating test.
- 03
Modify one declared behavior axis.
- 04
Check target, regression and transfer.
- 05
Retain, reject, acquire evidence or stop.
01 / PROBLEM
A simulator can reward the wrong behavior.
An apparent failure may belong to the agent, a missing world fact, an invalid scenario, an evaluator or an observation gap. If the system is changed before that distinction is made, it can learn to satisfy a broken test instead of solving the user’s problem.
Likewise, completing every case is an execution result, not a quality result. Passing known regressions means selected behaviors were preserved; it does not establish that an unobserved task will succeed. Closing an experiment may mean rejecting its hypothesis. These outcomes need separate names.
02 / HYPOTHESIS
Small causal changes can accumulate transferable value.
The hypothesis is conditional on sufficient world fidelity and a useful evaluator. When the environment cannot supply the required evidence, the right next action may be to improve observation or scenario quality in a separate experiment, not to edit the agent again.
03 / EXPERIMENTAL CONTRACT
Freeze what gives the comparison meaning.
| Element | Recorded boundary |
|---|---|
| System A | Source, configuration, model versions, tools and permitted effects. |
| World W | Scenario version, reachable facts, transitions, initial state and seed where applicable. |
| Evaluator E | Criteria, rubric, calibration evidence, thresholds and unknown conditions. |
| Data D | Case and family identity, role, exposure history and holdout boundaries. |
| Budget B | All generation, evaluation, retries, cost, time and human interventions. |
| Receipt R | Exact parent/candidate identities, observations, failures, decision and unresolved limitations. |
The candidate receives only the information available to the acting system. Evaluation-only answers and hidden future state must not enter its runtime input. Case families and connected entities are partitioned together when row-level splitting would leak the same underlying situation. A hash proves identity, not the truth of the data.
04 / MODEL
Compare the same tasks with the same measuring instrument.
ΔQ = (1 / n) Σᵢ [q(A′, Wᵢ, E) − q(A, Wᵢ, E)](1)For a binary acceptance criterion, q is 1 only when required conditions are verified. Unknowns remain a separately reported population; a conservative accepted/all-assigned rate does not imply that every unknown is a known semantic failure. Report both acceptance and evidence coverage.
Resample at the independent task-family level, not automatically at the row or execution-batch level. Report uncertainty, effect size and total cost. Repeatedly inspecting a holdout turns it into selection feedback; maintain exposure history and reserve a genuinely unopened final evaluation.
The score increased. Did the system improve?
Three hypothetical comparisons. The numbers are invented to explain the logic: these are not AlphaSim results and no model is run.
None of these examples authorizes deployment. Unknown remains unknown.
05 / IMPROVEMENT PROTOCOL
One question, one change, one recorded decision.
- Prepare the product contract, scenario/world boundaries and available labels. Do not manufacture new ground truth just to remove a missing field.
- Validate evaluator behavior on controlled correct, incorrect and insufficient-evidence examples before interpreting its scores.
- Run a fixed baseline and reproduce the target failure on the parent candidate.
- Name the first supported causal failure, its owner, a discriminating contrast and a neighboring behavior that should not change.
- Make the smallest coherent intervention. Keep changes to the agent, world and evaluator in separate comparisons.
- Evaluate targeted cases, negative controls, full required regressions and the declared transfer set under the bound identity.
- Record retain, reject, acquire-evidence or stop. Preserve failed candidates and useful stepping stones as evidence.
- At a complete checkpoint, freeze the candidate before validation and final holdout. Deployment remains a separate decision.
A stopped or inconclusive experiment is a legitimate outcome. Reserve enough resources to finish the required checkpoint before opening another batch. Retry transport failures within a bound; do not keep retrying a valid but incorrect answer until a lucky pass appears.
06 / EVALUATOR VALIDITY
The judge is part of the experiment too.
A semantic judge may help assess answers that executable assertions cannot fully cover. It needs its own validation, including false acceptance, ambiguity and policy-sensitive examples. A different prompt or role does not automatically make it statistically independent. Ragas provides useful methods for examining retrieval and generated answers; diagnostic dimensions are not interchangeable with product acceptance.
A missing source is different from an unsupported claim. A refusal may be correct under one scenario and a failure under another. Validity therefore depends on the intended task, available facts, permissible action and expected outcome being mutually consistent.
07 / TRANSFER & SCOPE
A tested world is not the world.
| Layer | What it supports | What remains open |
|---|---|---|
| Mechanics | The experiment and state transitions execute as specified. | Whether scenarios and labels represent the task. |
| Local repair | A specific reproduced failure is corrected without required regressions. | Transfer to unseen task families. |
| Held-out evaluation | Performance on a declared unseen distribution and budget. | Distribution shift and unmodeled real effects. |
| Real-environment qualification | A separately authorized, bounded deployment scenario. | Unbounded future reliability or universal autonomy. |
Start with replay and simulated tools, where side effects are controlled. Add realistic failures, delayed information, partial observations and recovery windows only when relevant to the product. Use a separate shadow or limited live protocol for sim-to-real transfer; passing a simulator must never itself grant execution authority.
08 / APPLICATIONS
The protocol transfers; the definition of value does not.
For a business agent, evaluate whether a permitted workflow reached its agreed outcome with supported facts. For a game, combine playable correctness with a clearly defined playtest question. For a musical system, keep listener preference, artistic intention and rights separate from raw engagement. For a shared spatial world, test object state, coordination, comfort and recoverability.
These are candidate application areas. They do not establish that one reward function, universal simulator or evaluator is adequate across domains. A second real consumer should test reusable boundaries before a shared framework is treated as proven.
10 / EVIDENCE SCOPE
A public method, informed by private work.
AlphaSim and the associated Agent Foundry work provide internal examples of versioned preparation, evaluator/simulator setup, bounded improvements and separate release gates. This publication abstracts that discipline without releasing project datasets, customer context or traces.
No fresh experiment is reported here. The interactive cases are deliberately synthetic. Historical completed runs and closed improvement items are not presented as accuracy or a count of successful improvements. The proposed generality beyond the motivating applications remains untested.
11 / NEXT EXPERIMENT
Test the improvement process itself.
Choose two independently specified task families with adequate labels. Compare a fixed baseline, bounded unstructured iteration and the proposed evidence-governed loop at matched total budgets. Freeze the environment and evaluator, randomize run order and blind final grading to the development condition.
Report held-out acceptance, false acceptance, regressions, evidence coverage, total cost and human repair. Preserve all assigned cases and declared exclusions. Publish de-identified task definitions and executable checks where rights permit; otherwise limit the claim to the available evidence.
12 / LIMITATIONS
A loop can systematically amplify a mistake.
- World fidelity, ground-truth quality and evaluator coverage can bound what improvement is knowable.
- Adaptive reuse of evaluation data can overfit the process even when each patch is small.
- Agent, world and judge errors may be correlated.
- A single declared change axis still requires substantive causal review.
- Cost, latency, privacy and safety cannot be hidden by an averaged quality score.
- No universal self-improvement, guaranteed monotonic progress or real-world reliability is established.
SOURCES
References & intellectual context
These works provide intellectual context and comparison methods. Their results are not experimental evidence for IO Lab’s hypotheses.
- Yan, H. et al.Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement 2026 · arXiv preprint
- Es, S., James, J., Espinosa-Anke, L. & Schockaert, S.Ragas: Automated Evaluation of Retrieval Augmented Generation 2023; revised 2025 · arXiv preprint
- Shinn, N. et al.Reflexion: Language Agents with Verbal Reinforcement Learning 2023 · arXiv preprint
CITE THIS WORK
Citation & edition
Version 0.1 introduces the simulation program and a proposed evaluation protocol. The illustrative comparison contains no experimental measurements. This working paper is not peer reviewed.
IO Lab. “Simulation and System Improvement: Evidence-Governed Loops from Failure to Transfer.” IO Lab Working Paper 004, version 0.1, September 8, 2026. https://io-lab.nglain.com/works/simulation-system-improvement
BibTeX
@techreport{iolab2026simulation,
author = {{IO Lab}},
title = {Simulation and System Improvement: Evidence-Governed Loops from Failure to Transfer},
institution = {IO Lab},
type = {Working Paper},
number = {004},
year = {2026},
month = {September},
note = {Version 0.1; not peer reviewed},
url = {https://io-lab.nglain.com/works/simulation-system-improvement}
}Availability: the full text of this edition is public. The internal repository, raw traces and datasets are not published. No DOI has been assigned.