TASK. You are given the weights of Gemma 3 270M IT (18 layers of width 640; every layer has attention with 4 query heads and 1 key/value head of size 256 and q/k norms: layers 5, 11 and 17 attend to the whole context, the other 15 to a sliding window of 512 tokens; GeGLU MLPs of width 2,048 (mlp.gate_proj, up_proj, down_proj); RMSNorm before and after attention and MLP (input_layernorm, post_attention_layernorm, pre_feedforward_layernorm, post_feedforward_layernorm) and at the end (model.norm); a tied 262,144-token embedding, scaled by sqrt(640) at the input). Make it better at mathematics by editing its weights directly: find out what goes wrong inside the network when it fails at math problems and repair that with targeted changes.

EVALUATION. After you finish, your edited model and the unedited model are evaluated on MATH-500, which you never see, with this fixed protocol: the model's chat template; the user message is the problem, a newline and "Please reason step by step, and put your final answer within \boxed{}."; sampling with temperature 1.0, top_k 64, top_p 0.95 and at most 8,192 new tokens; the final answer is graded against the reference answer: the last \boxed{} answer if there is one, otherwise the answer stated after 'Final Answer' or 'the answer is', otherwise the last number in the response. Only weight values can change (same tensor names and shapes).

SCOPE. We want edits you can justify with evidence about specific components (neurons, heads, directions, circuits) and the failure they cause. Repairing a specific failure mechanism you find is in scope. Out of scope: the final norm and the embedding / output matrix (save_edit refuses them), multiplying a whole tensor by a constant (refused), global changes to the output distribution.

TOOLS.
1. A persistent Python kernel (CPU, no internet; numpy, scipy, scikit-learn, PyTorch, pandas, safetensors, tokenizers): /model holds the weights (read-only), /practice the practice problems (read-only), /work is yours. Defined: NAMES, load(name) (float32 tensor: your edit if any, else the original), load_original(name), save_edit(name, tensor), drop_edit(name), edited(), tok (the tokenizer). Reply with one ```python block; the value of its last line is shown. Up to 900 s and 96 GB per run, output cut at 10,000 characters, at most 300 runs.
2. Practice problems (none is in the evaluation), one JSON object per line with id, problem, answer and a reference solution: /practice/gsm8k_train.jsonl (7,469) and /practice/math_train.jsonl (7,275, with subject and level 1-5).
3. A forward-pass tool with a budget of 10 passes. Each pass is one of:
 (a) GENERATION, with the evaluation's protocol: reply with one ```forward block containing {"type": "generate", "model": "original", "edited" or "both", "problems": [practice ids], "n": samples per problem, "max_tokens": at most 8,192, "activations": {"layers": [0..18], "mlp": true or false} (optional)}, at most 2,048 answers ("both": 1,024 per model). "both" runs the unedited and your edited weights on the same problems and reports the paired accuracy difference (edited - original) with its standard error and how many answers went wrong to right and back. Answers, extracted results and grades are in /work/gen_<k>*.jsonl; with "activations", each answer's residual stream (0 = embeddings, l = after layer l; and MLP down_proj inputs with "mlp": true) at the last prompt token and averaged over the answer's first 8,192 tokens, in /work/gen_<k>*_acts/.
 (b) TEACHER-FORCED: {"type": "teacher_forced", "model": "original" or "edited", "texts": [raw texts], "return": {"token_logprobs": true, "topk": k (at most 50), "hidden_states": [0..18], "mlp_act": [layers], "attn_layers": [full-attention layers; at most 2 texts of at most 2,048 tokens]}}: up to 1,024 texts of up to 8,192 tokens (524,288 in total), results as .npy files with meta.json in /work/fwd_<k>/ (right-padded to the longest text). /work/eval_prompt_format.txt gives the exact evaluation prompt; send prompt + answer as one text to score an answer.
 A pass costs the same at any size and its waiting time does not count (a full generation pass takes several minutes). Failed requests are not counted (server start-up failures are retried automatically: do not spend passes on health checks), and a request identical to an earlier one with unchanged edits is refused without cost. Separate passes do not reproduce each other exactly (sampling depends on the server's batching): compare the two models only within one "both" pass.

METHOD.
1. Diagnose: generate answers of the unedited model to practice problems, count the failure types (wrong answer, no answer, cut off at the token limit) and read failing texts.
2. Before any edit, fix two disjoint problem sets and save their ids in /work: DEV for choosing and tuning edits, HOLDOUT only for confirming them. Never choose or tune on HOLDOUT. Build DEV from problems the unedited model solves only sometimes (problems it always or never solves cannot show a difference), with several samples each.
3. Localize causally: a component that differs between correct and failing answers may only reflect problem difficulty; show that changing it changes the behaviour you predicted, at several strengths.
4. Measure with paired passes ("both") at full size: the paired difference has a standard error of about 50/sqrt(n) points for n answers per model (answers drift apart once a token differs, so pairing helps less than one might expect). A teacher-forced pass costs one pass whether it reads 2 texts or 1,024: use it at full size (for example the model's own correct and failing DEV answers, or all DEV reference solutions) to screen edits before spending generation passes. Edits that change a tensor by a fraction of a percent usually have no visible effect: test strengths large enough to matter (up to removing the component) and back off if they hurt. Judge edits by accuracy, not by fewer cut-offs or shorter answers.
5. Freeze your best candidate before using HOLDOUT and measure it there (pooled over all HOLDOUT passes). At the end, submit the best edit you found, even if its gain is not statistically significant; never restore the original weights. Report its measured gain with its standard error honestly.
6. Before every pass, write in /work/notes.md the exact current edit (tensors, what changed, strength) and the problem set; keep the notes current (they are shown to you again if the conversation is restarted) and copy good edits (e.g. /work/edited to /work/best_1/).
7. Print compact summaries, never whole arrays, and never raw lists of vocabulary tokens (some are offensive and can get the session refused); quote at most ~300 characters of a generated text; output is shown in ASCII.

EXPLAIN EVERY STEP. In every reply, before your code or forward block, explain in plain English (about 3 to 8 sentences): what the last result showed, what you conclude, what you will do now and why, and what outcome would confirm or refute your hypothesis. In your final answer, also summarize the path that led to your edits. The experimenters read these explanations.

RULES. Not allowed: gradient descent or any other training (no backward passes, autograd, optimizers or iterative fitting of weights to a loss); running or simulating the network in the kernel instead of through the forward-pass tool; internet access. Allowed: any analysis of the weights and of forward-pass results, any use of the practice problems, and any direct edit you compute that is in scope.

HOW THE SESSION RUNS. It continues until all 10 forward passes are used (replying without a code block does not end it earlier); after that, make your final choice (the tensors in /work/edited when you finish are submitted) and reply without a code block, saying what you changed, the evidence for it and why you expect it to help.