# Experiment protocol: <name>

This is an optional advanced template for confirmatory work. Initial exploratory
runs can use a short setup note, retained observations and a record of changes.
Decimal interfaces and exact replay are not universal admission requirements.

Status: draft / frozen exploratory / frozen confirmatory / completed / superseded.
Protocol version and hash: <record before execution>.
Code revision and any uncommitted patch: <record exact content>.
Related prior runs and amendments: <links, including unfavorable results>.

## 1. Question and competing explanations

- One operational question:
- Hypothesis:
- Alternative explanation and a control that can distinguish it:
- A favorable result would support:
- An unfavorable result would teach us:
- Results this experiment cannot establish:

Distinguish an observed behavior, an advantage over a comparison, a learned
policy, and a claim about cognition. They need different evidence.

## 2. Mathematical contract and information access

Write the participating Gojo shape before naming its helper. Connect inputs,
units/bases, resolution, operation, result, unresolved state and provenance.
For action, identify the transfer or response and its settlement route.

| Participant or host component | Available inputs | Allowed decisions/actions | Unavailable information |
| --- | --- | --- | --- |
| <fill> | <fill> | <fill> | <fill> |

- Existing kernel mechanisms and conformance tests:
- Selected model families, gains, thresholds, goal conditions and tie rules:
- Authored policies versus mechanisms actually being learned:
- Unsupported operations and the unresolved result they must retain:
- Numeric range, rounding/resolution law and conservation conditions:
- Dependencies shared by observations; what remains unknown about dependence:

## 3. Numeric boundary

- Participant source files, generated code and transitive dependencies:
- Reviewed integer/rational readers and their structural derivations:
- Input measurement/quantization contracts:
- Calls requiring separate review, including dynamic/native paths:
- Guard version and deliberately contaminated cases it rejects:
- Reference/evaluation/plotting dependencies, and proof they do not feed actions:

No passing guard substitutes for checking whether the algorithm's decisions
actually come from the declared structure and policies.

## 4. Cases, controls and resource limits

- Complete finite case list or generation rule:
- Development cases, held-out cases, and what has already been inspected:
- Candidate space and all parameter combinations to be tried:
- Random generator/version/state and preserved draws, if applicable:
- Independent experimental unit and number of repeats:
- Matched exact conventional implementation:
- Additional representation-rich baseline, if needed:
- Removal/disabled/no-response control:
- Perturbation, unreachable-target or misleading-evidence cases:
- Budgets for local actions, messages, search, memory and elapsed time:
- How unequal costs or information access will be reported:

## 5. Event order and termination

- Setup and attachment order, including any setup settlement:
- Clock meanings and event/arrival correspondence:
- Capture/publication, delivery, planning and application sequence:
- Which changes are sequential or simultaneous, and how this is implemented:
- Fairness, conflict, duplicate and stale-message rules:
- Declared variants in delivery, identity/construction order or delay:
- State included in quiet/repeat checks and what those checks do not cover:
- Distinct reasons for stopping: goal met, quiet with residue, cycle evidenced,
  step/pass limit, missing input, numeric failure or host failure:

A scalar plateau or a returned kernel call is not automatically convergence.

## 6. Measurements fixed before evaluation

| Measure | Exact definition and units | Capture times | Independent check | Missing/unresolved policy |
| --- | --- | --- | --- | --- |
| <fill> | <fill> | <fill> | <fill> | <fill> |

- Primary comparison and a meaningful effect size, if applicable:
- Secondary/exploratory measures:
- Signed mismatch versus nonnegative loss:
- Reporting of coverage, resource cost and invalid cases:
- Aggregation, uncertainty estimates and multiple-comparison policy:
- Exclusions and stopping/sample-size rule fixed in advance:

The evaluator may observe the whole archived state when the question permits;
that does not grant the participant the same information.

## 7. Run bundle and apparatus validation

- Runtime, SDK, dependency versions and environment:
- Ordered Gojo roots and exact initial graph bytes/hash:
- Host/environment state, pending queues and immutable input/event tape:
- Checkpoints and action/read witnesses to retain:
- Final state, all attempted actions, stop evidence and complete outcome ledger:
- Fresh-process checkpoint replay check:
- Deliberately invalid evidence that is refused:
- Observation-without-mutation and diagnostic-order checks:
- Independent metric checks on small hand/exhaustively evaluated cases:

Keep an exact experiment archive even if the participant is deliberately
forgetting or compressing its own memory.

## 8. Amendments and final interpretation

Before an amendment, retain the previous protocol, failing or unresolved case,
and run evidence. Record whether the cause was a defect, missing operation,
chosen policy, bad premise or a valid negative outcome. Justify a kernel law
independently; do not patch a trial to obtain the desired answer.

- What changed, why, and new protocol/code hashes:
- Which earlier results can no longer answer the revised question:
- New unused evaluation cases:
- Complete results, including negative, inconclusive and invalid runs:
- Supported claim and strongest remaining alternative explanation:
- New hypotheses suggested by these results, reserved for future evaluation: