# Wording and variable-name stability of a batch rule

Protocol date: 2026-10-11 KST. Status: planned; no model predictions or native
executions have been performed for this protocol at the time of its publication.

## Question

When the same batch rule is described in Korean, English or an English paraphrase,
does the model change its first candidate, number of attempted candidates or final
finite outcome? Do direct expressions and two equivalent local-variable forms
change those observations? This is a stability experiment on one rule family.

## Frozen inputs

- Compiler candidate source: `2e0e34f880baa2681ec48e22a5318e62739dcff9`,
  Go1.27.2, decision runtime0.2.39. The candidate source is awaiting its public PR.
- Existing released SDK0.2.39 ordered and interaction FP32 models. Their file
  hashes are in `plan.json`. No fitting, quantization, calibration or downloads.
- One rule: `min(max(pending, 0), 24)`. This cap and these source files are new to
  this observation. The initial body deliberately returns the larger value;
  declared choices permit swapping operands and branch layout (four combinations).
- Three wording variants times three source forms = nine presentations of one
  task. Stable IDs, choice order, source cases and condition cases stay fixed.
- Five authored output cases and two intermediate Boolean conditions per source.
- Two fixed native construction inputs and ten fixed caller evaluation inputs.
  The caller set overlaps construction observations after normalization; model
  training exposure is unknown. These are not ten unseen-task accuracy trials.

## Execution

Execute the 27 rows of `plan.json` in the listed order, once each. The three
policies rotate their position across presentations: deterministic ordering,
ordered model, interaction model. Use the same clean compiler executable for all
rows and record its digest and `version --build --json` before starting.

Each row invokes `body-construct --entry Main --source SOURCE
--construction-cases construction.json --cases evaluation.json --attempts 4
--out NEW_DIRECTORY`, adding `--model MODEL` for the two model policies.
Use the exact Go1.27.2 binary for native compilation. Run serially and preserve
each original stdout, stderr, exit status and whole-process timing. A row that
fails remains failed or unobserved; do not repair its source or rerun it inside
this study. Stop before execution if input/model/compiler identities disagree.
Do not mix a source change into this frozen cohort.

## Read the results

For each presentation and policy, retain first attempted mask and its finite
success, attempted-candidate count, selected mask, model calls and model/input
identities, declared output/condition counts, and native caller success/total.
Compare exported ranking scores and source-feature identities when available in
the ordinary receipt; absence remains unknown. A score is not a calibrated
success probability.

Report failed invocations, unsupported representations, incomplete searches and
missing fields separately. Equivalent-variable forms should produce equivalent
normalized ordered expressions; differing feature hashes require inspection,
not automatic attribution to natural-language understanding.

Retain whole-command wall time, user/system CPU time and peak RSS, plus the
compiler's reported prediction time when present. Summarize medians and ranges
with their denominators. This is one execution per pair with uncontrolled caches
and other host activity; no causal speedup, server throughput or instantaneous
host CPU utilization claim follows. Keep fit time and earlier experiments out.

Publish all 27 outcomes including failures, a source/plan manifest and a
read-only summary query. Do not describe 27 paired invocations as independent
business tasks. The next change should address an observed language or input
representation gap, rather than raising a success score by changing these cases.