---
name: Arco dry-run standard
version: 1.1.0
status: active
owner: Stoirm Arnold
last_updated: 15-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.

## 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 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>.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.

## 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.

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 15-Sep-2026 | 1.1.0 | Added outcome/behavioural validation and a closed self-updating loop: dry runs must test realistic results, compare observed outcomes with intent, feed material failures back into the owning maintained file, preserve corrections and reruns in evidence, and update the validation standard itself when real use exposes a durable weakness. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 1.0.0 | Established the universal Arco dry-run method for validating material maintained-system changes before promotion and preserving test evidence under the deployment outputs area. | Stoirm Arnold | GPT-5.6 Sol |