Damp the code-versus-prose style contrast in writers in all layers at 0.11 percent
When
Recorded date: 2026-11-13
Ledger date only; exact weight-build/change timestamp is not recorded here. Not a live training event.
Exact tensor-change timestamp: unavailable.
Why change it?
The model can write a patch yet lose the task through wrong code or an edit string that does not match the file. Damping the model's code-versus-prose style subspace may reduce generic form's influence relative to task-specific details while preserving syntax and literal text. This is a code-mode hypothesis, not a correctness probe. The polarity is an adaptive choice: the unqueued positive 0.33-percent writer candidate lowered code log p by 0.0082 nat and thought log p by 0.0723 nat per sampled token, and changed one of two logged thought endings. This new entry reverses the algebraic sign. It is one third of the 0.33-percent writer dose…
Which part changed?
Damp the code-versus-prose style contrast in writers in all layers at 0.11 percent
The source describes adapter targets and mathematical changes. No before/after tensor comparison is available in this viewer.
How was it changed?
Computed directly by author-written code and packaged as a low-rank adapter over the frozen base; not gradient-trained. base: champion generation 0 Code: code/turn4/build_fidelity.py. Inputs: code/turn4/fidelity_calls.jsonl and fidelity_directions.pt; captured by fidelity_worker.py with the frozen g31 library in code/turn4/tools. No optimizer, trained-adapter direction, agent rollout or new server. Per task, sample at most 32 interior code-argument positions and 32 preceding thought positions, evenly spaced. Capture raw writer directions (post-attention output divided by its norm weight; raw MLP output), and normalized reader inputs (attention input norm of resid_pre; mlp_in). Normalize each position to unit length before averaging. For each layer and space,…
Did it improve?
null · Stage 1: +0.00 (b007) tasks against reference arms. Stage 2: not yet measured. Matched control, stage 2: not yet measured. Verdict: null.
Evaluation set: wsp31_screen_v1 · Batch: b007. Local screening and historical task scores are not competition scores unless explicitly identified in the source. Different evaluation sets cannot be compared as a gain.
Original evidence
Literal source excerpts follow. They may contain original predictions and superseded counts; use the measured-outcome summary and corrections above for the current result.
Hypothesis
The model can write a patch yet lose the task through wrong code or an edit string that does not match the file. Damping the model's code-versus-prose style subspace may reduce generic form's influence relative to task-specific details while preserving syntax and literal text. This is a code-mode hypothesis, not a correctness probe. The polarity is an adaptive choice: the unqueued positive 0.33-percent writer candidate lowered code log p by 0.0082 nat and thought log p by 0.0723 nat per sampled token, and changed one of two logged thought endings. This new entry reverses the algebraic sign. It is one third of the 0.33-percent writer dose that preserved code and format and improved thought likelihood. The 0.99-percent writer scout preserved format on its first task but lowered thought log p by 0.0725 nat/token, with maximum KL 5.13; it was declined before a full panel/control replay. The smaller dose tests whether the slight favorable move at 0.33 percent survives with less disturbance. It is not another positive dose of that failed pre-test. The same two check tasks are reused for dose selection, so they are not an independent performance test. The contrast cannot tell correct code from wrong code. The fit uses code inside old_string/new_string and prose in the preceding thought of the same exact call, with equal task weight. Unlike the earlier deep-rumination damping entry, this contrast is code arguments versus preceding prose, not deep versus early thought. This also differs from prior thought-close and early-commit entries: no thought-depth, close-token, solve-rate or edit-timing label enters the direction. PRIOR_E4B's patch-correctness probe was weak and failed to gain; this entry uses code form, not a predicted correctness label, at all 60 layers and a measured network-wide size. That difference does not establish efficacy.
Exact recipe
base: champion generation 0 Code: code/turn4/build_fidelity.py. Inputs: code/turn4/fidelity_calls.jsonl and fidelity_directions.pt; captured by fidelity_worker.py with the frozen g31 library in code/turn4/tools. No optimizer, trained-adapter direction, agent rollout or new server. Per task, sample at most 32 interior code-argument positions and 32 preceding thought positions, evenly spaced. Capture raw writer directions (post-attention output divided by its norm weight; raw MLP output), and normalized reader inputs (attention input norm of resid_pre; mlp_in). Normalize each position to unit length before averaging. For each layer and space, subtract thought mean from code mean and remove its projection on the normalized grand mean of the two classes. Take the top four right singular vectors of the six task differences; weight each projector by squared singular value divided by the leading squared singular value. SVD signs are fixed by the largest absolute coordinate. For writers, dW = -beta * V.T diag(w) V W on o_proj and down_proj (120 matrices). For readers, dW = -beta * W V.T diag(w) V on q/k/v/gate/up_proj (300 matrices). This entry uses writers. Use module-space directions; no inverse post-norm approximation enters the saved projector. Later RMS norms and nonlinear interactions remain part of the forward pre-test. Per-matrix relative Frobenius norms are equalized, then all factors scaled to target whole-network size 0.11 percent. Stored factors are bf16, rank 4, alpha 8. The entry contains only its change; generation 0 has no overlap to discuss. Control: same builder, layers, modules, rank, negative sign, spectral weights and per-matrix norm, using Gaussian orthonormal directions orthogonal to both the fitted subspace and common mean. Seed 314000 + 100*layer + space index. The readers used by the projector change with its direction; there is no separate learned gate. This tests whether code-specific directions beat an equally broad random change. Bf16 rounding can leave a small norm mismatch, reported below. Selection: stage-1 b001 exact per-call records only; six fit tasks and three check tasks separated by sha256(instance) modulo 4. Check tasks have remainder zero. Within each split, select shortest eligible edit_file calls under 7000 tokens, one per task. No outcome labels used. Stage 1 therefore remains design data; stage 2 is the first unseen-task test. Fit tasks: pypa__build-229; ross-rotordynamics__ross-177; urbandataanalytics__SwissKnife-12; jpadilla__pyjwt-847; line__line-bot-sdk-python-274; pytask-dev__pytask-200. Check pool: juju-solutions__charms.reactive-71; keis__base58-46; Nikoleta-v3__blackbook-36. The recorded pre-test identifies which of these was used. Code in an old_string/new_string is generated text, not an independently verified correct target. Literal escapes are kept as the model saw them. This sample is small and selected for short contexts. size: whole network 0.110000% over 120 matrices, largest matrix 0.281829% control size: whole network 0.110000% over 120 matrices, largest matrix 0.281717% Rank 4; median stable rank 1.0658. Largest relative per-matrix norm mismatch after bf16 storage: 0.1053 percent. Full measurements: size.json. Both official checker runs pass; their output is in edit_check.txt and ctrl_check.txt. Both arms rebuild byte for byte (adapter_config.json, adapter_model.safetensors and edit.json); rebuild_receipt.json and source_hashes.json pin the files. ### Pre-test: exact logged calls on CPU No GPU was available to this author: GPU 0 held a screening batch, GPU 1 was not used. We used the documented g31 forward pass with device='cpu', mirror=True, 16 threads and dense-weight caching, on exact stored prefixes. This CPU backend is **NOT VERIFIED against an edited served model**. The GPU version's agreement is documented in TOOLS.md; baseline CPU-to-logged-server agreement measured here is 99.36% at 622 sampled tokens, mean absolute logged-token log-prob error 0.004749 nat. Agreement on the unedited model does not establish edited serving agreement. Two check tasks, excluded from fitting: juju-solutions__charms.reactive-71 and keis__base58-46. Teacher-forced replay only: no whole-turn generation, no sandbox task outcome. Interior argument tokens are a mix of old_string and new_string. Recorded edits on these two calls succeeded (one exact, one through the harness's unescape fallback); that fact was checked after selecting the calls, not used to fit directions. The code/prose contrast also includes a failed edit among fit calls and therefore is not a correct/incorrect-code direction. | arm / positions | n | mean change in logged-token log p | mean KL(base to arm) | max KL | top token unchanged | |---|---:|---:|---:|---:|---:| | edit / code | 57 | +0.000568 | 0.000134 | 0.004345 | 100.00% | | edit / thought | 59 | +0.007455 | 0.005112 | 0.050210 | 98.31% | | edit / turn | 2 | +0.009368 | 0.002278 | 0.004435 | 100.00% | | edit / think | 2 | +0.000080 | 0.000028 | 0.000051 | 100.00% | | edit / tool | 2 | +0.001082 | 0.000163 | 0.000326 | 100.00% | | edit / close | 2 | +0.094775 | 0.015268 | 0.030340 | 100.00% | | edit / cont | 8 | +0.003242 | 0.006122 | 0.043805 | 100.00% | | edit / all | 132 | +0.005370 | 0.002983 | 0.050210 | 99.24% | | ctrl / code | 57 | +0.000919 | 0.000140 | 0.005071 | 100.00% | | ctrl / thought | 59 | -0.002223 | 0.000741 | 0.017142 | 98.31% | | ctrl / turn | 2 | -0.009420 | 0.001607 | 0.003185 | 100.00% | | ctrl / think | 2 | +0.000020 | 0.000007 | 0.000014 | 100.00% | | ctrl / tool | 2 | +0.000594 | 0.000105 | 0.000210 | 100.00% | | ctrl / close | 2 | -0.000119 | 0.000009 | 0.000011 | 100.00% | | ctrl / cont | 8 | -0.000642 | 0.000134 | 0.000818 | 100.00% | | ctrl / all | 132 | -0.000771 | 0.000426 | 0.017142 | 99.24% | Fit diagnostics (six tasks, no solve labels): - attn_write: top four directions retain 91.20% of task-contrast squared energy on average over layers; mean split-half direction cosine 0.6960. - mlp_write: top four directions retain 88.93% of task-contrast squared energy on average over layers; mean split-half direction cosine 0.6335. Per-matrix signed projector coefficient beta (from the stored B factors): min -0.152758, median -0.075433, max -0.023925. The leading raw-output mode has gain 1 + beta; 0 matrices cross zero and invert that mode. Where this happens, the edit is stronger subtraction beyond simple damping. Bf16 factor rounding and downstream RMS norms still apply. Thought likelihood change above matched control: +0.009678 nat per sampled token. Code likelihood change above matched control: -0.000351 nat per sampled token. These are small, selected development probes, not evidence of tasks gained or of reduced string-match errors. The pre-test cannot measure wrong nonempty patches, long-context drift, total thought length or free-generation syntax. READY means checked and queued, not proven useful. Audit motivation: b001 has 700 edit_file calls, 541 captured status=ok responses, 49 captured status=error responses, and 110 without a captured response; 34 errors mention string matching. The first loose text scan also matched source-code strings, so only parsed tool status counts are used (code/turn4/edit_error_audit.json). Two failure examples: Mimino666__langdetect.a1598f1a.lm_rewrite__dk9wx21q (base call 19) and PyCQA__flake8.cf1542ce.lm_rewrite__yh5du3ns (base call 14): old_string not found. These observations motivate the experiment; they do not identify the cause of every wrong patch. Edit weights SHA256: 1bcbe8e5d954c0cb0d070869b274b5002144063a1af29f77d5907d14d1414e7f Control weights SHA256: ef10e0bb4fbe314f79ab1c2fcd13c11a8f318e447d8a8da5fd36cff09eac0fad Runner facts (2026-11-13 08:33:53 EST): source `wsp31/authors/gpt/queue/code-writer-damp-r4-011/`; served copy `wsp31/queue/frozen/gpt__code-writer-damp-r4-011/`; sha256 over files, edit `0deff4fbe60d77a7ea3426572e8af56f415bde1493a58baa0e5977f3b4fc36bb`, control `739da76bfd391c1c45a0cc74a8a4ed0b1e79a8b46c0a37f31660a2dd4475418e`; both passed the checker.
Prediction (written before the run)
predicted_gain_120: -5 to 10 In rollouts, edit_file string-match failures per edit call should fall by 10 to 25 percent relative; sampled code-token NLL should not worsen by more than 0.01 nat per token, and thought-token NLL should improve by 0.003 to 0.02 nat per token more than the matched control. This replaces the initial positive-candidate likelihood prediction before this reversed candidate is tested: the two selected code samples already have near-zero NLL, so a 0.02-nat improvement was mathematically out of reach. The behavioral hypothesis is that weaker prose/code separation lets thought retain code-specific detail; code likelihood here is a preservation check. Median first-edit call and thought tokens per call should remain within 10 percent of the reference. A gain should come from fewer wrong nonempty patches, not just fewer empty patches. These are hypotheses; the current contrast alone cannot prove any of them. Control: no consistent code-specific improvement; stage-1 gain expected between -5 and +5 tasks, though broad random changes can harm. Refutation: code log p falls by more than 0.01 nat per token, or thought likelihood does not improve beyond control; string-match failures do not fall; or they fall but solved tasks do not rise. More confident wrong code, changed tool format, or an increase in premature edits would reject the proposed mechanism. A task gain without the predicted mechanism is a different finding, not confirmation of this explanation.
Result
**Stage 1** (batch `b007`, 4 arms on one server, concurrency 4 per arm, finished 2026-11-13 22:51:39 EST; `results/wsp31/batches/b007/`). Reference arm: unedited. - unedited: solved 65 of 120, agent errors 47, at session limit 27, at tool-call cap 11, empty patch 23, median tool calls 17.0, mean 347.4 s, median 21.1 completion tokens/s of model time. - edit: solved 69 of 120, agent errors 47, at session limit 28, at tool-call cap 10, empty patch 23, median tool calls 18.0, mean 341.2 s, median 20.3 completion tokens/s of model time; vs base on 120 common tasks: +4.0 tasks (95% interval -4.0 to +12.0), base-only 6, arm-only 10, exact p 0.4545. - second unedited arm (identical weights): solved 73 against 65; 4 tasks solved only by the first, 12 only by the second (16 tasks differ; record 0003 measured 11.3 per identical pair); median 20.5 completion tokens/s. The gain used by the rule is against the mean of the two reference arms per task. - edit against the mean of the two reference arms: +0.0 tasks of 120 (95% interval -7.0 to +7.0). - Predicted gain -5 to +10; measured +0.0: inside the interval.
Verdict and notes
null by the fixed rule: stage-1 gain +0.0, bar +3, harmful at -6 or below.