Minds · project notes

Download Markdown

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.

• 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

• 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: