---
name: Arco dry-run standard
version: 1.5.1
status: active
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---




# Arco dry-run standard




## Purpose




This file defines how to perform a dry run when the System Manual requires validation before promotion.




A dry run tests proposed maintained-system behaviour before it becomes canonical. Its purpose is to detect regressions, ambiguous instructions, broken routing and unintended behaviour while there is still a safe opportunity to correct the draft.




Dry runs are evidence, not ceremony. Tests should exercise the responsibilities and risks of the proposed change rather than merely repeat wording from the file.




A dry run must verify that the maintained files actually produce the intended result when used. Structural correctness is not sufficient if a realistic user or AI request still produces the wrong, incomplete or ambiguous outcome.


## When a dry run is required


A Dry Run is required when a new maintained operating artefact is first promoted, or when a subsequent change could materially alter runtime behaviour, routing, authority, structure or interaction with another maintained component.


A Dry Run is not required solely for typographical corrections, metadata corrections, non-behavioural wording improvements or other changes that cannot reasonably alter system operation.


Where materiality is genuinely uncertain, prefer the smallest useful Dry Run rather than expanding validation into ceremony.




## Test design




Build a compact test set from the behaviour that must remain true after the change.




Use the test types that are relevant to the file or architecture being changed:




- **definition** — does an unfamiliar capable AI understand what the component is?
- **boundary** — can it distinguish the component from adjacent responsibilities?
- **routing** — does it select the intended next source without bypassing or duplicating pointers?
- **behaviour preservation** — does previously working behaviour still work?
- **negative** — does it avoid inventing authority, modules, schemas, paths or behaviour that are not established?
- **deployment** — does it distinguish Core, deployed and local state correctly?
- **ambiguity** — can plausible wording be misread in a materially incorrect way?
- **scenario** — can it apply the instructions correctly to realistic operating situations?
- **outcome / behavioural** — when an unfamiliar AI is given a realistic request, do the maintained files produce the result the system actually intends, with enough reasoning or action to be useful?




Prefer a small number of high-value tests over a large checklist of superficial ones.




When a change affects interpretation, routing, reasoning or user-visible behaviour, include at least one realistic outcome / behavioural test written as the kind of request a user or AI would actually make. The observed result must be evaluated for usefulness and correctness, not only for whether the file contains the expected wording.




## Test conditions




Unless a test specifically requires wider context, evaluate the proposed change as though an unfamiliar capable AI has only:




1. the proposed file or files required by the normal routing path; and
2. the test prompt.




Do not silently supply design intent that is absent from the maintained files. A test should fail if the desired interpretation depends on knowledge the files do not actually provide.




Where the change is intended to preserve existing behaviour, compare the proposed behaviour against the current canonical behaviour or a representative prior run.




## Expected behaviour




Each test must state the expected behaviour before recording the result.




The expected behaviour should identify the material outcome, not prescribe exact prose unless exact wording is itself operationally important.




Example:




```text
Prompt:
Where should a deployment-specific Skills Register ID live?




Expected:
The AI routes from the deployed Skills README to local Skills configuration and identifies the local file as the authoritative home for the deployment-specific ID. It must not put the ID in the AI guide.
```




## Running the dry run




For each test:




1. record the prompt;
2. record the expected behaviour or outcome;
3. run or simulate the prompt/action using only the maintained files available through the intended routing path;
4. record the actual answer, interpretation, action or outcome produced;
5. compare the observed result with the expected result;
6. mark `PASS` or `FAIL`;
7. explain material failures briefly.




A test passes only when the resulting behaviour is materially what was intended. Finding the right section, keyword or architectural relationship is not enough if the answer or action produced is still incomplete, misleading or unusable.




If a test fails:




1. treat the failure as evidence about the maintained system;
2. correct the proposed maintained file that owns the problem, following the System Manual's normal versioning, changelog, archive and verification rules where applicable;
3. do not patch the test or silently supply missing intent to make the draft appear correct;
4. rerun the failed test against the corrected file;
5. rerun any other tests materially affected by the correction;
6. preserve the initial failure, correction and rerun result in the dry-run evidence;
7. promote only when the final test set passes or an explicitly accepted exception is recorded.




This creates a closed validation loop:




```text
proposed maintained behaviour
        ↓
realistic test
        ↓
observed result
        ↓
compare with intended result
   ↙                 ↘
PASS                 GAP / FAIL
                       ↓
             update owning file
                       ↓
                    rerun
```




A dry run may expose a better architectural boundary. When that happens, change the owning system file rather than duplicating compensating instructions elsewhere.


If a Dry Run materially identifies a separate durable system proposal that cannot be resolved within the change currently being tested and is not already owned by an existing Development item, create or link to the next `DEV-###` record. The Dry Run evidence/Register continues to own the validation run; the DEV record owns the proposed system change. Do not create Development items for routine test observations or deterministic corrections already owned by the tested change.




If the dry run exposes a durable weakness in the validation method itself, update this dry-run standard through the same System Manual maintenance process. Do not leave a known improvement only as chat knowledge or an informal convention.




## Output record




Save each completed dry run under the deployment's Arco operating space:




```text
outputs/
└── dry-runs/
    └── dry-run-<target>-v<proposed-version>-YYYY-MM-DD.md
```




The output record is validation evidence, not a runtime source of truth. Runtime routing must not depend on dry-run files.




The record should contain:




- target file or change;
- proposed version;
- reason validation was required;
- test prompts;
- expected behaviour;
- observed answer, action or outcome;
- comparison with expected behaviour;
- PASS / FAIL result;
- initial failures where relevant;
- corrections made after failures;
- rerun result after each correction;
- final result.




Do not add dry-run outputs to the AI guide or normal runtime routing.




## Dry Run Register




Each deployment that uses Dry Runs must maintain a durable Dry Run Register alongside the evidence area:




```text
outputs/
└── dry-runs/
    ├── dry-run-register.csv
    └── dry-run-<target>-v<proposed-version>-YYYY-MM-DD.md
```




The Register owns the durable history of completed runs. Register storage follows the System Manual.




Each row must record at least:




- Dry Run ID;
- date;
- target or scope;
- versions tested;
- final result;
- accepted exceptions, if any;
- evidence file link while the file exists;
- evidence status.




Use a stable sequential identifier such as `DRY-001`. The Register owns the next identifier.




For a whole-system or multi-file run, `versions tested` must identify the material maintained files and versions used by the test. Do not rely on the evidence file as the only record of what was tested.




The detailed evidence file supports validation and debugging, but it is not necessarily permanent. A clean completed evidence file may later be removed by Defrag once the Register contains the durable run facts and no failure, accepted exception or unresolved investigation requires the detailed evidence. When evidence is removed, update the Register's evidence status; do not remove the Register row.




Dry Run failures and accepted exceptions should retain their detailed evidence while they remain operationally relevant. Deployment candidate workspaces follow the separate cleanup rule in the Deployment operating guide.




## Result standard




Use a concise final result such as:




```text
Final result: 12/12 PASS
```




A clean `PASS` means the current proposed version has been rerun after any corrections and now produces the intended material outcome.




If an exception is deliberately accepted, record the exception and approver explicitly rather than presenting the run as a clean pass.




## Boundaries




Dry runs validate maintained operating behaviour. They do not replace:




- human approval where the deployment requires it;
- release archives;
- changelogs;
- saved-file verification;
- production monitoring or evidence from real use.




Dry runs should remain lightweight enough to be used whenever they add confidence. They are a protection against accidental regression, not a new administrative layer.





## Canonical references

[arco-system-manual.md](https://drive.google.com/file/d/1doS7QXRtShzT45wHC13Vx0zxputK50l-/view).

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 1.5.1 | Restored canonical provider-link references. | Stoirm Arnold — Defrag invocation | Codex Work |
| 23-Sep-2026 | 1.5.0 | Added Dry Run → DEV handoff for separate durable system proposals while preserving Dry Run evidence as validation history rather than a competing Development tracker. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 22-Sep-2026 | 1.4.0 | Defined the Dry Run materiality threshold: first promotion and behaviour/routing/authority/structural changes require validation, while typographical, metadata and genuinely non-behavioural corrections do not. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 22-Sep-2026 | 1.3.0 | Added the durable Dry Run Register, required versions-tested history for multi-file runs, and made clean detailed evidence eligible for later Defrag cleanup once the durable run record is complete. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 18-Sep-2026 | 1.2.0 | Aligned filed dry-run evidence with the universal report filename standard by placing sortable `YYYY-MM-DD` at the end of the filename; retained the existing evidence-driven self-learning loop unchanged. | Stoirm Arnold | GPT-5.6 Sol |