George Auto Research

Idea workflow

ResearchProcessing
Discovery and triageNo active card
RepositoryWatching
Repository analysisNo active card
Repository 2Processing
Repository analysisNo active card
ScienceWaiting
Scientific reviewNo active card
ImplementationAttention
Implementation blocked
FailureProcessing
Failure investigationSince 02:24 UTC
Training runNo eligible training actiontraining code raised an exception
Critical alertERRORtraining code raised an exception
Queues
40 review5 build0 test1 scale

Discovered / inbox

New ideas and monitored discoveries

0

No cards here.

Review

Evidence and scientific triage

40

Upper-layer Q/K warmup damping

P11Score 0.59needs reviewFailure processing

Temporarily reduce the learning-rate multiplier only for Q/K projections in the upper transformer layers during the first 100 warmup steps, then restore the matched baseline multiplier; this may improve 3k-step decoder pretraining sample...

Evidence

The local Titan snapshot can support the proposed fixed 100-step upper-layer Q/K LR damping mostly through existing config machinery: lr_scale_regex_initial, lr_scale_regex_initial_steps, and LRScaledSchedulersContainer. The smallest saf...

LOCAL completed
Recovery next

Recover the missing run evidence before retrying or changing experiment semantics: verify whether /persistent/.local/state/george-auto-research/logs/experiment_qk_warmup_control_0722_r1/training.log was never created, deleted, written to...

View details
Idea details

Upper-layer Q/K warmup damping

Lifecycleneeds review
PriorityP11
Score0.59
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Experiment

LOCAL completed

Recovery next

Recover the missing run evidence before retrying or changing experiment semantics: verify whether /persistent/.local/state/george-auto-research/logs/experiment_qk_warmup_control_0722_r1/training.log was never created, deleted, written to another location, or hidden by a mount/path issue; collect sanitized scheduler/process exit evidence for experiment_qk_warmup_control_0722_r1; then fix the log capture or artifact path so the next run produces the expected training.log.

Evidence, sources, and controls
Hypothesis

Temporarily reduce the learning-rate multiplier only for Q/K projections in the upper transformer layers during the first 100 warmup steps, then restore the matched baseline multiplier; this may improve 3k-step decoder pretraining sample efficiency by delaying premature upper-layer attention specialization while preserving architecture, data, objective, and the final optimizer state.

Evidence

The local Titan snapshot can support the proposed fixed 100-step upper-layer Q/K LR damping mostly through existing config machinery: lr_scale_regex_initial, lr_scale_regex_initial_steps, and LRScaledSchedulersContainer. The smallest safe path is to generate a downstream candidate from scripts/runs/tiny.yaml, keep the matched control unchanged, damp only selected upper-layer attention.wq/wk weights by 0.25 for steps 1-100, then restore the normal multiplier. The only unresolved local scientific choice is the odd-depth upper-layer boundary for the 9-layer tiny override.

Current evidence
  • internal repository analysisTitan repository analysis: Upper-layer Q/K warmup damping

    The local Titan snapshot can support the proposed fixed 100-step upper-layer Q/K LR damping mostly through existing config machinery: lr_scale_regex_initial, lr_scale_regex_initial_steps, and LRScaledSchedulersContainer. The smallest saf...

  • arxivLearning Less Is More: Premature Upper-Layer Attention Specialization Hurts Language Model Pretraining

    A causal-decoder block is hierarchical: lower layers build the residual basis that upper layers attend over. We identify a failure mode in GPT pretraining: upper layers commit to sharp attention patterns before lower-layer features stabi...

  • manualUpper-layer Q/K warmup damping
  • internal implementation failureImplementation failure: Upper-layer Q/K warmup damping

    Implementation audit requested repair: Trusted host verification is not clean for the current diff: `host_verification.verified` is false, `static_checks` failed after formatting reordered `upper_qk_lr_damping` in YAML files, and the tou...

2 earlier records are available in the full idea history.

Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
14048b8a98717d7037a6733b093ababc8560dc8f
Branch
auto-research/qk-warmup-manual-recovery
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/implementation/action_11f7627f44ae4395
Configuration
/persistent/.local/state/george-auto-research/worktrees/implementation/action_11f7627f44ae4395/scripts/runs/auto_research_qk_warmup_control.yaml
Config SHA-256 (recorded, unverified)
3fd647964bd228ba51129e2b77fb26fa240c1da678d9c855a4053fd334a947ef
Actual config SHA-256
3fd647964bd228ba51129e2b77fb26fa240c1da678d9c855a4053fd334a947ef
Resolved config SHA-256 (recorded, unverified)
3fd647964bd228ba51129e2b77fb26fa240c1da678d9c855a4053fd334a947ef

No training launch command was recorded. The provenance above identifies the exact revision and configuration evidence that is available.

Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

PP3 router-EMA lifecycle correctness

P10Score 0.49needs review

Fix pipeline-parallel MoE router EMA updates so only retained registered MoE layers are updated after splitting, and cache references match the live post-parallelization parameters. The repair must preserve PP1 behavior and enable the ma...

Evidence

Feasible as a local code repair: pipeline splitting currently prunes registered layers but leaves TransformerMoE._moe_layers stale, while EMA reference caching walks only live registered routers after parallelization. The smallest fix is...

View details
Idea details

PP3 router-EMA lifecycle correctness

Lifecycleneeds review
PriorityP10
Score0.49
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Fix pipeline-parallel MoE router EMA updates so only retained registered MoE layers are updated after splitting, and cache references match the live post-parallelization parameters. The repair must preserve PP1 behavior and enable the matched PP3/DP2 3k control and candidate runs; reject it if the exact PP3 control still asserts or if it changes non-PP router EMA behavior.

Evidence

Feasible as a local code repair: pipeline splitting currently prunes registered layers but leaves TransformerMoE._moe_layers stale, while EMA reference caching walks only live registered routers after parallelization. The smallest fix is to refresh the MoE layer cache on each PP stage chunk after pruning, so update_ema and running stats visit only retained registered layers and cached references match post-parallelization parameters. No scientific choice is missing for the 1B implementation. The exact 17B PP3/DP2 8-GPU request is not feasible from this snapshot because the baseline is MTP-wrapped, MTP has no pipelining registry, and PP3*DP2 cannot exactly fit eight ranks.

Current evidence
  • internal repository analysisTitan repository analysis: PP3 router-EMA lifecycle correctness

    Feasible as a local code repair: pipeline splitting currently prunes registered layers but leaves TransformerMoE._moe_layers stale, while EMA reference caching walks only live registered routers after parallelization. The smallest fix is...

  • manualPP3 router-EMA lifecycle correctness
  • internal implementation failureImplementation failure: PP3 router-EMA lifecycle correctness

    Implementation audit requested repair: Trusted check static_checks failed: aseline_17b_moe.yaml @@ -205,8 +205,8 @@ model: norm_type: torch_rmsnorm overlapped_all_to_all_overprovision_factor: 0 partial_rotary_factor:...

1 earlier records are available in the full idea history.

Peri-LN output RMSNorm

P10Score 0.49needs reviewEarlier smoke passed; retest pending

Add one learnable RMSNorm to the complete output of every attention branch after output projection and gating, and to every dense, routed-expert, and shared-expert MLP branch after its down projection, immediately before each branch is a...

Evidence

Local 1B implementation is feasible with a small architecture flag and focused tests. The supplied historical commit 9f13144d implements a different residual-norm switch: it reuses existing input norms on sublayer outputs and can remove ...

LOCAL completed
100.0%3000 / 3000 (100.0%)Training loss 1.85 at step 3000W&B poolside/Autoresearch
View details
Idea details

Peri-LN output RMSNorm

Lifecycleneeds review
PriorityP10
Score0.49
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Experiment

LOCAL completed

100.0%3000 / 3000 (100.0%)Training loss 1.85 at step 3000
Matched baseline

local-dp4-control_85523afd66e8d6205654

Test history

An earlier implementation passed its distributed smoke. The corrected build must finish and pass a new smoke before this card returns to Smoke / Local Test.

Evidence, sources, and controls
Hypothesis

Add one learnable RMSNorm to the complete output of every attention branch after output projection and gating, and to every dense, routed-expert, and shared-expert MLP branch after its down projection, immediately before each branch is added to the residual stream. Retain the existing input Pre-RMSNorms, QK norms, embedding path, final norm, attention pattern, and residual topology. This isolated output-normalization component from Peri-LN should lower equal-token held-out decoder pretraining loss and reduce depth-wise activation growth and gradient spikes without changing model width. Falsify the sample-efficiency claim if the candidate does not beat the matched control beyond calibrated local run noise at step 3000, or if any apparent loss gain depends on a changed schedule, data order, token count, or added embedding normalization.

Evidence

Local 1B implementation is feasible with a small architecture flag and focused tests. The supplied historical commit 9f13144d implements a different residual-norm switch: it reuses existing input norms on sublayer outputs and can remove PreNorm, so it should not be ported directly. The faithful diff adds separate learnable output RMSNorms after attention output projection/gating, dense FFN down projection, and the complete routed/shared MoE branch outputs immediately before residual addition, while preserving existing PreNorms, QK norms, embedding path, final norm, attention pattern, and residual topology. No unresolved local scientific choice blocks implementation.

Current evidence
  • internal repository analysisTitan repository analysis: Peri-LN output RMSNorm

    Local 1B implementation is feasible with a small architecture flag and focused tests. The supplied historical commit 9f13144d implements a different residual-norm switch: it reuses existing input norms on sublayer outputs and can remove ...

  • internal failure diagnosisTraining failure diagnosis: Peri-LN output RMSNorm

    The training lifecycle reaches `router.update_ema()` with router EMA enabled, but the router's EMA weight references were never cached before the first optimizer-step EMA update. The earliest concrete failure is the assertion in `poolsid...

  • arxivPeri-LN: Revisiting Normalization Layer in the Transformer Architecture

    Selecting a layer normalization (LN) strategy that stabilizes training and speeds convergence in Transformers remains difficult, even for today's large language models (LLM). We present a comprehensive analytical foundation for understan...

  • internal implementation failureImplementation failure: Peri-LN output RMSNorm

    Implementation audit requested repair: Trusted check trusted_gpu_verification failed: tests.titan.test_peri_ln_output_norm_distributed::test_peri_ln_output_norm_tp_egp_gradients [failure] torch._dynamo.exc.TorchRuntimeError: RuntimeError...

15 earlier records are available in the full idea history.

Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_d22956657b444feb
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
479f0b199890728563f86a74f03b3615b5498683
Branch
auto-research/idea_50ea033e59f842f7/local-dp4-candidate_ebffb3c1117440605e50
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/local-dp4-candidate_ebffb3c1117440605e50
Configuration
/persistent/.local/state/george-auto-research/run_configs/local-dp4-candidate_ebffb3c1117440605e50.local.yaml
Config SHA-256 (recorded, unverified)
d3cfa4db4d54835154547a73ec9a2618224b7a19ebe517d44568b9119dd282d9
Actual config SHA-256
d3cfa4db4d54835154547a73ec9a2618224b7a19ebe517d44568b9119dd282d9
Resolved config SHA-256 (recorded, unverified)
ee2cbab8da41ebc334920b46b46e4e84584eeffe905d28424dff229002a602aa
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/local-dp4-candidate_ebffb3c1117440605e50.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

One-sided sigmoid Mixture of Activations

P9Score 0.56needs review

In every dense, routed-expert, and shared-expert SwiGLU FFN, keep the SiLU gate branch unchanged and replace only the linear multiplicative branch z with the source one-sided token-adaptive mixture sum_k sigmoid(u_k^T x)*sigma_k(z), shar...

Evidence

Local implementation is structurally possible in Titan but not exactly specifiable from the supplied evidence because the required Type-II activation dictionary is missing. The relevant code paths are dense Transformer FeedForward, Trans...

View details
Idea details

One-sided sigmoid Mixture of Activations

Lifecycleneeds review
PriorityP9
Score0.56
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

In every dense, routed-expert, and shared-expert SwiGLU FFN, keep the SiLU gate branch unchanged and replace only the linear multiplicative branch z with the source one-sided token-adaptive mixture sum_k sigmoid(u_k^T x)*sigma_k(z), sharing the existing linear projections across activations. Use the exact paper-selected Type-II activation dictionary and sigmoid gating, initialize the gate vectors with N(0,0.02^2), and do not use bi-sided, quadratic, hard-routed, or learnable-input-independent variants. This added token-adaptive nonlinearity should lower equal-token held-out loss at approximately unchanged memory and modest runtime cost. Reject the claim if final loss does not beat the matched SwiGLU control beyond calibrated local noise, if gates collapse to a token-independent mixture without a loss benefit, or if measured throughput makes the gain unfavorable.

Evidence

Local implementation is structurally possible in Titan but not exactly specifiable from the supplied evidence because the required Type-II activation dictionary is missing. The relevant code paths are dense Transformer FeedForward, TransformerMoE FeedForward for dense/shared experts, GroupedRoutedExperts for routed experts, and the MoE/MTP parallelizers. The supplied local-history patch 5215b002 only changes shared-expert gate dimensionality and does not implement this MoA mechanism.

Current evidence
  • internal repository analysisTitan repository analysis: One-sided sigmoid Mixture of Activations

    Local implementation is structurally possible in Titan but not exactly specifiable from the supplied evidence because the required Type-II activation dictionary is missing. The relevant code paths are dense Transformer FeedForward, Trans...

  • arxivMore Expressive Feedforward Layers: Part I. Token-Adaptive Mixing of Activations

    Feedforward network (FFN) layers account for a large fraction of parameters and nonlinear expressivity in Transformer-based large language models (LLMs). Despite the evolution from ReLU and GELU to gated variants such as SwiGLU, most FFN...

  • manualOne-sided sigmoid Mixture of Activations

Branch-specific RMSNorm projection scales

P9Score 0.56needs review

At every decoder Pre-RMSNorm, compute the RMS-normalized direction once, then replace the one shared affine scale with separately learned gamma_Q, gamma_K, and gamma_V vectors before the query, key, and value projections, plus separate g...

Evidence

The mechanism is mostly implementable in the target tree: current decoder PreNorms already centralize the single affine RMSNorm before attention and MLP branches, and MoE routed/shared experts have identifiable gate/up projection sites. ...

View details
Idea details

Branch-specific RMSNorm projection scales

Lifecycleneeds review
PriorityP9
Score0.56
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

At every decoder Pre-RMSNorm, compute the RMS-normalized direction once, then replace the one shared affine scale with separately learned gamma_Q, gamma_K, and gamma_V vectors before the query, key, and value projections, plus separate gamma_gate and gamma_up vectors before the two SwiGLU input projections in dense, routed-expert, and shared-expert MLPs. Initialize every branch-specific vector from the control shared gamma so the initial function is identical, and leave the existing QK output norms and all other architecture and optimizer behavior unchanged. The source argues that these O(d) vectors change optimization preconditioning rather than expressivity; the falsifiable prediction is lower equal-token held-out loss. Reject the claim if step-3000 loss does not beat the matched control beyond calibrated local noise or if the gain disappears when all non-scale-vector settings are matched.

Evidence

The mechanism is mostly implementable in the target tree: current decoder PreNorms already centralize the single affine RMSNorm before attention and MLP branches, and MoE routed/shared experts have identifiable gate/up projection sites. The smallest diff is a new branch-specific norm path plus wiring through dense, MoE, FP8 routed, shared-expert, TP, MTP, and activation-checkpoint call sites. The main unresolved local scientific choice is Titan's existing attention gate projection, which is fed by the same PreNorm but is not covered by the source's Q/K/V-only branch definition.

Current evidence
  • internal repository analysisTitan repository analysis: Branch-specific RMSNorm projection scales

    The mechanism is mostly implementable in the target tree: current decoder PreNorms already centralize the single affine RMSNorm before attention and MLP branches, and MoE routed/shared experts have identifiable gate/up projection sites. ...

  • manualPrimary extraction: branch scales precede shared QKV and SwiGLU projections

    The paper defines heterogeneous scales where one shared Transformer Pre-Norm feeds Q/K/V and separately feeds SwiGLU gate/up linear projections. For Titan MoE, gamma_gate and gamma_up are global hidden-dimension Pre-Norm branch scales ap...

  • arxivNegligible in Size, Significant in Effect: On Scale Vectors in Large Language Models

    Normalization layers in modern large language models (LLMs) consist of a deterministic normalization operation and a learnable scale vector. While the normalization operation has been extensively studied, the scale vector remains poorly ...

  • internal implementation failureImplementation failure: Branch-specific RMSNorm projection scales

    Implementation audit requested repair: Authoritative host verification is not clean for the current candidate: `host_verification.verified` is false and `uv run --no-sync .github/static_checks.sh` failed. The trusted static check output ...

17 earlier records are available in the full idea history.

Full zero-init Polar Coordinate Position Embedding

P8Score 0.62needs review

Replacing RoPE with the full PoPE v3 mechanism - softplus query/key magnitudes, one scalar frequency per head dimension, and a learned per-layer/per-head/per-frequency phase delta zero-initialized and clamped to [-2*pi, 0] - will decoupl...

Evidence

The ICML 2026 camera-ready primary paper evaluates matched decoder-only language models on OpenWebText from 124M to 774M parameters. Reported RoPE-to-PoPE perplexity is 21.55 to 21.33 at 124M, 18.88 to 18.55 at 253M, and 15.85 to 15.45 a...

View details
Idea details

Full zero-init Polar Coordinate Position Embedding

Lifecycleneeds review
PriorityP8
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Replacing RoPE with the full PoPE v3 mechanism - softplus query/key magnitudes, one scalar frequency per head dimension, and a learned per-layer/per-head/per-frequency phase delta zero-initialized and clamped to [-2*pi, 0] - will decouple content and position and lower held-out next-token loss/AUC under the fixed Titan TPP30 protocol.

Evidence

The ICML 2026 camera-ready primary paper evaluates matched decoder-only language models on OpenWebText from 124M to 774M parameters. Reported RoPE-to-PoPE perplexity is 21.55 to 21.33 at 124M, 18.88 to 18.55 at 253M, and 15.85 to 15.45 at 774M; the 774M downstream average is 51.80 to 52.46. The paper's ablations show both softplus magnitudes and learned phase delta are needed for the full result.

Current evidence
  • internal repository analysisTitan repository analysis: Full zero-init Polar Coordinate Position Embedding

    PoPE v3 replaces RoPE's cos/sin-rotation with a scalar-per-dimension magnitude/phase scheme: mu_q=softplus(q_c), mu_k=softplus(k_c), theta_c=base^(-c/head_dim) for c in [0,head_dim), logit=sum_c mu_q*mu_k*cos((s-t)*theta_c+delta_head). B...

  • arxivDecoupling the "What" and "Where" With Polar Coordinate Positional Embeddings

    The ICML 2026 camera-ready primary paper evaluates matched decoder-only language models on OpenWebText from 124M to 774M parameters. Reported RoPE-to-PoPE perplexity is 21.55 to 21.33 at 124M, 18.88 to 18.55 at 253M, and 15.85 to 15.45 a...

  • internal implementation failureImplementation failure: Full zero-init Polar Coordinate Position Embedding

    Implementation audit requested repair: Trusted host verification is not clean: `host_verification.verified` is false and `format_normalization` failed with Ruff `E501` on `poolside/titan/models/transformer_moe.py:982`. This must be fixed...

2 earlier records are available in the full idea history.

Required controls
  1. Implement one switch whose disabled path is numerically identical to the canonical baseline; do not bundle any second architecture or optimizer change.
  2. First run a 3-optimizer-step smoke. If depth is shortened, change only n_layers and trim attention_window to the shortened pattern; preserve width, experts, head geometry, and all other model behavior.
  3. Then run a 300-step full-shape prefix probe on 8 GPUs, preserving the complete 3000-step scheduler horizon (100 warmup, cooldown beginning at step 2100). Treat this as a diagnostic, not final evidence.
  4. Only proceed to the matched 3000-step A/B if the smoke is finite, the off-switch parity check passes, and the 300-step loss/AUC and systems metrics show no regression that already falsifies the idea.
  5. Use the exact canonical about-1B-total/about-100M-active TPP30 protocol on 8 GPUs, with identical seed, data order, tokenizer, global batch, optimizer, schedule, parallelism, compile mode, and evaluator.
  6. Record resolved config, git SHA, seed, tokenizer version, dataset manifest, actual token count/TPP, wall time, tokens/s, peak memory, allocation retries/OOMs, and W&B run ids in the separate Autoresearch project.
  7. Implement full v3 PoPE exactly: for scalar c, mu_q=softplus(q_c), mu_k=softplus(k_c), theta_c=10000^(-c/d_head), and logit=sum_c mu_q*mu_k*cos((query_position-key_position)*theta_c + delta_(layer,query_head,c)), retaining the baseline attention scale used by the source implementation.
  8. Use d_head scalar frequencies rather than RoPE's paired d_head/2 rotations. Zero-initialize delta and clamp it to [-2*pi, 0] as in the authors' OpenWebText implementation.
  9. Review and document exact GQA broadcasting before implementation; preserve per-query-head delta without duplicating or changing shared K/V semantics.
  10. Compare dense reference and optimized forward/gradient results, and measure delta distributions, frequency usage, Q/K magnitude distributions, and attention-logit scale by depth.

Rank-16 elementwise GatedNorm

P8Score 0.49needs review

Replace each decoder RMSNorm output covered by the source mechanism with rank-16 elementwise GatedNorm: for y=RMSNorm(x), compute y_gate=sigmoid(W_up(SiLU(W_down(y)))) and return y_gate*y. Preserve the baseline gated-attention mechanism,...

Evidence

The local 1B implementation is feasible without production code changes: the target snapshot already contains rank-configurable elementwise sigmoid low-rank GatedRMSNorm and MoE config wiring. The candidate should be generated downstream...

View details
Idea details

Rank-16 elementwise GatedNorm

Lifecycleneeds review
PriorityP8
Score0.49
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Replace each decoder RMSNorm output covered by the source mechanism with rank-16 elementwise GatedNorm: for y=RMSNorm(x), compute y_gate=sigmoid(W_up(SiLU(W_down(y)))) and return y_gate*y. Preserve the baseline gated-attention mechanism, attention pattern, residual topology, and all non-normalization behavior. Use the source rank 16 and bounded sigmoid gate, and match the control total parameter count by reducing only candidate FFN capacity by the minimum required amount. The explicit learned rescaling should lower equal-token held-out decoder pretraining loss and reduce residual-stream outlier concentration. Reject the claim if final loss does not beat the parameter-matched control beyond calibrated local noise, if training becomes unstable, or if the result requires a non-sigmoid or tensorwise gate.

Evidence

The local 1B implementation is feasible without production code changes: the target snapshot already contains rank-configurable elementwise sigmoid low-rank GatedRMSNorm and MoE config wiring. The candidate should be generated downstream from scripts/runs/tiny.yaml, not checked in under scripts/runs, with residual norms switched to gated_rmsnorm rank 16 and dense FFN intermediate_size reduced from 2048 to 1845. Keep gated attention, attention windows, QK norms, loss masks, EOS/data settings, optimizer, seed, and fixed equal-token protocol unchanged. The supplied gated-XSA history is unrelated provenance for attention gating and does not implement this normalization mechanism.

Current evidence
  • internal repository analysisTitan repository analysis: Rank-16 elementwise GatedNorm

    The local 1B implementation is feasible without production code changes: the target snapshot already contains rank-configurable elementwise sigmoid low-rank GatedRMSNorm and MoE config wiring. The candidate should be generated downstream...

  • arxivA Unified View of Attention and Residual Sinks: Outlier-Driven Rescaling is Essential for Transformer Training

    We investigate the functional role of emergent outliers in large language models, specifically attention sinks (a few tokens that consistently receive large attention logits) and residual sinks (a few fixed dimensions with persistently l...

  • arxivA Unified View of Attention and Residual Sinks: Outlier-Driven Rescaling is Essential for Transformer Training

    We investigate the functional role of emergent outliers in large language models, specifically attention sinks (a few tokens that consistently receive large attention logits) and residual sinks (a few fixed dimensions with persistently l...

  • internal implementation failureImplementation failure: Rank-16 elementwise GatedNorm

    Implementation audit requested repair: Trusted check static_checks failed: .................................Passed ruff (legacy alias)......................................................Passed ruff format..................................

20 earlier records are available in the full idea history.

anGPT approximate compact-space residual normalization

P7Score 0.48needs review

Implement the source anGPT architecture as one explicit compound candidate: use its dimension-derived fixed approximate normalization factors, LERP-style residual updates, and bounded directional weight parameterization instead of nGPT-s...

Evidence

Repository wiring can host an architecture candidate in TransformerMoE, and the matched local config should be generated from scripts/runs/tiny.yaml with fixed 3000 steps, 100 warmup, and 900 cooldown while retaining Muon weight decay. I...

View details
Idea details

anGPT approximate compact-space residual normalization

Lifecycleneeds review
PriorityP7
Score0.48
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Implement the source anGPT architecture as one explicit compound candidate: use its dimension-derived fixed approximate normalization factors, LERP-style residual updates, and bounded directional weight parameterization instead of nGPT-style exact per-step hypersphere normalization. For this first architecture test, retain the Titan control optimizer, weight decay, 100-step warmup, and 900-step cooldown so schedule and regularization do not confound the architecture comparison. The compact-space geometry should lower equal-token held-out loss and control residual-norm growth with small runtime overhead. Reject this architecture claim if final loss does not beat the matched GPT-plus-QK-norm control beyond calibrated local noise, if norms escape the source bounds, or if improvement appears only after also removing warmup or weight decay.

Evidence

Repository wiring can host an architecture candidate in TransformerMoE, and the matched local config should be generated from scripts/runs/tiny.yaml with fixed 3000 steps, 100 warmup, and 900 cooldown while retaining Muon weight decay. Inspection found no existing anGPT implementation and no complete source equations in the supplied local evidence, so exact implementation is blocked rather than safely inferable. The 17B path has verified configs, including scripts/runs/large.yaml, but the checked-in large baseline is MTPTransformerMoE and should not be used directly for a clean architecture-only claim.

Current evidence
  • internal repository analysisTitan repository analysis: anGPT approximate compact-space residual normalization

    Repository wiring can host an architecture candidate in TransformerMoE, and the matched local config should be generated from scripts/runs/tiny.yaml with fixed 3000 steps, 100 warmup, and 900 cooldown while retaining Muon weight decay. I...

  • arxivnGPT: Normalized Transformer with Representation Learning on the Hypersphere

    We propose a novel neural network architecture, the normalized Transformer (nGPT) with representation learning on the hypersphere. In nGPT, all vectors forming the embeddings, MLP, attention matrices and hidden states are unit norm norma...

  • arxivLearning in Compact Spaces with Approximately Normalized Transformer

    The successful training of deep neural networks requires addressing challenges such as overfitting, numerical instabilities leading to divergence, and increasing variance in the residual stream. A common solution is to apply regularizati...

1 earlier records are available in the full idea history.

Masked-input regularization under data reuse

P0Score 0.78needs reviewEarlier smoke passed; retest pending

Changing the pretraining objective to add MIR, an auxiliary next-token loss on randomly masked inputs, should improve held-out base-model loss at matched training tokens because input corruption regularizes repeated-data memorization and...

Evidence

The source proposes masked-input regularization for autoregressive decoder-only pretraining: add an auxiliary next-token prediction loss where inputs are randomly masked, aiming to improve data-constrained repeated-data training without ...

Current blocker

Repository analysis retry budget exhausted for idea_1278bd21deec473e

Full-AC probe recovery - health/directional only - completedRepository analysis retry budget exhausted for idea_1278bd21deec473e
100.0%300 / 300 (100.0%)Training loss 4.968 at step 300W&B poolside/Autoresearch
Directional gate

Clean CE gate did not pass: candidate 3.306537 vs control 3.305000 (delta +0.001537). No 3000-step pair was launched.

View details
Idea details

Masked-input regularization under data reuse

Lifecycleneeds review
PriorityP0
Score0.78
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Experiment

Full-AC probe recovery - health/directional only - completed

100.0%300 / 300 (100.0%)Training loss 4.968 at step 300
Matched baseline

probe-dp4-control_b0fe69b449383cfae20b

Experiment conclusion

Repository analysis retry budget exhausted for idea_1278bd21deec473e

Directional gate

Clean CE gate did not pass: candidate 3.306537 vs control 3.305000 (delta +0.001537). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Current blocker

Repository analysis retry budget exhausted for idea_1278bd21deec473e

Gate: repository analysis failure.

Test history

An earlier implementation passed its distributed smoke. The corrected build must finish and pass a new smoke before this card returns to Smoke / Local Test.

Evidence, sources, and controls
Hypothesis

Changing the pretraining objective to add MIR, an auxiliary next-token loss on randomly masked inputs, should improve held-out base-model loss at matched training tokens because input corruption regularizes repeated-data memorization and encourages more robust autoregressive representations without changing inference architecture.

Evidence

The source proposes masked-input regularization for autoregressive decoder-only pretraining: add an auxiliary next-token prediction loss where inputs are randomly masked, aiming to improve data-constrained repeated-data training without changing architecture or inference. It also proposes SoftQ, a scaling law for finite-data repeated-epoch regimes, but the clean Titan candidate is the MIR objective intervention.

Current evidence
  • internal repository analysisTitan repository analysis: Masked-input regularization under data reuse

    MIR is locally feasible as a small Trainer-level objective change for the non-PP TransformerMoE path. The smallest safe implementation adds only training.masked_input_regularization_coeff, keeps coefficient 0 on the untouched legacy path...

  • internal tokenizer artifactLaguna RC2 tokenizer artifact: MASK token id 12

    The exact Laguna RC2 tokenizer used by the Titan baselines defines its specialized MASK token at vocabulary id 12. tokenizer_config.json and tokenizer.json agree on id 12 and mark it special; all freshly downloaded local files match thei...

  • arxivData-Constrained Language Model Pretraining: Improved Regularization and Scaling Laws

    Classical scaling laws for language model pretraining balance model size against training dataset size under a fixed compute budget, assuming abundant data and a single pass over the corpus. As training compute grows faster than the supp...

  • internal implementation failureImplementation failure: Masked-input regularization under data reuse

    Implementation audit requested repair: Trusted host verification is not green for the current candidate: host_verification.verified is false, and the authoritative touched test run has a new failure in tests/titan/test_masked_input_regul...

46 earlier records are available in the full idea history.

Required controls
  1. Baseline: Titan decoder-only MoE with established data mixture, tokenizer, optimizer, weight decay, and no MIR.
  2. Match token budget first: same number of training tokens and optimizer steps; also report any extra objective compute separately for equal-FLOP interpretation.
  3. Use same seed and data order when practical; otherwise paired seeds matching the local baseline variance protocol.
  4. Change only MIR: add the randomly masked-input auxiliary next-token loss with a fixed mask rate and coefficient; keep architecture and inference path unchanged.
  5. Track whether masking changes effective context corruption, loss normalization, batch shape, activation memory, or throughput.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_273bf95a8c1842c7
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
7b79c5c37ee1453d085c599412b000638c52d9b1
Branch
auto-research/idea_1278bd21deec473e/probe-dp4-candidate-fullac_6e16c91a699b51295e18
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate-fullac_6e16c91a699b51295e18
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate-fullac_6e16c91a699b51295e18.local.yaml
Config SHA-256 (recorded, unverified)
c751c6e82aeab43693d159e7bade86eba2070a1b68fdd7911b320c3584a1fd0a
Actual config SHA-256
c751c6e82aeab43693d159e7bade86eba2070a1b68fdd7911b320c3584a1fd0a
Resolved config SHA-256 (recorded, unverified)
4a87d478567e19d6a45336ffa1a27595176327a6903b36f5deed05354a46d7f4
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate-fullac_6e16c91a699b51295e18.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Frobenius Hyperball Muon

P0Score 0.68needs review

Changing eligible Transformer matrix updates from decoupled weight decay to Muon Hyperball should improve held-out base-model loss under matched tokens or matched measured FLOPs because fixed Frobenius weight and update norms directly co...

Evidence

Hyperball replaces decoupled weight decay's implicit matrix-norm equilibrium with an explicit Frobenius-sphere optimizer constraint. For eligible Transformer matrices, it fixes matrix norms and update norms while leaving embeddings and n...

View details
Idea details

Frobenius Hyperball Muon

Lifecycleneeds review
PriorityP0
Score0.68
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible Transformer matrix updates from decoupled weight decay to Muon Hyperball should improve held-out base-model loss under matched tokens or matched measured FLOPs because fixed Frobenius weight and update norms directly control angular learning rate instead of relying on implicit weight-decay equilibrium.

Evidence

Hyperball replaces decoupled weight decay's implicit matrix-norm equilibrium with an explicit Frobenius-sphere optimizer constraint. For eligible Transformer matrices, it fixes matrix norms and update norms while leaving embeddings and norm-like parameters on Adam. The source reports that MuonH maintains larger token-equivalent speedups than MuonW at 1.2B scale and improves LR transfer across model shapes.

Current evidence
  • internal repository analysisTitan repository analysis: Frobenius Hyperball Muon

    Frobenius Hyperball Muon is locally implementable as a scoped Muon optimizer extension, not a model wrapper. The smallest faithful change is to add an opt-in Muon hyperball mode over the existing Muon-eligible matrix groups, store each m...

  • arxivFantastic Pretraining Optimizers and Where to Find Them II: Hyperball Optimization

    Matrix based optimizers such as Muon can substantially speed up language model pretraining, but their gains over AdamW are observed to shrink as model size and data scale grow when using standard constant decoupled weight decay. We propo...

  • arxivRethinking Language Model Scaling under Transferable Hypersphere Optimization

    Scaling laws for large language models depend critically on the optimizer and parameterization. Existing hyperparameter transfer laws are mainly developed for first-order optimizers, and they do not structurally prevent training instabil...

1 earlier records are available in the full idea history.

Required controls
  1. Exact Titan baseline optimizer recipe at matched tokens and optimizer steps
  2. Same seed and data order when practical
  3. Matched active FLOPs reported, including Hyperball projection overhead
  4. Compare MuonH against tuned MuonW and AdamW, not only AdamW
  5. Keep embeddings, norm gains, and semantically normed parameters on Adam as source specifies

Post-polar Muon+ normalization

P0Score 0.68needs review

Changing eligible Muon matrix updates to apply one post-polar bidirectional normalization step should improve held-out decoder pretraining loss under matched tokens because it reduces row/column imbalance amplified by practical polar ite...

Evidence

Muon+ addresses a claimed post-polar imbalanced-update problem in Muon: practical polar/Newton-Schulz orthogonalization can amplify row and column imbalance in the update matrix. The proposed fix adds one normalization step after polar o...

View details
Idea details

Post-polar Muon+ normalization

Lifecycleneeds review
PriorityP0
Score0.68
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible Muon matrix updates to apply one post-polar bidirectional normalization step should improve held-out decoder pretraining loss under matched tokens because it reduces row/column imbalance amplified by practical polar iterations without adding optimizer state.

Evidence

Muon+ addresses a claimed post-polar imbalanced-update problem in Muon: practical polar/Newton-Schulz orthogonalization can amplify row and column imbalance in the update matrix. The proposed fix adds one normalization step after polar orthogonalization, without extra optimizer state. The supplied evidence reports lower validation perplexity than Muon across GPT and LLaMA pretraining runs on FineWeb, with direction, polar-function, competing-optimizer, overtraining, and limited multi-seed ablations.

Current evidence
  • internal repository analysisTitan repository analysis: Post-polar Muon+ normalization

    Titan's target tree already has a clear Muon insertion point: schedule_compute gathers the full bf16 update block, runs Newton-Schulz, and scatters slices back. Muon+ is feasible as a small optimizer-local extension with no extra state, ...

  • arxivMUON+: Towards More Effective Muon via One Additional Normalization Step for LLM Pre-training

    Muon has recently emerged as a strong optimizer for large language model pre-training, orthogonalizing the momentum matrix via Newton--Schulz polar iterations. A natural intuition is that polar iterations, by flattening the singular spec...

Required controls
  1. Exact Titan Muon baseline with identical model, data, tokenizer, batch, schedule, parameter grouping, seed, token budget, and Newton-Schulz coefficients
  2. Equal-token 3000-step local candidate and control; also report measured throughput and approximate active FLOPs
  3. Same seed when practical, with repeat seeds if the observed delta is within calibrated local baseline variance
  4. Ablate Muon+ row_col or col_row against plain Muon without changing LR, weight decay, schedule, or Muon parameter eligibility

Input-preconditioned Newton-Muon

P0Score 0.64needs review

Changing eligible decoder matrix updates from standard Muon to Newton-Muon right-preconditioned orthogonalized updates should improve held-out base-model loss under matched pretraining tokens because input-second-moment inverse precondit...

Evidence

Newton-Muon modifies Muon by right-preconditioning each eligible matrix gradient with a ridge-stabilized inverse estimate of the layer input second moment before taking the matrix sign or polar direction. The source reports faster target...

View details
Idea details

Input-preconditioned Newton-Muon

Lifecycleneeds review
PriorityP0
Score0.64
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible decoder matrix updates from standard Muon to Newton-Muon right-preconditioned orthogonalized updates should improve held-out base-model loss under matched pretraining tokens because input-second-moment inverse preconditioning corrects Muon's neglected right-side curvature before spectral normalization.

Evidence

Newton-Muon modifies Muon by right-preconditioning each eligible matrix gradient with a ridge-stabilized inverse estimate of the layer input second moment before taking the matrix sign or polar direction. The source reports faster target-validation-loss attainment on reproduced Modded-NanoGPT FineWeb speedrun settings, with smaller or marginal gains on more optimized records.

Current evidence
  • internal repository analysisTitan repository analysis: Input-preconditioned Newton-Muon

    Newton-Muon is feasible as an opt-in extension of Titan's existing Muon optimizer, not as a config-only change. The smallest local implementation keeps poolside.titan.optimizers.Muon as the class path, adds activation second-moment state...

  • arxivThe Newton-Muon Optimizer

    The Muon optimizer has received considerable attention for its strong performance in training large language models, yet the design principle behind its matrix-gradient orthogonalization remains largely elusive. In this paper, we introdu...

  • github repositoryzhehangdu/Newton-Muon

    The Newton-Muon optimizer # The Newton-Muon Optimizer Paper: [arXiv:2604.01472](https://arxiv.org/abs/2604.01472) This repository is adapted from [modded-nanogpt](https://github.com/KellerJordan/modded-nanogpt). Thanks to Keller Jorda...

Required controls
  1. Baseline optimizer is the current Titan Muon assignment on the same model, data, tokenizer, schedule, batch, and token budget.
  2. Run candidate and control with matched seeds when practical and exactly matched optimizer updates/tokens for the primary loss comparison.
  3. Report measured step time, optimizer memory, and active FLOPs so any wall-clock or compute claim is interpreted separately from equal-token loss.
  4. Use a small learning-rate sweep for both Muon and Newton-Muon or preregister the source-derived candidate LR and a tuned Muon control to avoid one-sided tuning.

Neuron-wise normalized Muon

P0Score 0.62needs review

Changing eligible Muon matrix updates to NorMuon neuron-wise normalized orthogonalized updates should improve held-out decoder pretraining loss under matched tokens because row-wise adaptive second-moment scaling balances per-neuron upda...

Evidence

NorMuon combines Muon's matrix update orthogonalization with neuron-level adaptive learning rates. The source argues that Muon fixes update condition numbers but leaves high variance in per-neuron update norms, and that maintaining row-w...

View details
Idea details

Neuron-wise normalized Muon

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible Muon matrix updates to NorMuon neuron-wise normalized orthogonalized updates should improve held-out decoder pretraining loss under matched tokens because row-wise adaptive second-moment scaling balances per-neuron update norms while preserving Muon's matrix conditioning benefit.

Evidence

NorMuon combines Muon's matrix update orthogonalization with neuron-level adaptive learning rates. The source argues that Muon fixes update condition numbers but leaves high variance in per-neuron update norms, and that maintaining row-wise second-moment statistics followed by row-wise normalization balances neuron utilization. Reported decoder pretraining experiments compare AdamW, Muon, Dion, and NorMuon across multiple model scales.

Current evidence
  • internal repository analysisTitan repository analysis: Neuron-wise normalized Muon

    NorMuon is locally plausible as a Muon-family optimizer mode, not a model/data/loss change. Titan's current Muon implementation already has the right boundary: eligible hidden matrices are split by OptimizersContainer, gathered over the ...

  • github repositoryDominator-Index/RMNP

    # RMNP: Row-Momentum Normalized Preconditioning for Scalable Matrix-Based Optimization > ### $\color{#1E3A8A}{\textbf{Input-dimension normalization is asymptotically equivalent to orthogonalization.}}$ This repository contains the offi...

  • github repositoryzichongli5/NorMuon

    Official Implementation for NorMuon paper # NorMuon Official implementation of **NorMuon: Making Muon more efficient and scalable** ([arXiv:2510.05491](https://arxiv.org/abs/2510.05491)). > ? **Accepted as a Spotlight at ICML 2026.** ...

1 earlier records are available in the full idea history.

Required controls
  1. Titan baseline optimizer recipe at matched tokens and identical model/data/tokenizer/seed where practical.
  2. Standard Titan Muon control with the same eligible parameter set, LR schedule, weight decay groups, and optimizer-step budget.
  3. AdamW or current production optimizer control if different from Muon, to separate NorMuon gain from Muon-family gain.
  4. Report measured tokens/sec, optimizer memory, and active FLOPs because row-wise second moments and distributed orthogonalization may change cost.

Parallax covariance-probe attention

P0Score 0.62needs review

Changing causal softmax attention to Muon-trained Parallax attention should improve held-out base-model loss under matched tokens or matched measured FLOPs because the learned rho projector supplies a local-linear KV-covariance correctio...

Evidence

Parallax modifies attention from a local-constant softmax estimator toward a parameterized local-linear estimator. It adds a learned rho/R projector that probes KV covariance and contributes a correction branch to the standard attention ...

View details
Idea details

Parallax covariance-probe attention

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing causal softmax attention to Muon-trained Parallax attention should improve held-out base-model loss under matched tokens or matched measured FLOPs because the learned rho projector supplies a local-linear KV-covariance correction that improves associative-memory prediction beyond the local-constant estimator of softmax attention.

Evidence

Parallax modifies attention from a local-constant softmax estimator toward a parameterized local-linear estimator. It adds a learned rho/R projector that probes KV covariance and contributes a correction branch to the standard attention output. The supplied evidence reports 0.6B and 1.7B pretraining gains under Muon, with parameter-matched and compute-matched controls, and shows the advantage weakens under AdamW.

Current evidence
  • internal repository analysisTitan repository analysis: Parallax covariance-probe attention

    The Titan target tree is conceptually ready for an Attention-local Parallax prototype, but not for an exact implementation from the supplied records alone. The current MoE attention path has a clean insertion point: TransformerMoE Attent...

  • github repositoryYifei-Zuo/Parallax

    Official repository for Parallax (Parameterized Local Linear Attention) # Parallax: Parameterized Local Linear Attention [![arXiv](https://img.shields.io/badge/-arXiv-000000.svg?logo=arxiv&logoColor=b31b1b)](https://arxiv.org/abs/2605....

  • arxivParallax: Parameterized Local Linear Attention for Language Modeling

    Large Language Models (LLMs) have become the central paradigm in artificial intelligence, yet the core computational primitive of attention has remained structurally unchanged. Local Linear Attention (LLA) is an attention mechanism deriv...

1 earlier records are available in the full idea history.

Required controls
  1. Titan baseline TransformerMoE/Muon control with identical data, tokenizer, sequence length, batch, 3000 steps, 100 warmup, 900 cooldown, and same seed where practical.
  2. Parameter-matched Parallax candidate changing only attention mechanism plus required extra R projector, with total active parameters matched by local width adjustment if needed.
  3. Compute-accounting control measuring active FLOPs and throughput; interpret primary result at equal tokens and report equal-measured-FLOP adjusted loss if overhead is material.
  4. AdamW is not required for the primary Titan falsifier, but if run it should be a diagnostic optimizer-interaction control rather than the main comparison.

Variance-adaptive Muon momentum

P0Score 0.62needs review

Changing eligible Muon matrix updates to variance-adapt momentum before Newton-Schulz orthogonalization should improve held-out decoder pretraining loss under matched tokens because per-coordinate variance or noise-to-signal normalizatio...

Evidence

The source proposes Muon-NSR and Muon-VS, optimizer variants that normalize Muon momentum using variance or noise-to-signal information before Newton-Schulz orthogonalization. Reported decoder-only GPT-2 and LLaMA pretraining experiments...

View details
Idea details

Variance-adaptive Muon momentum

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible Muon matrix updates to variance-adapt momentum before Newton-Schulz orthogonalization should improve held-out decoder pretraining loss under matched tokens because per-coordinate variance or noise-to-signal normalization conditions the momentum matrix before spectral whitening.

Evidence

The source proposes Muon-NSR and Muon-VS, optimizer variants that normalize Muon momentum using variance or noise-to-signal information before Newton-Schulz orthogonalization. Reported decoder-only GPT-2 and LLaMA pretraining experiments compare against AdamW, Muon, and AdaMuon and claim lower validation loss and faster convergence under matched training protocols.

Current evidence
  • internal repository analysisTitan repository analysis: Variance-adaptive Muon momentum

    The Titan target tree has a clean optimizer-only insertion point: current Muon forms EMA/Nesterov momentum in filter_group, gathers Muon-eligible matrix DTensors, applies Newton-Schulz, then updates parameters with existing scaling and w...

  • github repositoryjingru-lee/Variance-Adaptive-Muon

    Official PyTorch implementation of "Variance-Adaptive Muon: Accelerating LLM Pretraining with NSR-Modulated and Variance-Scaled Momentum" # Variance-Adaptive Muon [![arXiv](https://img.shields.io/badge/arXiv-2601.14603-b31b1b.svg)](htt...

  • arxivVariance-Adaptive Muon: Accelerating LLM Pretraining with NSR-Modulated and Variance-Scaled Momentum

    Large Language Models (LLMs) achieve competitive performance across diverse natural language processing (NLP) tasks, yet pretraining is computationally demanding, making optimizer efficiency an important practical consideration. Muon acc...

2 earlier records are available in the full idea history.

Required controls
  1. Titan baseline optimizer assignment with existing Muon/AdamW parameter partitioning and identical model, data, tokenizer, schedule, weight decay, clipping, batch, and token count
  2. Candidate changes only eligible Muon matrix update preprocessing to Muon-NSR or Muon-VS, with a single config off switch restoring baseline Muon exactly
  3. Use matched seed when practical and run the canonical 3000-step local candidate/control pair at equal tokens
  4. Measure optimizer overhead and report equal-token loss primarily, with measured-FLOP interpretation as secondary
  5. Include a Muon-only control and avoid comparing only to AdamW

Column-normalized Adam subspace updates

P0Score 0.62needs review

Changing eligible decoder matrix optimization to Conda column-normalized Adam should improve held-out base-model loss under matched pretraining tokens because projecting updates into an orthogonal subspace before column-wise second-momen...

Evidence

Conda modifies Adam for matrix parameters by projecting momentum into an orthogonal subspace and maintaining column-wise second moments from projected gradients. The source reports decoder-only LLaMA and GPT-2 pretraining gains over Adam...

View details
Idea details

Column-normalized Adam subspace updates

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible decoder matrix optimization to Conda column-normalized Adam should improve held-out base-model loss under matched pretraining tokens because projecting updates into an orthogonal subspace before column-wise second-moment normalization combines Muon-like spectral conditioning with Adam-like coordinate adaptivity.

Evidence

Conda modifies Adam for matrix parameters by projecting momentum into an orthogonal subspace and maintaining column-wise second moments from projected gradients. The source reports decoder-only LLaMA and GPT-2 pretraining gains over AdamW, Muon, SOAP, and Adafactor, with claimed step and wall-clock convergence speedups.

Current evidence
  • internal repository analysisTitan repository analysis: Column-normalized Adam subspace updates

    Conda is locally implementable as an optimizer-only candidate by adding a Muon-adjacent matrix optimizer and reusing Titan's existing parameter grouping, DTensor sharded optimizer, checkpoint, and standalone CUDA test patterns. The local...

  • github repositoryjie040109/Conda

    The official PyTorch implementation of the paper "Conda: Column-Normalized Adam for Training Large Language Models Faster" # Conda Official PyTorch implementation of the paper: [?Conda: Column-Normalized Adam for Training Large Langu...

  • arxivConda: Column-Normalized Adam for Training Large Language Models Faster

    Large language models (LLMs) have demonstrated impressive generalization and emergent capabilities, yet their pre-training remains computationally expensive and sensitive to optimization dynamics. While Adam-based optimizers offer fast c...

Required controls
  1. Titan baseline optimizer/control unchanged except optimizer assignment
  2. Equal-token 3000-step local candidate and control with same data order and seed when practical
  3. Report measured optimizer overhead and interpret equal-FLOP impact separately
  4. Compare against tuned Titan Muon/AdamW-family baseline rather than AdamW-only

OrScale layer-wise trust-ratio Muon

P0Score 0.62needs review

Changing eligible matrix-parameter Muon+Moonlight updates to include a dynamic per-layer trust ratio (real-update-direction Frobenius-norm denominator, coupled weight decay, r_l,0=1 calibration) should improve held-out decoder pretrainin...

Evidence

Proposes OrScale-LM, a LARS/LAMB-style dynamic per-layer trust ratio applied on top of Muon+Moonlight: r_l,t = ||W_l||_F / (||lambda*W_l + s_l*Q_l||_F + eps), where Q_l is the Newton-Schulz orthogonalized Muon direction, s_l is the Moonl...

View details
Idea details

OrScale layer-wise trust-ratio Muon

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible matrix-parameter Muon+Moonlight updates to include a dynamic per-layer trust ratio (real-update-direction Frobenius-norm denominator, coupled weight decay, r_l,0=1 calibration) should improve held-out decoder pretraining loss under matched tokens because it restores time-varying, layer-adaptive update magnitude control that a static shape-only scaling factor cannot provide, while avoiding the clip-saturation and weight-decay-runaway failure modes of naive LAMB-Muon hybrids.

Evidence

Proposes OrScale-LM, a LARS/LAMB-style dynamic per-layer trust ratio applied on top of Muon+Moonlight: r_l,t = ||W_l||_F / (||lambda*W_l + s_l*Q_l||_F + eps), where Q_l is the Newton-Schulz orthogonalized Muon direction, s_l is the Moonlight shape factor (0.2*sqrt(max(m,n))), and a one-time per-layer calibration anchors r_l,0=1 exactly at init. Weight decay is coupled into the trust-ratio-scaled step rather than applied separately, which the authors show avoids a runaway-norm failure mode. The paper also analyzes and rejects two naive LAMB-Muon hybrids (raw-momentum denominator and post-orthogonalized-norm denominator) via clip-saturation diagnostics. Empirically tested on GPT-2-style dense decoder-only transformers pretrained on FineWeb-Edu at 125M/399M/545M/1.1B, beating Muon+Moonlight at 3 of 4 scales and AdamW at all 4 scales; also tested (irrelevantly) on CIFAR-10/DavidNet vision.

Current evidence
  • internal repository analysisTitan repository analysis: OrScale layer-wise trust-ratio Muon

    Titan can host OrScale-LM as a small optimizer-only branch on the existing Muon+Moonlight path. The key code path is poolside/titan/optimizers/muon.py: current Muon scales Q by Moonlight then applies decoupled weight decay, so the implem...

  • github repositoryNUS-HPC-AI-Lab/OrScale

    Orthogonalized updates with layer-wise scaling for language model training. # OrScale **Orthogonalised Optimization with Layer-Wise Trust-Ratio Scaling** [![arXiv](https://img.shields.io/badge/arXiv-2605.07815-b31b1b.svg)](https://arx...

  • arxivOrScale: Orthogonalised Optimization with Layer-Wise Trust-Ratio Scaling

    Muon improves neural-network training by orthogonalizing matrix-valued updates, but it leaves each layer's update magnitude controlled mostly by a global learning rate. We introduce OrScale, a trust-ratio extension of Muon built on a sim...

Required controls
  1. Exact baseline match: off-switch r_min=r_max=1 recovers current Muon+Moonlight update bit-for-bit
  2. Matched token budget and optimizer step count between candidate and control
  3. Same seed between candidate and control where practical
  4. Report clip-saturation diagnostics (fraction of steps at r_min/r_max) as in the source's failure-mode analysis to confirm the trust ratio is not degenerating to a constant
  5. Coupled weight-decay coefficient lambda held fixed and swept identically for candidate and any weight-decay-ablation variant

Sophia diagonal-Hessian clipped optimizer

P0Score 0.62needs review

Changing the pretraining optimizer from AdamW/Muon to Sophia (gradient-EMA divided by clipped, periodically re-estimated diagonal-Hessian EMA) should improve held-out decoder base-model loss at matched training tokens or matched FLOPs be...

Evidence

Sophia is a second-order optimizer for LM pretraining that maintains an EMA of gradients (momentum) divided by an EMA of a light-weight diagonal Hessian estimate (Hutchinson or Gauss-Newton-Bartlett), re-estimated only every ~10 steps, f...

View details
Idea details

Sophia diagonal-Hessian clipped optimizer

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing the pretraining optimizer from AdamW/Muon to Sophia (gradient-EMA divided by clipped, periodically re-estimated diagonal-Hessian EMA) should improve held-out decoder base-model loss at matched training tokens or matched FLOPs because the lightweight Hessian preconditioner adapts step size to per-coordinate curvature while clipping bounds worst-case updates against Hessian non-convexity/rapid change, reducing steps needed to reach a target loss versus first-order Adam.

Evidence

Sophia is a second-order optimizer for LM pretraining that maintains an EMA of gradients (momentum) divided by an EMA of a light-weight diagonal Hessian estimate (Hutchinson or Gauss-Newton-Bartlett), re-estimated only every ~10 steps, followed by element-wise clipping to bound worst-case update size. On GPT-2 (125M-770M, OpenWebText) and GPT NeoX (1.5B/6.6B, Pile), Sophia reaches matched validation perplexity with about half the optimizer steps, total compute, and wall-clock time versus tuned AdamW, with peak LR and other hyperparameters separately grid-searched per method and per budget to satisfy a stated fair-comparison criterion (avoiding conflating same-hyperparameter transfer across budgets with true speedup).

Current evidence
  • internal repository analysisTitan repository analysis: Sophia diagonal-Hessian clipped optimizer

    Sophia-H is locally implementable but not a drop-in config-only swap. Titan's current tiny and 17B MoE baselines use Muon with Adam fallback groups; Sophia requires a new optimizer plus a periodic Hessian-estimation closure in the traine...

  • arxivSophia: A Scalable Stochastic Second-order Optimizer for Language Model Pre-training

    Given the massive cost of language model pre-training, a non-trivial improvement of the optimization algorithm would lead to a material reduction on the time and cost of training. Adam and its variants have been state-of-the-art for year...

Required controls
  1. Same architecture, data, tokenizer, batch size, gradient-clip threshold, and cosine LR schedule (final LR = 0.05x peak) across optimizers being compared
  2. Peak learning rate and other optimizer hyperparameters (beta1, beta2, weight decay) independently grid-searched per optimizer at each specific step budget being compared, not transferred across budgets
  3. Sophia-specific hyperparameters (gamma, epsilon, Hessian-update interval) tuned once on a small 30M model and held fixed across sizes, mirroring how baseline hyperparameters (besides peak LR) are tuned
  4. Same seed policy and matched total token/step budget when declaring a speedup, per the paper's explicit fair-comparison inequality (Eq. 14) rejecting same-hyperparameter cross-budget comparisons

SOAP: Shampoo-Adam in Kronecker eigenbasis

P0Score 0.62needs review

Replacing AdamW (or the current Muon-eligible matrix optimizer) with SOAP -- Adam-style first/second-moment updates computed in the periodically-refreshed eigenbasis of Shampoo's Kronecker-factored (L=GG^T, R=G^T G) preconditioner -- sho...

Evidence

The paper shows Shampoo (with 1/2 power) is equivalent to running Adafactor in the eigenbasis of Shampoo's Kronecker-factored preconditioner, and proposes SOAP: maintain Shampoo's L=sum GG^T and R=sum G^T G accumulators per 2D layer, per...

View details
Idea details

SOAP: Shampoo-Adam in Kronecker eigenbasis

Lifecycleneeds review
PriorityP0
Score0.62
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Replacing AdamW (or the current Muon-eligible matrix optimizer) with SOAP -- Adam-style first/second-moment updates computed in the periodically-refreshed eigenbasis of Shampoo's Kronecker-factored (L=GG^T, R=G^T G) preconditioner -- should improve held-out decoder base-model loss at matched training tokens or matched optimizer steps because continuously updating second-moment statistics in a slowly-rotating, curvature-aligned coordinate system captures more useful preconditioning information than isotropic per-coordinate Adam while avoiding Shampoo's need for frequent expensive eigendecompositions.

Evidence

The paper shows Shampoo (with 1/2 power) is equivalent to running Adafactor in the eigenbasis of Shampoo's Kronecker-factored preconditioner, and proposes SOAP: maintain Shampoo's L=sum GG^T and R=sum G^T G accumulators per 2D layer, periodically (every f steps) extract eigenvectors Q_L, Q_R via power iteration + QR, rotate the gradient into that basis, run standard Adam first/second-moment updates in the rotated (slowly-changing) coordinate system every step, then rotate the update back. Very large layers (first/last embedding) fix Q to identity, recovering plain Adam for those. On 360M and 660M decoder LMs at 2M and 256K token batch sizes with chinchilla-optimal (20x) and longer (100x) token budgets, SOAP reduces training iterations by >40% and wall-clock time by >35% vs tuned AdamW, and ~20% vs tuned DistributedShampoo, at matched final train loss (measured via scaling-law fits across fractional-data runs). A frequency ablation shows SOAP degrades more gracefully than Shampoo as preconditioning frequency f is reduced.

Current evidence
  • internal repository analysisTitan repository analysis: SOAP: Shampoo-Adam in Kronecker eigenbasis

    SOAP is locally implementable as a new optimizer, not as a model wrapper. The smallest faithful Titan diff is to add poolside.titan.optimizers.SOAP, export it, and extend OptimizersContainer grouping so SOAP replaces Muon only for 2D non...

  • arxivSOAP: Improving and Stabilizing Shampoo using Adam

    There is growing evidence of the effectiveness of Shampoo, a higher-order preconditioning method, over Adam in deep learning optimization tasks. However, Shampoo's drawbacks include additional hyperparameters and computational overhead w...

Required controls
  1. Baseline AdamW and DistributedShampoo each independently learning-rate-swept (and secondary hyperparameter swept) to near-optimal before comparison
  2. Same warmup+cosine schedule shape and same beta1=0.95 across optimizers where applicable
  3. Token/iteration matching done via scaling-law fit (a+bN^{-beta}) across four fractional-data SOAP reruns (0.5, 0.625, 0.75, 0.875 of full run) rather than a single fixed-token comparison
  4. Batch-size ablation (256K vs 2M tokens) to check the large-batch-regime dependence of the claimed gain
  5. Preconditioning-frequency ablation (f swept) isolating the cost/quality tradeoff shared by Shampoo and SOAP

Nora row-orthogonal optimizer

P0Score 0.61needs review

Changing eligible decoder matrix-parameter updates to Nora row-orthogonal momentum projection plus row-wise normalized updates should improve held-out base-model loss under matched pretraining tokens or matched measured FLOPs because it ...

Evidence

Nora is a matrix optimizer for autoregressive LLaMA-style pretraining that projects momentum row-wise onto the orthogonal complement of each weight row, row-normalizes the projected direction, and updates with a width-scaled learning rat...

View details
Idea details

Nora row-orthogonal optimizer

Lifecycleneeds review
PriorityP0
Score0.61
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible decoder matrix-parameter updates to Nora row-orthogonal momentum projection plus row-wise normalized updates should improve held-out base-model loss under matched pretraining tokens or matched measured FLOPs because it preserves scale-invariant angular learning while approximating Muon-like row-block preconditioning at lower update cost.

Evidence

Nora is a matrix optimizer for autoregressive LLaMA-style pretraining that projects momentum row-wise onto the orthogonal complement of each weight row, row-normalizes the projected direction, and updates with a width-scaled learning rate. The source claims this preserves scale-invariant angular learning, approximates Transformer row-block preconditioning, and is faster than heavier matrix optimizers.

Current evidence
  • internal repository analysisTitan repository analysis: Nora row-orthogonal optimizer

    Nora is locally implementable as a small Muon-family optimizer mode rather than a model change. The target tree already has the required matrix-group split, DTensor gather/compute/scatter path, checkpoint state plumbing, and local tiny/1...

  • arxivRMNP: Row-Momentum Normalized Preconditioning for Scalable Matrix-Based Optimization

    Preconditioned adaptive methods have gained significant attention for training deep neural networks, as they capture rich curvature information of the loss landscape. The central challenge in this field lies in balancing preconditioning ...

  • arxivNora: Normalized Orthogonal Row Alignment for Scalable Matrix Optimizer

    Matrix-based optimizers have demonstrated immense potential in training Large Language Models (LLMs), however, designing an ideal optimizer remains a formidable challenge. A superior optimizer must satisfy three core desiderata: efficien...

  • internal implementation failureImplementation failure: Nora row-orthogonal optimizer

    Implementation audit requested repair: Off-switch must reverse enabling override paths: optimizer.init_args.muon.nora_lr_scale; Activation is invalid: `activation_validation_error` states the off-switch does not reverse the enabling over...

1 earlier records are available in the full idea history.

Required controls
  1. Titan baseline optimizer assignment with current Muon or AdamW matrix groups unchanged
  2. Matched 3000 optimizer updates and equal token budget on the canonical 1B-total, 100M-active MoE local protocol
  3. Same seed and data order when practical, with repeated baseline if local variance is not already calibrated
  4. Separate control for weight decay: compare Nora weight_decay=0 against baseline matrix optimizer both with its canonical decay and with weight_decay=0 where applicable
  5. Tune only Nora matrix learning rate on a small predefined grid while holding non-matrix Adam settings fixed

Spectrum-preserving Pion optimizer

P0Score 0.58needs review

Changing eligible decoder matrix optimization from additive Muon or AdamW updates to Pion spectrum-preserving orthogonal equivalence updates should improve held-out base-model loss under matched pretraining tokens or matched measured FLO...

Evidence

Pion is an optimizer that updates weight matrices by orthogonal left/right transformations, preserving singular values during training. The source's final variant combines RMS-controlled scaling, Lie-algebra first- and second-order momen...

View details
Idea details

Spectrum-preserving Pion optimizer

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible decoder matrix optimization from additive Muon or AdamW updates to Pion spectrum-preserving orthogonal equivalence updates should improve held-out base-model loss under matched pretraining tokens or matched measured FLOPs because weights can rotate their input/output geometry while preserving singular spectra and stabilizing norm growth.

Evidence

Pion is an optimizer that updates weight matrices by orthogonal left/right transformations, preserving singular values during training. The source's final variant combines RMS-controlled scaling, Lie-algebra first- and second-order momentum, alternating-side updates, and a second-order matrix-exponential approximation. It reports 60M design studies, muP transfer checks, and 1.3B LLaMA pretraining on C4 where Pion is comparable to Muon in validation loss and better than AdamW, plus out-of-scope fine-tuning/RL evidence.

Current evidence
  • internal repository analysisTitan repository analysis: Spectrum-preserving Pion optimizer

    Pion is locally plausible but not already present in the target tree. The smallest repo change is an optimizer-stack addition modeled on Muon: reuse post-parallelization parameter grouping, preserve Adam fallback for ineligible params, a...

  • arxivPion: A Spectrum-Preserving Optimizer via Orthogonal Equivalence Transformation

    We introduce Pion, a spectrum-preserving optimizer for large language model (LLM) training based on orthogonal equivalence transformation. Unlike additive optimizers such as Adam and Muon, Pion updates each weight matrix through left and...

  • internal implementation failureImplementation failure: Spectrum-preserving Pion optimizer

    Implementation audit requested repair: Trusted check touched_tests failed: -> None:\n init_args = {\n \"enable_pion\": True,\n \"pion\": asdict(PionHparams()),\n \"adam_lr_scale\": 0.25,\n }...

12 earlier records are available in the full idea history.

Required controls
  1. Titan baseline optimizer and schedule at equal tokens and same seed/data order
  2. Muon-only control with Titan's current tuned Muon settings at equal tokens
  3. Measured active FLOPs and optimizer overhead for Pion versus Muon/AdamW
  4. Keep model, data, tokenizer, objective, batch, warmup/cooldown, and parameter count fixed except optimizer assignment

MONA: Muon Optimizer with Nesterov Acceleration for Scalable Language Model Training

P0Score 0.58needs review

Source claim to test: The Muon optimizer has recently offered a promising alternative to AdamW for large language model training, leveraging matrix orthogonalization to produce geometry-aware updates.

Evidence

The Muon optimizer has recently offered a promising alternative to AdamW for large language model training, leveraging matrix orthogonalization to produce geometry-aware updates. However, like all first-order methods, Muon can become tra...

View details
Idea details

MONA: Muon Optimizer with Nesterov Acceleration for Scalable Language Model Training

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Source claim to test: The Muon optimizer has recently offered a promising alternative to AdamW for large language model training, leveraging matrix orthogonalization to produce geometry-aware updates.

Evidence

The Muon optimizer has recently offered a promising alternative to AdamW for large language model training, leveraging matrix orthogonalization to produce geometry-aware updates. However, like all first-order methods, Muon can become trapped in sharp local minima. In this work, we present MONA, an optimizer that bridges Muon's orthogonalization framework with curvature-aware acceleration. MONA adds an acceleration term directly into Muon's gradient processing pipeline. This term is calculated from the exponential moving average of gradient differences. We provide a detailed convergence analysis for MONA, showing that the acceleration term enables escape from sharp minima while preserving Muon's spectral-norm regularization. Empirically, MONA achieves better convergence and downstream task performance compared to both Muon and AdamW across three scales of Mixture-of-Experts pretraining, spanning from 1B to 68B parameters, with the largest model trained on 1 trillion tokens. Furthermore, we conduct supervised fine-tuning on the MOE-68B-A3B model and evaluate it on general capability, mathematical reasoning, and code generation benchmarks, where MONA achieves SOTA performance.

Current evidence
  • internal repository analysisTitan repository analysis: MONA: Muon Optimizer with Nesterov Acceleration for Scalable Language Model Training

    MONA is locally implementable as a scoped extension of the existing Muon optimizer path: add an optional pre-orthogonalization gradient-difference acceleration EMA before the current Muon momentum/Nesterov/Newton-Schulz pipeline, leaving...

  • arxivMONA: Muon Optimizer with Nesterov Acceleration for Scalable Language Model Training

    The Muon optimizer has recently offered a promising alternative to AdamW for large language model training, leveraging matrix orthogonalization to produce geometry-aware updates. However, like all first-order methods, Muon can become tra...

  • arxivMONA: Muon Optimizer with Nesterov Acceleration for Scalable Language Model Training

    The Muon optimizer has recently offered a promising alternative to AdamW for large language model training, leveraging matrix orthogonalization to produce geometry-aware updates. However, like all first-order methods, Muon can become tra...

  • internal implementation failureImplementation failure: MONA: Muon Optimizer with Nesterov Acceleration for Scalable Language Model Training

    Implementation audit requested repair: Off-switch must reverse enabling override paths: optimizer.init_args.muon.mona_accel_dtype, optimizer.init_args.muon.mona_beta_a; Activation is not valid for launch: `activation_validation_error` re...

4 earlier records are available in the full idea history.

Required controls
  1. define a matched baseline and smallest falsifying test

Dynamic hyper-connections residual replacement

P0Score 0.58needs review

Changing decoder Transformer residual joins to dynamic hyper-connections with expansion rate 4 should improve held-out base-model loss under matched pretraining tokens because learned depth-connection weights can mix Pre-Norm-like long-r...

Evidence

Hyper-connections replace fixed residual joins with trainable static and dynamic depth-connection weights over expanded hidden streams. The source reports decoder LM pretraining experiments on dense OLMo-style models and OLMoE, with DHC ...

View details
Idea details

Dynamic hyper-connections residual replacement

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing decoder Transformer residual joins to dynamic hyper-connections with expansion rate 4 should improve held-out base-model loss under matched pretraining tokens because learned depth-connection weights can mix Pre-Norm-like long-range feature preservation with Post-Norm-like decay and reduce representation collapse without severe gradient loss.

Evidence

Hyper-connections replace fixed residual joins with trainable static and dynamic depth-connection weights over expanded hidden streams. The source reports decoder LM pretraining experiments on dense OLMo-style models and OLMoE, with DHC variants improving validation loss over residual baselines at 500B tokens and ablations indicating expansion rate, dynamic connections, tanh, and trainable connection parameters matter.

Current evidence
  • internal repository analysisTitan repository analysis: Dynamic hyper-connections residual replacement

    A local Titan implementation is architecture-level, not config-only. The smallest target is TransformerMoEBlock in the MoE-specific model path: the current code hard-codes PreNorm residual additions around attention and MoE/FFN branches,...

  • github issueAgent MoE Experiment: July-baseline Identity Hyper-Connections

    <!-- experiment-tldr:start --> ## Summary This experiment tested four-stream Identity Hyper-Connections on the real July MoE baseline while keeping the baseline architecture, optimizer, data, and compute-optimal schedules fixed. The fir...

  • github repositoryaHapBean/xHC

    [Tech Report] Expanded Hyper-Connections <div align="center"> <h1>xHC: Expanded Hyper-Connections</h1> <p><strong>Scale Residual Streams Wider ? Push Model Intelligence Further</strong></p> <p> <a href="https://arxiv.org/abs/2607.1...

4 earlier records are available in the full idea history.

Required controls
  1. Matched baseline residual-connection Transformer/MoE with same data, tokenizer, optimizer, schedule, sequence length, and token budget.
  2. Equal 3000-step local token budget and identical seed/data order when practical.
  3. Report measured active FLOPs, parameter count, activation memory, and throughput so the small overhead is interpreted separately from equal-token loss.
  4. Control must include the same output-module initialization policy except for changes mathematically required to preserve initial output variance under hyper-connections.

LITE flat-direction Muon

P0Score 0.58needs review

Changing eligible Muon matrix-block updates to LITE flat-direction damping and learning-rate amplification should improve held-out decoder pretraining loss at matched tokens or matched measured FLOPs because the optimizer increases progr...

Evidence

LITE modifies adaptive matrix optimizers such as Muon and SOAP by identifying sharp versus flat directions and increasing damping or learning-rate amplification in flat directions. The source reports decoder-only pretraining experiments ...

View details
Idea details

LITE flat-direction Muon

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible Muon matrix-block updates to LITE flat-direction damping and learning-rate amplification should improve held-out decoder pretraining loss at matched tokens or matched measured FLOPs because the optimizer increases progress along flat, loss-reducing directions while preserving sharper directions more conservatively.

Evidence

LITE modifies adaptive matrix optimizers such as Muon and SOAP by identifying sharp versus flat directions and increasing damping or learning-rate amplification in flat directions. The source reports decoder-only pretraining experiments across dense and MoE models, datasets, schedules, and 130M-1.3B scales, with Muon-LITE and SOAP-LITE improving training dynamics over their baselines.

Current evidence
  • internal repository analysisTitan repository analysis: LITE flat-direction Muon

    Titan already has a suitable optimizer-local insertion point for LITE inside poolside.titan.optimizers.Muon: eligible 2D non-output/non-embedding parameters are split into Muon groups, gathered to full DTensor blocks, transformed by Newt...

  • arxivAccelerating LLM Pre-Training through Flat-Direction Dynamics Enhancement

    Pre-training Large Language Models requires immense computational resources, making optimizer efficiency essential. The optimization landscape is highly anisotropic, with loss reduction driven predominantly by progress along flat directi...

  • arxivAccelerating LLM Pre-Training through Flat-Direction Dynamics Enhancement

    Pre-training Large Language Models requires immense computational resources, making optimizer efficiency essential. The optimization landscape is highly anisotropic, with loss reduction driven predominantly by progress along flat directi...

1 earlier records are available in the full idea history.

Required controls
  1. Baseline: Titan's current Muon optimizer recipe with identical model, data, tokenizer, schedule family, batch, sequence length, and training horizon.
  2. Token match: primary local falsifier uses the same optimizer steps and tokens as control; report measured throughput and optimizer overhead separately.
  3. Seed policy: use the same seed for candidate and control when practical; require matched repeated seeds if the effect is near baseline variance.
  4. Intervention isolation: change only eligible matrix-block optimizer update to LITE acceleration; AdamW fallback parameters remain unchanged unless explicitly audited.
  5. Hyperparameter control: preregister Muon-LITE-H style settings from the source record, including r_s=0.1, beta1=-0.25, beta2=2.0, output block excluded, and no extra schedule retuning beyond the baseline peak LR unless a tuning control is run.
  6. Compute confound: report equal-token loss and measured equal-FLOP interpretation because projection and threshold logic may alter optimizer wall time.

ScheduleFree+ optimizer

P0Score 0.58needs review

Changing scheduled AdamW/WSD training to ScheduleFree+ should improve held-out decoder pretraining loss under matched tokens because Polyak/adaptive schedule-free iterate averaging can avoid horizon-specific decay choices while stabilizi...

Evidence

ScheduleFree+ is a schedule-free, learning-rate-free optimizer recipe for LLM pretraining. It keeps separate gradient-evaluation and output iterate sequences, uses adaptive Polyak or inverse-gradient-norm step sizing, adds inner momentum...

View details
Idea details

ScheduleFree+ optimizer

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing scheduled AdamW/WSD training to ScheduleFree+ should improve held-out decoder pretraining loss under matched tokens because Polyak/adaptive schedule-free iterate averaging can avoid horizon-specific decay choices while stabilizing large-batch training with inner momentum and delayed averaging.

Evidence

ScheduleFree+ is a schedule-free, learning-rate-free optimizer recipe for LLM pretraining. It keeps separate gradient-evaluation and output iterate sequences, uses adaptive Polyak or inverse-gradient-norm step sizing, adds inner momentum for large-batch stability, delays iterate averaging during warmup, and uses long-run averaging weights. The source claims better loss than WSD or tuned linear-decay schedules, especially for long-duration training.

Current evidence
  • internal repository analysisTitan repository analysis: ScheduleFree+ optimizer

    ScheduleFree+ is not implemented in the inspected snapshot. The local insertion point is the optimizer/training-loop boundary, not model code: OptimizersContainer already owns parameter grouping, checkpoint state remapping, and scheduler...

  • arxivScheduleFree+: Scaling Learning-Rate-Free & Schedule-Free Learning to Large Language Models

    Schedule-Free Learning has shown promise as a practical anytime training method for machine learning, showing success across dozens of standard benchmark problems. However, strong performance for LLM training has only been demonstrated a...

Required controls
  1. Compare against Titan's current tuned WSD/trapezoidal or production baseline optimizer schedule at identical model, data, tokenizer, batch, sequence length, and total tokens.
  2. Run same seed for candidate and control when practical; use existing baseline variance or a repeated control if the loss delta is small.
  3. Keep optimizer family and parameter grouping as close as possible except for the ScheduleFree+ state/update rule, gradient-evaluation point, step-size adaptation, and averaging/output semantics.
  4. Report equal-token primary result and measured training FLOPs/throughput because the optimizer may change step overhead and evaluation/checkpoint handling.

Head-wise value RMSNorm

P0Score 0.58needs review

Changing causal attention to apply head-wise RMSNorm after value aggregation should improve held-out decoder pretraining loss under matched tokens because it reduces position-wise variance discrepancy that drives attention sinks and earl...

Evidence

The source argues that causal value aggregation creates position-wise variance discrepancy that is amplified by early FFN super neurons, producing attention sinks. It proposes head-wise RMSNorm after attention value aggregation while ret...

View details
Idea details

Head-wise value RMSNorm

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing causal attention to apply head-wise RMSNorm after value aggregation should improve held-out decoder pretraining loss under matched tokens because it reduces position-wise variance discrepancy that drives attention sinks and early-layer representation outliers.

Evidence

The source argues that causal value aggregation creates position-wise variance discrepancy that is amplified by early FFN super neurons, producing attention sinks. It proposes head-wise RMSNorm after attention value aggregation while retaining standard softmax attention, and reports faster convergence in 152M Llama-2-style scratch pretraining on OpenWebText compared with a baseline and sigmoid-attention variant.

Current evidence
  • internal repository analysisTitan repository analysis: Head-wise value RMSNorm

    The mechanism is locally implementable in the MoE Attention path: both TE and Flex backends return the aggregated per-head value output before Titan applies gating and wo. The smallest code change is a disabled-by-default per-head RMSNor...

  • arxivThe Structural Origin of Attention Sink: Variance Discrepancy, Super Neurons, and Dimension Disparity

    Despite the prevalence of the attention sink phenomenon in Large Language Models (LLMs), where initial tokens disproportionately monopolize attention scores, its structural origins remain elusive. This work provides a \textit{mechanistic...

  • arxivThe Structural Origin of Attention Sink: Variance Discrepancy, Super Neurons, and Dimension Disparity

    Despite the prevalence of the attention sink phenomenon in Large Language Models (LLMs), where initial tokens disproportionately monopolize attention scores, its structural origins remain elusive. This work provides a \textit{mechanistic...

Required controls
  1. Exact Titan baseline architecture at the same total tokens and same data order where practical
  2. Same seed policy: matched seed for candidate/control plus repeat if baseline variance is not already calibrated
  3. Match token budget at 3000 steps and report measured throughput/active FLOPs for the added normalization
  4. Keep optimizer, LR schedule, tokenizer, data mixture, RoPE, QK norms, MLPs, and attention masks unchanged
  5. Compare against existing Peri-LN output RMSNorm idea results if available to separate attention-value normalization from generic branch-output normalization

Coordinate-first Zeta whitening optimizer

P0Score 0.58needs review

Changing eligible matrix-parameter updates from plain Muon-style spectral whitening to Zeta's coordinate-whitening-then-spectral-whitening update should improve held-out decoder pretraining loss under matched tokens or matched measured F...

Evidence

Zeta is a matrix-aware optimizer that first whitens coordinate-wise scale heterogeneity in momentum matrices and then applies Muon-like Newton-Schulz spectral whitening. The source argues that coordinate whitening improves the conditioni...

View details
Idea details

Coordinate-first Zeta whitening optimizer

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible matrix-parameter updates from plain Muon-style spectral whitening to Zeta's coordinate-whitening-then-spectral-whitening update should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because coordinate scale homogenization conditions the momentum matrix before Newton-Schulz orthogonalization.

Evidence

Zeta is a matrix-aware optimizer that first whitens coordinate-wise scale heterogeneity in momentum matrices and then applies Muon-like Newton-Schulz spectral whitening. The source argues that coordinate whitening improves the conditioning required for reliable orthogonalization and reports language-model pretraining comparisons against AdamW, Muon, and AdaMuon across GPT2-Large, Qwen3 dense models up to 8B, and Qwen3-MoE.

Current evidence
  • internal repository analysisTitan repository analysis: Coordinate-first Zeta whitening optimizer

    Titan has a clear optimizer boundary for this idea: Muon already owns matrix-parameter momentum, Newton-Schulz whitening, distributed sharded gather/scatter, replica broadcasts, checkpoint state, and Adam fallback. The smallest repo chan...

  • arxivZeta: Dual Whitening for Matrix Optimization via Coordinate-Adaptive Preconditioning

    Large-scale neural network training increasingly relies on matrix-aware optimizers that exploit the structure of weight parameters beyond element-wise adaptation. However, existing matrix-aware methods such as Muon have an underappreciat...

  • arxivZeta: Dual Whitening for Matrix Optimization via Coordinate-Adaptive Preconditioning

    Large-scale neural network training increasingly relies on matrix-aware optimizers that exploit the structure of weight parameters beyond element-wise adaptation. However, existing matrix-aware methods such as Muon have an underappreciat...

1 earlier records are available in the full idea history.

Required controls
  1. Titan baseline optimizer assignment at identical model, data, tokenizer, batch, schedule, weight decay, and token budget
  2. Compare against the current Titan Muon or AdamW/Muon hybrid control at the same seed when practical
  3. Report equal-token primary result and measured optimizer-step throughput/FLOPs for equal-compute interpretation
  4. Keep all non-optimizer architecture, objective, routing, and schedule settings unchanged

Hashed n-gram conditional memory

P0Score 0.58needs review

Changing a decoder MoE by reallocating part of the sparse expert parameter budget to hashed n-gram Engram conditional memory should improve held-out base-model loss under matched tokens and active FLOPs because local static dependencies ...

Evidence

Engram adds a large hashed n-gram embedding memory to a decoder MoE as a second sparsity axis. Local compressed token n-grams deterministically address sparse memory rows, and context-aware gating/fusion injects the retrieved representat...

View details
Idea details

Hashed n-gram conditional memory

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing a decoder MoE by reallocating part of the sparse expert parameter budget to hashed n-gram Engram conditional memory should improve held-out base-model loss under matched tokens and active FLOPs because local static dependencies can be served by O(1) lookup, freeing attention and MoE depth for compositional computation.

Evidence

Engram adds a large hashed n-gram embedding memory to a decoder MoE as a second sparsity axis. Local compressed token n-grams deterministically address sparse memory rows, and context-aware gating/fusion injects the retrieved representation into selected layers. The source reports that reallocating about 20%-25% of sparse parameter budget from MoE experts to Engram improves validation loss in allocation sweeps and that a 27B Engram model beats an iso-parameter and iso-FLOPs MoE baseline on downstream benchmarks.

Current evidence
  • internal repository analysisTitan repository analysis: Hashed n-gram conditional memory

    The target snapshot has no Engram implementation or config toggle. The smallest Titan-native path is to add Engram as an optional TransformerMoE submodule, not as a wrapper, so existing class-path dispatch, trainer type checks, running s...

  • github repositorydeepseek-ai/Engram

    Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models <!-- markdownlint-disable first-line-h1 --> <!-- markdownlint-disable html --> <!-- markdownlint-disable no-duplicate-header --> <div align="cente...

  • arxivConditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models

    While Mixture-of-Experts (MoE) scales capacity via conditional computation, Transformers lack a native primitive for knowledge lookup, forcing them to inefficiently simulate retrieval through computation. To address this, we introduce co...

Required controls
  1. Compare against Titan MoE baseline with identical data, tokenizer, seed where practical, token budget, optimizer schedule, active FLOPs, total parameters, and routed expert active compute accounting.
  2. Use an equal-token 3000-step local pilot and report measured FLOPs/TPS so any memory-lookup overhead or routed-expert reduction is accounted for.
  3. Include a parameter/FLOP-matched MoE control that reallocates Engram parameters back into routed experts, matching the source's rho=100% baseline.
  4. Hold all non-memory architecture choices fixed; if Titan lacks mHC multi-branch wiring, test the smallest Titan-native residual injection and mark branch-fusion mismatch as a confound.

MERIT max-norm element-wise trust ratio optimizer

P0Score 0.58needs review

Changing the matrix-parameter optimizer from AdamW/LAMB to MERIT's max-norm plus element-wise trust-ratio update should improve held-out decoder pretraining loss at matched tokens and batch size because directly bounding the max attentio...

Evidence

Proposes MERIT, an Adam/LAMB-family optimizer for large-batch causal-LM pretraining. It replaces LAMB's l2-norm layer-wise trust ratio with a max-norm-based trust ratio (to directly bound max attention logit growth in attention Q/K weigh...

View details
Idea details

MERIT max-norm element-wise trust ratio optimizer

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing the matrix-parameter optimizer from AdamW/LAMB to MERIT's max-norm plus element-wise trust-ratio update should improve held-out decoder pretraining loss at matched tokens and batch size because directly bounding the max attention-logit-driving weight magnitudes reduces attention entropy collapse and yields more robust local update scaling than LAMB's l2-norm-based, weight-wise trust ratio.

Evidence

Proposes MERIT, an Adam/LAMB-family optimizer for large-batch causal-LM pretraining. It replaces LAMB's l2-norm layer-wise trust ratio with a max-norm-based trust ratio (to directly bound max attention logit growth in attention Q/K weights) plus element-wise trust ratios and element-wise update clipping (magnitude <=1) for finer local scaling. Tested on GPT-2 (125M/355M/770M) and Llama (130M/350M) trained from scratch on OpenWebText/C4 at Chinchilla-optimal token budgets, comparing MERIT against AdamW, LAMB, Lion, and Sophia-G with grid-searched LR and fixed weight decay 0.1. Reports lower validation loss/perplexity and better LAMBADA/WikiText zero-shot scores, and shows MERIT sustains a 6k batch size on GPT-2 Medium without degradation versus the 480-batch AdamW baseline. Includes a nonconvex convergence proof and open-source code.

Current evidence
  • internal repository analysisTitan repository analysis: MERIT max-norm element-wise trust ratio optimizer

    MERIT is a moderate optimizer-only integration, not a model or trainer rewrite. Titan's current baseline already routes matrix parameters to Muon and scalar/embedding/output parameters to Adam fallback through optimizer container groupin...

  • arxivMERIT: Maximum-normalized Element-wise Ratio for Language Model Large-batch Training

    Large-batch training has become a cornerstone in accelerating the training of deep neural networks, yet it poses challenges in optimization and generalization. Existing optimizers like AdamW present performance degradation during languag...

  • github repositoryNUS-HPC-AI-Lab/MERIT

    <h1 align="center">MERIT Optimizer</h1> <h3 align="center">ICML 2025 | <a href="https://openreview.net/forum?id=NSxKNNFni0">Paper</a></h3> This is an official implementation of **MERIT** optimizer in the "MERIT: Maximum-normalized Eleme...

Required controls
  1. Fixed weight decay 0.1 across all compared optimizers
  2. Per-optimizer LR chosen via grid search
  3. Matched total training tokens per Chinchilla-optimal allocation per model size
  4. Same context length (1024), gradient clip norm 1.0, warmup ratio 0.02, cosine LR schedule with final LR 0.1x peak
  5. bf16 training on H100 GPUs
  6. For the Llama comparison, batch size is held fixed across AdamW/LAMB/MERIT (unlike the GPT-2 large-batch headline comparison)

Gated associative successor memory

P0Score 0.58needs review

Changing causal dense attention to a gated associative successor-memory path should improve held-out decoder pretraining loss under matched tokens because bounded content-addressed retrieval can recover useful long-context successor evid...

Evidence

PCAF replaces dense causal attention with a local parametric path plus an in-context associative successor cache. It writes local causal records into hash buckets, retrieves a bounded candidate set for each query, converts retrieved reco...

View details
Idea details

Gated associative successor memory

Lifecycleneeds review
PriorityP0
Score0.58
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing causal dense attention to a gated associative successor-memory path should improve held-out decoder pretraining loss under matched tokens because bounded content-addressed retrieval can recover useful long-context successor evidence without forcing every token pair through quadratic attention.

Evidence

PCAF replaces dense causal attention with a local parametric path plus an in-context associative successor cache. It writes local causal records into hash buckets, retrieves a bounded candidate set for each query, converts retrieved records into a sparse next-token cache distribution, and mixes that distribution with the parametric model using a learned gate. The source reports lower autoregressive validation perplexity and higher throughput than dense and local attention baselines at 303M parameters on WikiText-103 and PG-19, with smaller ablations supporting the cache and gate.

Current evidence
  • internal repository analysisTitan repository analysis: Gated associative successor memory

    PCAF is not present in the target Titan snapshot, but the natural implementation boundary is clear: add config fields and a PCAF module, then integrate it at the TransformerMoE logit path so cache probabilities can be mixed with the para...

  • github repositoryahmed123hds/PCAF

    # Parallel Causal Associative Fields (PCAF) This repository contains the PCAF architecture, CUDA/Triton and JAX/TPU implementations, language and vision experiments, reproducibility scripts, and the accompanying paper. [Conference manu...

  • arxivParallel Causal Associative Fields: Gated Sparse Memory for Long-Context Language Modeling

    Transformers achieve strong language modeling performance by providing direct token-to-token communication paths, but causal self-attention scales quadratically with context length. Recurrent and state-space models reduce this cost, yet ...

  • internal implementation failureImplementation failure: Gated associative successor memory

    Implementation audit requested repair: Off-switch must reverse enabling override paths: model.init_args.config.pcaf_candidate_mode, model.init_args.config.pcaf_context_order, model.init_args.config.pcaf_fixed_cache_weight, model.init_arg...

1 earlier records are available in the full idea history.

Required controls
  1. Titan dense/MoE baseline with identical data, tokenizer, sequence length, optimizer, schedule, seed, and 3000-step token budget
  2. Equal-token candidate replacing the target attention path with PCAF-style local parametric path plus associative successor cache and learned gate
  3. Measured-FLOP and throughput accounting so any speed gain is interpreted separately from held-out loss
  4. Same validation selection rule and no best-checkpoint cherry-pick beyond the matched control policy
  5. Ablate cache disabled and learned gate replaced by fixed mixture if the full candidate beats baseline

Position-adaptive recurrent decay spectra

P0Score 0.57needs review

Changing diagonal recurrent decoder layers to PoST geometric log-decay spectra with position-adaptive scaling should improve held-out base-model loss under matched tokens because better-conditioned decay channels preserve long-range memo...

Evidence

PoST modifies diagonal linear recurrent layers by enforcing geometrically structured log-decay spectra and scaling those spectra by position so channels cover the effective dependency range at each timestep. The source reports equal-hype...

View details
Idea details

Position-adaptive recurrent decay spectra

Lifecycleneeds review
PriorityP0
Score0.57
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing diagonal recurrent decoder layers to PoST geometric log-decay spectra with position-adaptive scaling should improve held-out base-model loss under matched tokens because better-conditioned decay channels preserve long-range memory without wasting channels at early positions.

Evidence

PoST modifies diagonal linear recurrent layers by enforcing geometrically structured log-decay spectra and scaling those spectra by position so channels cover the effective dependency range at each timestep. The source reports equal-hyperparameter and equal-compute language-model pretraining comparisons on FineWeb-Edu for Mamba-2, RWKV-7, and Gated DeltaNet at about 180M parameters, plus Mamba-2 at about 440M, with improvements described on zero-shot benchmarks and long-context retrieval.

Current evidence
  • internal repository analysisTitan repository analysis: Position-adaptive recurrent decay spectra

    Titan contains an experimental RWKV6/RWKV7 recurrent path with diagonal decay parameters, so PoST has a plausible host module. It is not applicable to the standard TransformerMoE tiny or 17B baselines as a simple field toggle. The smalle...

  • github repositorySiLifen/PoST

    Code for Position-Adaptive Spectral Tapering # Optimal Decay Spectra for Linear Recurrences Official implementation of **PoST (Position-Adaptive Spectral Tapering)** ? a principled spectral reparameterization and position-adaptive scal...

  • arxivOptimal Decay Spectra for Linear Recurrences

    Linear recurrent models offer linear-time sequence processing but often suffer from suboptimal long-range memory. We trace this to the decay spectrum: for $N$ channels, random initialization collapses the minimum spectral gap to $O(N^{-2...

Required controls
  1. Exact baseline match: same recurrent backbone with its default decay initialization and parameterization
  2. Token or FLOP match: equal training compute and data within each reported model pair; Titan falsifier should use equal tokens and report measured FLOPs
  3. Seed policy: same seed when practical, otherwise matched seed sets for candidate and control
  4. Intervention-specific confound: separate PoST's spectral reparameterization from position-adaptive scaling if the full candidate wins

Cross-head K/V MEA attention

P0Score 0.56needs reviewEarlier smoke passed; retest pending

Changing decoder causal attention to MEA with separate cross-head linear combinations over K and V plus head-level GroupNorm should improve held-out base-model loss under matched pretraining tokens because explicit inter-head communicati...

Evidence

Multi-head Explicit Attention adds learnable cross-head linear combinations for key and value vectors plus head-level GroupNorm/RMSNorm. The supplied evidence reports decoder LM from-scratch pretraining comparisons at a LLaMA3.2-1B-style...

Recovery completed (not a scientific result)
100.0%300 / 300 (100.0%)Training loss 3.17 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.170267 vs control 3.279997 (delta -0.109730). No 3000-step pair was launched.

Recovery next

Do not modify the candidate diff (016830f35cb93c95f9c16395d88c0a2c6b0e3702) ? it is not implicated, since mea_attention=false in this run's resolved_configuration and the diff touches no file in the failing call chain. Instead, escalate ...

View details
Idea details

Cross-head K/V MEA attention

Lifecycleneeds review
PriorityP0
Score0.56
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.17 at step 300
Matched baseline

probe-dp4-control_8713f1fc97a938a9763f

Directional gate

Global loss gate did not pass: candidate 3.170267 vs control 3.279997 (delta -0.109730). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Recovery next

Do not modify the candidate diff (016830f35cb93c95f9c16395d88c0a2c6b0e3702) ? it is not implicated, since mea_attention=false in this run's resolved_configuration and the diff touches no file in the failing call chain. Instead, escalate to the owner of poolside/titan/models/moe/routers.py and poolside/titan/training_helpers.py to verify that cache_ema_weight_refs() is invoked for every model part / every data-parallel replica (not just one) before the first update_model_ema() call, specifically checking behavior under this run's exact topology: pipeline_parallel_degree=3, data_parallel_shard_degree=2, world_size=6 (gpu_indices [0,2,3,4,5,6]), where ranks 3-5 (the second DP replica) hit the assertion at routers.py:301 while ranks 0-2's fate is not visible in the truncated log tail (training.log, sha256 a47eb6c0a18b187c8e15026ec0375b443197247c57000c2905b9a5e477900702). Before any retry, an operator should pull the full untruncated training.log to confirm whether ranks 0-2 also failed, an

Test history

An earlier implementation passed its distributed smoke. The corrected build must finish and pass a new smoke before this card returns to Smoke / Local Test.

Evidence, sources, and controls
Hypothesis

Changing decoder causal attention to MEA with separate cross-head linear combinations over K and V plus head-level GroupNorm should improve held-out base-model loss under matched pretraining tokens because explicit inter-head communication can share key/value evidence across heads while normalization prevents the cross-head transform from degenerating during training.

Evidence

Multi-head Explicit Attention adds learnable cross-head linear combinations for key and value vectors plus head-level GroupNorm/RMSNorm. The supplied evidence reports decoder LM from-scratch pretraining comparisons at a LLaMA3.2-1B-style scale, with MEA showing lower fitted test loss and greater tolerance for large learning rates than standard attention and related ablations.

Current evidence
  • internal repository analysisTitan repository analysis: Cross-head K/V MEA attention

    The target tree does not contain MEA yet, but the implementation boundary is clear: TransformerMoE Attention plus its MoE TP plan and focused tests. The local tiny baseline can use a generated candidate config derived from scripts/runs/t...

  • internal failure diagnosisTraining failure diagnosis: Cross-head K/V MEA attention

    The candidate diff (commit 79be221c, base 14048b8a) adds mea_attention to poolside/titan/models/transformer_moe.py. In Attention.init_weights (transformer_moe.py:1131-1136), when self.mea_attention is True, the code does `self.mea_k_head...

  • arxivExplicit Multi-head Attention for Inter-head Interaction in Large Language Models

    In large language models built upon the Transformer architecture, recent studies have shown that inter-head interaction can enhance attention performance. Motivated by this, we propose Multi-head Explicit Attention (MEA), a simple yet ef...

  • internal implementation failureImplementation failure: Cross-head K/V MEA attention

    Implementation audit requested repair: Trusted host verification is not green for the current candidate: `host_verification.verified` is false and the authoritative `touched_tests` check failed, including `tests/titan/test_config.py::tes...

8 earlier records are available in the full idea history.

Required controls
  1. Compare against Titan baseline attention with identical data, tokenizer, model size, optimizer, schedule family, token count, and seed.
  2. Run an equal-token control at 3000 optimizer steps with the same peak LR as the MEA candidate to isolate the module effect.
  3. Run a tuned-LR interpretation sweep only after the same-LR test, because the paper's main claim partly depends on larger stable LR.
  4. Match parameter count or report the exact extra HLC and GroupNorm parameters and include a parameter-matched control if non-negligible.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_9bd5f867cb7746c9
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
016830f35cb93c95f9c16395d88c0a2c6b0e3702
Branch
auto-research/idea_90da09ea90ff46c5/probe-dp4-candidate_c060f443d83e26be45a7
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_c060f443d83e26be45a7
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_c060f443d83e26be45a7.local.yaml
Config SHA-256 (recorded, unverified)
379f18f5a28044fd916642e1c493d73fdc91173b19a4f63b2c5a63cd25d59137
Actual config SHA-256
379f18f5a28044fd916642e1c493d73fdc91173b19a4f63b2c5a63cd25d59137
Resolved config SHA-256 (recorded, unverified)
29e4cc38cb5f91d5051ca411b1cb4f09c830b0d3063d53aaa3a2f642fdfccef1
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_c060f443d83e26be45a7.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

State-prediction token separation

P0Score 0.54needs review

Changing the decoder block/input format to State-Prediction Separation, where each real token is paired with a predict token that carries next-token loss under an SPS attention mask, should improve held-out base-model loss at matched tra...

Evidence

State-Prediction Separation interleaves each input token with a predict token sharing the same RoPE position, computes next-token loss only on predict positions, and uses a custom causal attention pattern so input tokens maintain state w...

View details
Idea details

State-prediction token separation

Lifecycleneeds review
PriorityP0
Score0.54
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing the decoder block/input format to State-Prediction Separation, where each real token is paired with a predict token that carries next-token loss under an SPS attention mask, should improve held-out base-model loss at matched training FLOPs because separating state maintenance from prediction may reduce interference between representation storage and next-token readout.

Evidence

State-Prediction Separation interleaves each input token with a predict token sharing the same RoPE position, computes next-token loss only on predict positions, and uses a custom causal attention pattern so input tokens maintain state while predict tokens perform readout. The source reports validation-loss and downstream gains at GPT-2 scales but identifies the key confound: the method costs about twice the training compute per real token, so the local test must be judged at matched FLOPs.

Current evidence
  • internal repository analysisTitan repository analysis: State-prediction token separation

    SPS is a substantial but locally implementable Titan change, not a YAML-only switch. The target tree has the needed MoE backbone, flex attention mask machinery, wrapper precedent in MTPTransformerMoE, and class-path parallel dispatch, bu...

  • internal repository analysisTitan repository analysis: State-prediction token separation

    SPS is implementable in this Titan snapshot, but it must be a real model wrapper plus attention/loss/parallelism work, not a YAML-only switch. The nearest safe pattern is MTPTransformerMoE: wrap TransformerMoE, explicitly forward MoE run...

  • internal repository analysisTitan repository analysis: State-prediction token separation

    SPS is implementable in this Titan snapshot, but not as a pure config toggle. The target MoE path is TransformerMoE through poolside.titan.parallelisms.parallelize_transformer_moe, with MTP providing the closest wrapper and parallelizati...

  • internal implementation failureImplementation failure: State-prediction token separation

    Implementation audit requested repair: Trusted check mypy failed: {"baseline": "{\"file\": \"tests/integration/dagster_launch_backend.py\", \"line\": 315, \"column\": 23, \"end_line\": 315, \"end_column\": 65, \"message\": \"Value of typ...

44 earlier records are available in the full idea history.

Required controls
  1. Compare against compute-optimal Grug ladder baselines at the same FLOP budgets, starting with d512 @ 2.19e17 and d768 @ 1.70e18.
  2. Match training FLOPs as the primary comparison; also report equal-real-token loss separately to expose the 2x per-token compute overhead.
  3. Use the same dataset, tokenizer, optimizer, LR schedule, batch policy, and evaluation loss stack as the baseline unless SPS mechanically requires different masking.
  4. Use matched seeds where practical, or repeat enough seeds to compare against measured local baseline variance.
  5. Keep predict-window w fixed for gate 1; sweep w only after the fixed-window SPS variant beats the matched-FLOP gate.
  6. Validate SPS attention masking against a dense-mask reference before any ladder run.
  7. Account for active sequence length, attention mask block skipping, and wall-clock throughput so a token-matched win is not mistaken for sample-efficiency.

Microbatch bias-corrected preconditioning

P0Score 0.54needs review

Changing AdamW/Sophia/Shampoo preconditioned updates to cross-fitted numerator/preconditioner estimates plus variance-corrected inverse preconditioning should improve held-out decoder pretraining loss under matched tokens or matched meas...

Evidence

The source argues that stochastic preconditioned optimizer updates are biased because the gradient and preconditioner are estimated from the same minibatch and because inverting a noisy preconditioner is nonlinear. It proposes cross-fitt...

View details
Idea details

Microbatch bias-corrected preconditioning

Lifecycleneeds review
PriorityP0
Score0.54
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing AdamW/Sophia/Shampoo preconditioned updates to cross-fitted numerator/preconditioner estimates plus variance-corrected inverse preconditioning should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because it reduces finite-sample gradient-preconditioner coupling and nonlinear inverse-estimator bias.

Evidence

The source argues that stochastic preconditioned optimizer updates are biased because the gradient and preconditioner are estimated from the same minibatch and because inverting a noisy preconditioner is nonlinear. It proposes cross-fitted microbatch preconditioning plus a delta-method inverse correction, reporting lower held-out pretraining loss for AdamW, Sophia-G, and Shampoo on Qwen2.5-0.5B FineWeb-Edu runs.

Current evidence
  • internal repository analysisTitan repository analysis: Microbatch bias-corrected preconditioning

    The repository can host this as an optimizer-layer AdamW-family experiment, but the exact local 1B implementation is blocked by an unresolved scientific/mechanical choice: Titan's current non-PP training path exposes only one aggregate b...

  • github repositoryfastino-ai/preconditioner-bias-correction

    # Bias-Corrected Preconditioned Optimization Reference implementation for the paper **"Correcting Stochastic Update Bias in Preconditioned Language Model Optimizers"** (Nayak et al., Fastino Labs). The code instantiates a single-batch b...

  • arxivCorrecting Stochastic Update Bias in Preconditioned Language Model Optimizers

    Preconditioned optimizers are central to language model training, but their stochastic update rules are usually treated as direct approximations to population preconditioned descent. We show that this view misses two finite-sample biases...

Required controls
  1. Exact baseline optimizer family match: standard AdamW, Sophia-G, or Shampoo against the corresponding bias-corrected variant
  2. Match training tokens and reported compute for the local falsifier; record throughput overhead separately
  3. Use matched model seed, data-order seed, tokenizer, data mixture, sequence length, LR schedule, weight decay, and batch size where practical
  4. Ablate cross-fit-only and inverse-correction-only to separate numerator/preconditioner decoupling from nonlinear inverse bias correction

Native hierarchical sparse attention

P0Score 0.52needs review

Changing decoder causal attention from full attention to NSA hierarchical trainable sparse attention should improve held-out base-model loss or quality-throughput tradeoff under matched pretraining tokens because compressed global contex...

Evidence

NSA replaces full attention with a trainable hierarchical sparse pattern that combines compressed global tokens, blockwise selected KV blocks, and a sliding local window, paired with hardware-aligned Triton kernels. The source reports a ...

View details
Idea details

Native hierarchical sparse attention

Lifecycleneeds review
PriorityP0
Score0.52
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing decoder causal attention from full attention to NSA hierarchical trainable sparse attention should improve held-out base-model loss or quality-throughput tradeoff under matched pretraining tokens because compressed global context, learned blockwise selection, and a local sliding window preserve salient long-range information while reducing attention compute.

Evidence

NSA replaces full attention with a trainable hierarchical sparse pattern that combines compressed global tokens, blockwise selected KV blocks, and a sliding local window, paired with hardware-aligned Triton kernels. The source reports a 27B-total / 3B-active MoE pretrained for 270B tokens where NSA has a smoother/lower pretraining loss curve than Full Attention and better long-context benchmark averages, while reducing long-context attention latency.

Current evidence
  • internal repository analysisTitan repository analysis: Native hierarchical sparse attention

    The target snapshot is not config-only ready for NSA. It has useful MiniMax sparse attention contract files and a clear MoE attention insertion point, but the sparse contracts and kernels are NotImplementedError and current backend dispa...

  • arxivNative Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention

    Long-context modeling is crucial for next-generation language models, yet the high computational cost of standard attention mechanisms poses significant computational challenges. Sparse attention offers a promising direction for improvin...

Required controls
  1. Full Attention baseline with same model size, data, tokenizer, token budget, optimizer, schedule, and seed when practical.
  2. Equal-token comparison at the fixed local 3000-step Titan protocol.
  3. Measured active FLOP and throughput accounting for NSA versus full attention; do not reschedule the primary local control unless a separate matched-FLOP protocol is preregistered.
  4. A sparse-attention confound control should preserve GQA, MoE, RoPE/YaRN, MLP, router, and all non-attention settings.

Hierarchical landmark sparse attention

P0Score 0.52needs review

Changing decoder causal attention from full attention to end-to-end learned hierarchical landmark sparse attention should improve held-out base-model loss or equal-compute long-context quality under matched tokens or measured FLOPs becau...

Evidence

HiLS attention replaces dense causal attention with chunk-wise sparse retrieval learned through the language-modeling loss. Each chunk has a learnable landmark-derived summary; queries score chunk summaries, retrieve top-k chunks, attend...

View details
Idea details

Hierarchical landmark sparse attention

Lifecycleneeds review
PriorityP0
Score0.52
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing decoder causal attention from full attention to end-to-end learned hierarchical landmark sparse attention should improve held-out base-model loss or equal-compute long-context quality under matched tokens or measured FLOPs because LM-loss-trained chunk retrieval can select useful KV blocks more accurately than nonparametric sparse chunk selection while bounding attention compute.

Evidence

HiLS attention replaces dense causal attention with chunk-wise sparse retrieval learned through the language-modeling loss. Each chunk has a learnable landmark-derived summary; queries score chunk summaries, retrieve top-k chunks, attend within each retrieved chunk and a local window, then fuse chunk outputs using retrieval scores. The supplied evidence reports comparable perplexity to full attention, stronger long-context retrieval, a 1.4B from-scratch run on 300B tokens, and 7B continued-pretraining conversion results.

Current evidence
  • internal repository analysisTitan repository analysis: Hierarchical landmark sparse attention

    Inspection found no complete HiLS implementation in the target tree. The natural integration point is TransformerMoE Attention through build_attention_backend, with existing causal/document/SWA metadata and MoE parallelization available....

  • github repositoryTencent-Hunyuan/HiLS-Attention

    Official code for HiLS-Attention # HiLS-Attention: Hierarchical Sparse Attention Done Right Official code for the paper [Hierarchical Sparse Attention Done Right: Toward Infinite Context Modeling](https://arxiv.org/abs/2607.02980). <p...

  • arxivHierarchical Sparse Attention Done Right: Toward Infinite Context Modeling

    Scaling modern large language models (LLMs) to long contexts is limited by the quadratic computation cost, and poor length extrapolation of dense attention. Chunk-wise sparse attention offers a promising alternative, but all existing met...

Required controls
  1. Matched full-attention decoder baseline with same tokenizer, corpus mixture, sequence length, training steps, optimizer, and seed where practical.
  2. Equal-token primary comparison at 3000 steps; also report measured active FLOPs and throughput because sparse attention changes compute per token.
  3. Sparse-attention controls with the same local window, chunk size, and top-k retrieval budget, including NSA-style native sparse attention if available in Titan.
  4. Parameter-count control for the added landmark token embedding and W_up/W_down projections, or report the exact added parameter delta.
  5. Same synthetic-retrieval mixture policy in candidate and control, or exclude synthetic RULER-style examples for a base-loss-only local falsifier.

Column-normalized last-layer momentum SGD

P0Score 0.49needs review

Changing eligible decoder matrix optimization from Adam/Muon-style updates to SCALE column-normalized SGD with last-layer-only momentum should improve held-out base-model loss or memory-adjusted training efficiency under matched tokens o...

Evidence

The source proposes SCALE, a minimalist memory-efficient optimizer for LLM pretraining. Matrix parameters use column-wise gradient normalization instead of Adam moments, first-order momentum is applied only to the output layer, and vecto...

View details
Idea details

Column-normalized last-layer momentum SGD

Lifecycleneeds review
PriorityP0
Score0.49
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing eligible decoder matrix optimization from Adam/Muon-style updates to SCALE column-normalized SGD with last-layer-only momentum should improve held-out base-model loss or memory-adjusted training efficiency under matched tokens or matched measured FLOPs because column-wise gradient normalization supplies the essential adaptive scaling while avoiding most optimizer state.

Evidence

The source proposes SCALE, a minimalist memory-efficient optimizer for LLM pretraining. Matrix parameters use column-wise gradient normalization instead of Adam moments, first-order momentum is applied only to the output layer, and vector parameters remain on Adam. Reported C4 LLaMA experiments from 60M to 1B compare against Adam, Muon, GaLore, Fira, APOLLO, SWAN, and Adam Stable-SPAM, with a 7B 100B-token stability run.

Current evidence
  • internal repository analysisTitan repository analysis: Column-normalized last-layer momentum SGD

    SCALE is locally feasible as a scoped optimizer intervention. The smallest repository change is a new optimizer class plus optimizer-container grouping and package export; the model, data, loss, tokenizer, and parallelizer entry points c...

  • github repositoryOptimAI-Lab/Minimalist_LLM_Pretraining

    [ICML 2026] Memory-Efficient LLM Pretraining via Minimalist Optimizer Design # Memory-Efficient LLM Pretraining via Minimalist Optimizer Design (ICML 2026) <a href="https://arxiv.org/abs/2506.16659"> <img src="https://img.shields.io...

  • arxivMemory-Efficient LLM Pretraining via Minimalist Optimizer Design

    Training large language models (LLMs) relies on adaptive optimizers such as Adam, which introduce extra operations and require significantly more memory to maintain first- and second-order moments than SGD. While recent works such as GaL...

  • internal implementation failureImplementation failure: Column-normalized last-layer momentum SGD

    Implementation audit requested repair: Trusted check format_normalization failed: poolside/titan/optimizers/scale.py:39:22: UP038 Use `X | Y` in `isinstance` call instead of `(X, Y)` | 37 | if isinstance(placement, Sha...

3 earlier records are available in the full idea history.

Required controls
  1. Titan baseline optimizer matched exactly except for eligible optimizer assignment
  2. Equal-token 3000-step local run with same data order and seed for candidate and control
  3. Matched measured FLOP interpretation including optimizer-step overhead and throughput
  4. Control for vector parameters remaining on baseline Adam behavior in both runs
  5. LR sweep or preregistered small grid for SCALE LR versus the tuned Titan optimizer LR

Complete-muE MoE transfer

P0Score 0.49needs review

Changing MoE optimizer and initialization scaling to Complete-muE transfer rules should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because dense-calibrated hyperparameters transfer more relia...

Evidence

Complete-muE proposes a compositional hyperparameter-transfer rule for dense FFN, Dense MoE, and sparse MoE Transformer blocks. It combines active-width muP, normalized router scale, and expert-side SDE reasoning so dense-tuned initializ...

View details
Idea details

Complete-muE MoE transfer

Lifecycleneeds review
PriorityP0
Score0.49
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing MoE optimizer and initialization scaling to Complete-muE transfer rules should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because dense-calibrated hyperparameters transfer more reliably across active width, activated experts, total experts, and per-expert workload.

Evidence

Complete-muE proposes a compositional hyperparameter-transfer rule for dense FFN, Dense MoE, and sparse MoE Transformer blocks. It combines active-width muP, normalized router scale, and expert-side SDE reasoning so dense-tuned initialization and AdamW settings transfer across activated experts, total experts, granularity, shared experts, width, batch, and duration changes.

Current evidence
  • internal repository analysisTitan repository analysis: Complete-muE MoE transfer

    Complete-muE targets real Titan surfaces: MoE expert initialization, router score scaling, and optimizer LR/WD param-group plumbing. The target tree already has routed/shared/router parameter naming, regex LR/WD overrides, EGP/ETP/FSDP-a...

  • arxivComplete-muE: Optimal Hyperparameter Transfer and Scaling for MoE Models

    We propose Complete-muE, a framework which targets hyperparameter transfer across dense FFN and any Mixture-of-Experts (MoE) setups in transformer blocks. Existing tools such as $?$P (requires fixed architectue) or SDE (requires fixed pe...

Required controls
  1. Compare against the current Titan MoE baseline at identical tokens, optimizer steps, seed, data order, tokenizer, and model shape.
  2. Hold active FLOPs fixed when testing the Complete-muE optimizer/init transfer rule, or report measured FLOPs and throughput for compute interpretation.
  3. Include a tuned local AdamW/Muon baseline if the transferred recipe changes LR, WD, init, or router scale relative to Titan defaults.
  4. Use the same dense reference calibration for all candidate MoE variants, with no per-candidate retuning.

muP-scaled matrix optimizer transfer

P0Score 0.49needs review

Changing matrix-preconditioned optimizer hyperparameters to muP-scaled learning rates plus 1/width independent weight decay should improve held-out decoder pretraining loss at matched tokens or matched measured FLOPs because optimizer op...

Evidence

The source argues that matrix-preconditioned optimizers only retain apparent speedups over AdamW when their learning rate and independent weight decay are transferred with scale-aware rules. It reports that muP-derived learning-rate scal...

View details
Idea details

muP-scaled matrix optimizer transfer

Lifecycleneeds review
PriorityP0
Score0.49
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Changing matrix-preconditioned optimizer hyperparameters to muP-scaled learning rates plus 1/width independent weight decay should improve held-out decoder pretraining loss at matched tokens or matched measured FLOPs because optimizer optima transfer more reliably across width and depth instead of drifting with scale.

Evidence

The source argues that matrix-preconditioned optimizers only retain apparent speedups over AdamW when their learning rate and independent weight decay are transferred with scale-aware rules. It reports that muP-derived learning-rate scaling plus 1/width independent weight decay gives Muon, SOAP, and Shampoo stable near-1.4x compute-efficiency gains on dense Llama-style language models from 190M to 1.4B, while incorrect scaling causes the gains to vanish.

Current evidence
  • internal repository analysisTitan repository analysis: muP-scaled matrix optimizer transfer

    The local optimizer mechanism is mostly feasible but not exact until Titan-specific muP width mapping is decided. Target code already supports Muon, per-parameter LR scaling, and weight-decay regexes; the historical independent-weight-de...

  • github repositorycharliezchen/scaling-matrix-preconditioning

    # Hyperparameter Transfer Enables Consistent Gains of Matrix-Preconditioned Optimizers Across Scales This repository contains the code for the paper [Hyperparameter Transfer Enables Consistent Gains of Matrix-Preconditioned Optimizers Ac...

  • arxivHyperparameter Transfer Enables Consistent Gains of Matrix-Preconditioned Optimizers Across Scales

    Several recently introduced deep learning optimizers utilizing matrix-level preconditioning have shown promising speedups relative to the current dominant optimizer AdamW, particularly in relatively small-scale experiments. However, effo...

  • internal implementation failureImplementation failure: muP-scaled matrix optimizer transfer

    Implementation audit requested repair: Trusted check touched_tests failed: fn, weight_decay_regex=None)\n optimizer = container.optimizers[0]\n \n muon_group = next(group for group in optimizer.param_groups if group[\"us...

2 earlier records are available in the full idea history.

Required controls
  1. Compare against Titan's current tuned baseline optimizer at identical model, data, tokenizer, sequence length, seed, token budget, and scheduler.
  2. Match training tokens for the primary local run and report measured wall time, MFU, and optimizer overhead as secondary compute interpretation.
  3. Keep architecture, parameter count, batch size, data order, loss, initialization except optimizer-required muP scaling, and evaluation unchanged.
  4. Include a constant-scaling or current-scaling Muon control if Titan already uses Muon, to isolate hyperparameter-transfer scaling from optimizer family choice.
  5. Use same seed when practical and judge against measured local baseline variance.

EMO: Pretraining Mixture of Experts for Emergent Modularity

P0Score 0.46needs review

Source claim to test: Large language models are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge.

Evidence

Large language models are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge. Mixture-of-Experts (MoEs) seem...

View details
Idea details

EMO: Pretraining Mixture of Experts for Emergent Modularity

Lifecycleneeds review
PriorityP0
Score0.46
Decision now

This idea is in needs review. The current gate and any live recovery appear below.

Evidence, sources, and controls
Hypothesis

Source claim to test: Large language models are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge.

Evidence

Large language models are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge. Mixture-of-Experts (MoEs) seemingly offer a potential alternative by activating only a subset of experts per input, but in practice, restricting inference to a subset of experts for a given domain leads to severe performance degradation. This limits their practicality in memory-constrained settings, especially as models grow larger and sparser. We introduce EMO, an MoE designed for modularity-the independent use and composition of expert subsets-without requiring human-defined priors. Our key idea is to encourage tokens from similar domains to rely on similar experts. Since tokens within a document often share a domain, EMO restricts them to select experts from a shared pool, while allowing different documents to use different pools. This simple constraint enables coherent expert groupings to emerge during pretraining using document boundaries alone. We pretrain a 1B-active, 14B-total EMO on 1T tokens. As a full model, it matches standard MoE performance. Crucially, it enables selective expert use: retaining only 25% (12.5%) of experts incurs just a 1% (3%) absolute drop, whereas standard MoEs break under the same setting. We further find that expert subsets in EMO specialize at semantic levels (e.g., domains such as math or code), in contrast to the low-level syntactic specialization observed in standard MoEs. Altogether, our results demonstrate a path toward modular, memory-efficient deployment of large, sparse models and open new opportunities for composable architectures.

Current evidence
  • internal repository analysisTitan repository analysis: EMO: Pretraining Mixture of Experts for Emergent Modularity

    Inspection found an implementation path in the existing TransformerMoE router stack, not a new model wrapper. The natural change is to add a config-gated document-pool branch to TokenChoiceTopKRouter before current top-k selection, then ...

  • arxivEMO: Pretraining Mixture of Experts for Emergent Modularity

    Large language models are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge. Mixture-of-Experts (MoEs) seem...

  • arxivEMO: Pretraining Mixture of Experts for Emergent Modularity

    Large language models are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge. Mixture-of-Experts (MoEs) seem...

Required controls
  1. define a matched baseline and smallest falsifying test

Implementation

Verification and audit must pass before Smoke / local

5

Path-integral additive GRAPE-AP attention bias

P12Score 0.78implementation blocked

Add the exact paper GRAPE-AP path-integral attention-logit bias while retaining the current Titan rotary bilinear attention term. For each attention head, form positional probes from token-local features with a learned linear projection ...

Evidence

The local 1B GRAPE-AP candidate is feasible with a small attention-path change plus focused tests. The exact mechanism should live in the existing Transformer and TransformerMoE attention modules, use flex attention score_mod rather than...

SMOKE failedCurrent scientific review no longer approves implementation
Training steps observed 0 at step 0
View details
Idea details

Path-integral additive GRAPE-AP attention bias

Lifecycleimplementation blocked
PriorityP12
Score0.78
Decision now

This idea is in implementation blocked. The current gate and any live recovery appear below.

Experiment

SMOKE failed

Training steps observed 0 at step 0
Experiment conclusion

Current scientific review no longer approves implementation

Evidence, sources, and controls
Hypothesis

Add the exact paper GRAPE-AP path-integral attention-logit bias while retaining the current Titan rotary bilinear attention term. For each attention head, form positional probes from token-local features with a learned linear projection followed by RMS normalization, compare fixed commuting rotations of the probes at relative offsets, pass the scaled similarity through log-sigmoid to obtain bounded non-positive edge potentials, and causally sum those edges from each key position to the current query position. This source-faithful, content-dependent forgetting path should improve equal-token held-out decoder pretraining loss and sample efficiency by suppressing irrelevant earlier keys while preserving global attention, row-wise path composition, and cacheable causal semantics. Gate 1 must implement GRAPE-AP without KV-shift and must not reuse the unsupported multiplicative GRAPE-M mechanism.

Evidence

The local 1B GRAPE-AP candidate is feasible with a small attention-path change plus focused tests. The exact mechanism should live in the existing Transformer and TransformerMoE attention modules, use flex attention score_mod rather than dense bias tensors, and wire new probe parameters through the existing MoE and MTP parallelizers. The 17B baseline is also feasible only with config changes: the checked-in cuDNN MTP MoE config needs a matched flex candidate/control pair because cuDNN has no current additive score boundary. No unresolved local scientific choice blocks implementation; acceptance rests on equation/reference tests, disabled equivalence, streaming/cache consistency, AC recomputation, and real TP/FSDP gradient coverage.

Current evidence
  • internal repository analysisTitan repository analysis: Path-integral additive GRAPE-AP attention bias

    The local 1B GRAPE-AP candidate is feasible with a small attention-path change plus focused tests. The exact mechanism should live in the existing Transformer and TransformerMoE attention modules, use flex attention score_mod rather than...

  • internal failure diagnosisTraining failure diagnosis: Path-integral additive GRAPE-AP attention bias

    The GRAPE-AP implementation constructs a full dense additive attention bias tensor with shape proportional to batch x heads x query length x key length before calling flex attention. At the supplied configuration this materialization tri...

  • arxiv pdfGRAPE Eq. 5.1 primary paper evidence

    Section 5, Eq. 5.1 defines R_l = exp(l J), where l is the absolute edge/key position, and psi_h(t,l) scores p_t against R_l p_l. The relative j-t term appears only in the optional orthogonally rotary bilinear in Eq. 5.3. The candidate is...

  • internal implementation failureImplementation failure: Path-integral additive GRAPE-AP attention bias

    Implementation audit requested repair: Trusted check trusted_gpu_verification failed: tests.titan.test_grape_ap::test_grape_ap_distributed_tp_fsdp_probe_gradients[False] [failure] RuntimeError: Expected all tensors to be on the same devi...

75 earlier records are available in the full idea history.

Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_96218a5b87454a46
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
ced6630f3568bfe501aae3a72720a7c0c688b3ed
Branch
auto-research/idea_da01d43462214529/smoke_0450a7111cdbb932a26f
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/smoke_0450a7111cdbb932a26f
Configuration
/persistent/.local/state/george-auto-research/run_configs/smoke_0450a7111cdbb932a26f.smoke.yaml
Config SHA-256 (recorded, unverified)
9e93d47fd702ead0006435026bbc6e678f71ac477c10d3d953757603d211198c
Actual config SHA-256
9e93d47fd702ead0006435026bbc6e678f71ac477c10d3d953757603d211198c
Resolved config SHA-256 (recorded, unverified)
a5f0fa9471a185752377651254a09e6b8304fb277251b09d64c4ad08901373b2
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/smoke_0450a7111cdbb932a26f.smoke.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

FoX data-dependent attention forget gate

P8Score 0.78implementation blockedEarlier smoke passed; retest pending

Add only Forgetting Attention to each causal attention layer while retaining the Titan baseline RoPE, QK norms, gated-attention output, global and sliding-window masks, and MLP. For each token and head, compute the source scalar data-dep...

Evidence

The local 1B Titan implementation is feasible without a new model wrapper. The smallest faithful change is an optional per-head forget-gate projection inside the existing dense and MoE Attention classes, feeding a float32 cumulative log-...

Recovery completed (not a scientific result)Scientific review evidence changed after approval
100.0%3000 / 3000 (100.0%)Training loss 1.874 at step 3000W&B poolside/Autoresearch
View details
Idea details

FoX data-dependent attention forget gate

Lifecycleimplementation blocked
PriorityP8
Score0.78
Decision now

This idea is in implementation blocked. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%3000 / 3000 (100.0%)Training loss 1.874 at step 3000
Experiment conclusion

Scientific review evidence changed after approval

Test history

An earlier implementation passed its distributed smoke. The corrected build must finish and pass a new smoke before this card returns to Smoke / Local Test.

Evidence, sources, and controls
Hypothesis

Add only Forgetting Attention to each causal attention layer while retaining the Titan baseline RoPE, QK norms, gated-attention output, global and sliding-window masks, and MLP. For each token and head, compute the source scalar data-dependent sigmoid forget gate, accumulate its log values along the sequence, and add the resulting query-key decay difference to the unnormalized causal softmax logits before softmax; initialize the data-dependent gate projection to zero as in the paper. The learned content-dependent decay should lower equal-token held-out loss by suppressing irrelevant history without reducing global retrieval capacity. Reject the claim if final loss does not beat the matched RoPE control beyond calibrated local noise, if learned gates become data-independent without benefit, or if a kernel-correct implementation cannot sustain the local throughput target.

Evidence

The local 1B Titan implementation is feasible without a new model wrapper. The smallest faithful change is an optional per-head forget-gate projection inside the existing dense and MoE Attention classes, feeding a float32 cumulative log-forget tensor into FlexBackend as an additive query-minus-key score bias before softmax. This preserves RoPE, QK norms, global/SWA/document masks, existing gated-attention output, MLP, optimizer ownership, and loss semantics. Supplied history shows related FP8 gated-XSA work, but it is an output-gate projection change rather than this attention-logit forget mechanism, so it should not be reused as the mechanism. Prior FoX implementation failures are addressed by reversible activation fields, a source-faithful zero-logit gate instead of a neutralized variant, a cloned Flex score_mod read for backward, and focused tests including distributed TP/FSDP gradients.

Current evidence
  • internal repository analysisTitan repository analysis: FoX data-dependent attention forget gate

    The local 1B Titan implementation is feasible without a new model wrapper. The smallest faithful change is an optional per-head forget-gate projection inside the existing dense and MoE Attention classes, feeding a float32 cumulative log-...

  • internal failure diagnosisTraining failure diagnosis: FoX data-dependent attention forget gate

    The earliest observed failure is in the MoE router EMA update path: during optimizer_step, update_model_ema calls model_part.update_ema, then moe_layer.update_ema, then router.update_ema, which asserts that _ema_weight_refs has been init...

  • internal failure diagnosisFoX failure gate and semantic fidelity correction

    FoX repair evidence correction: the latest review's 'calibrated local noise' rule is an explicit metric decision threshold and should not be clamped as missing a falsifier. The candidate is still not launch-ready: tests/titan/test_activa...

  • internal implementation failureImplementation failure: FoX data-dependent attention forget gate

    Implementation audit requested repair: Off-switch must reverse enabling override paths: model.init_args.config.mtp_config.forgetting_attention; Activation metadata is not reversible as supplied: the enabling override is only `--job_confi...

44 earlier records are available in the full idea history.

Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
79d54d799dfab9ec07ad43c7a225c1d99a420ee6
Branch
external-observation
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/local-pp3dp2-candidate_798e2501474121f461d5
Configuration
/persistent/.local/state/george-auto-research/run_configs/fox-pp3dp2-control-seed43.full.yaml
Config SHA-256 (recorded, unverified)
b737304c5109c650f3d286e643f53e9016bf1cc7850d36fcf6dbf43a2925e6a3
Actual config SHA-256
b737304c5109c650f3d286e643f53e9016bf1cc7850d36fcf6dbf43a2925e6a3
Resolved config SHA-256 (recorded, unverified)
b737304c5109c650f3d286e643f53e9016bf1cc7850d36fcf6dbf43a2925e6a3
Seed
43
Recorded launch command
external observed titan-pretrain --config <FoX seed-43 control config>
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Layer-specific Bank of Values

P0Score 0.74implementation blocked

Changing the last third of decoder attention layers to layer-specific Bank of Values token-id value lookups should improve held-out base-model loss under matched pretraining tokens because deep-layer value vectors benefit from preserving...

Evidence

Bank of Values replaces standard residual-stream value projections in the last third of decoder attention layers with layer-specific token-id lookup tables scaled by a learnable coefficient. The source argues and ablates that deep-layer ...

LOCAL completedImplementation action could not be claimed
Training loss 2.221 at step 3000
View details
Idea details

Layer-specific Bank of Values

Lifecycleimplementation blocked
PriorityP0
Score0.74
Decision now

This idea is in implementation blocked. The current gate and any live recovery appear below.

Experiment

LOCAL completed

Training loss 2.221 at step 3000
Experiment conclusion

Implementation action could not be claimed

Evidence, sources, and controls
Hypothesis

Changing the last third of decoder attention layers to layer-specific Bank of Values token-id value lookups should improve held-out base-model loss under matched pretraining tokens because deep-layer value vectors benefit from preserving context-free token identity while queries and keys still carry contextual routing information.

Evidence

Bank of Values replaces standard residual-stream value projections in the last third of decoder attention layers with layer-specific token-id lookup tables scaled by a learnable coefficient. The source argues and ablates that deep-layer values prefer context-free original token information, while queries and keys still use contextual residual features. Reported 135M and 780M decoder-only experiments show validation-loss improvements over standard attention, with component ablations for source, coefficient, sharing, and target-layer choices.

Current evidence
  • internal repository analysisTitan repository analysis: Layer-specific Bank of Values

    Feasible with a scoped model/parallelism/optimizer change. Titan's MoE attention already has the exact W_V interface needed for BoV: wv outputs n_kv_heads * head_dim and is reshaped as GQA values. The smallest faithful implementation add...

  • internal failure diagnosisTraining failure diagnosis: Layer-specific Bank of Values

    The smoke-tier resolved configuration sets model.init_args.config.n_layers=2 (resolved_configuration.content.model.init_args.config.n_layers), while the run's config_overrides list applies '--job_config.model.init_args.config.bank_of_val...

  • manualVerified official Bank of Values implementation snapshot

    Exact official implementation: distinct final-ceil-third value tables substitute for xW_V, gamma is unbounded and initialized to 1, table rows use aligned x0W_V initialization, and tables use Adam while matrices use Muon.

  • internal implementation failureImplementation failure: Layer-specific Bank of Values

    Implementation audit requested repair: Trusted check touched_tests failed: gs summary ===============================\n../venv/lib/python3.12/site-packages/torch/jit/_script.py:365: 14 warnings\n /venv/lib/python3.12/site-packages/torch...

12 earlier records are available in the full idea history.

Required controls
  1. Standard attention baseline with the same architecture scale, tokenizer/data recipe, sequence length, optimizer family, and token budget for the internal test.
  2. Equal-token primary comparison at 3000 steps with matched seed and data order; report measured active FLOPs and throughput for equal-compute interpretation.
  3. Parameter-count control or explicit accounting for added per-layer |Vocab| x value-dimension tables and removed/replaced W_V parameters in target layers.
  4. Ablate BoV against computing x0 W_V directly in target layers to separate lookup parameterization from context-free value source.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/implementation/action_5caefcbb202d4e61
Configuration
scripts/runs/auto_research_bov_control.yaml
Seed
43

No training launch command was recorded. The provenance above identifies the exact revision and configuration evidence that is available.

Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

X-shaped variable layer widths

P0Score 0.74approved for implementation

Changing decoder-only Transformer blocks from uniform hidden width to an x-shaped layerwise width schedule with wider early and late layers, narrower middle layers, and parameter-free residual coordinate copying should improve held-out b...

Evidence

The source proposes a decoder-only Transformer with nonuniform hidden width across depth: early and late layers are wider, middle layers are narrowed, and inactive residual-stream coordinates bypass narrow layers through parameter-free c...

Queued for implementation - not finished
Current: Waiting for the implementation workerNext: Implementation, host verification, and independent audit; then moves automatically to Smoke / local test.
Implementation repair

Implementation audit requested repair: Off-switch must reverse enabling override paths: model.init_args.config.variable_width.bottleneck_layer_ratio, model.init_args.config.variable_width.expand_method, model.init_args.config.variable_wi...

View details
Idea details

X-shaped variable layer widths

Lifecycleapproved for implementation
PriorityP0
Score0.74
Decision now

This idea is in approved for implementation. The current gate and any live recovery appear below.

Current gate

Queued for implementation - not finished. Current: Waiting for the implementation worker. Next: Implementation, host verification, and independent audit; then moves automatically to Smoke / local test.

Why it did not advance

Current retry status: Implementation audit Codex exited 1: nses_websocket: failed to connect to websocket: HTTP error: 503 Service Unavailable, url: wss://chatgpt.com/backend-api/codex/responses warning: Falling back from WebSockets to HTTPS transport. unexpected status 503 Service Unavailable: Service Unavailable, url: wss://chatgpt.com/backend-api/codex/responses, cf-ray: a209efd7ba523cd0-CMH, auth error: 503, auth error code: biscuit_baker_service_me_circuit_open ERROR: Reconnecting... 1/5 ERROR: Reconnecting... 2/5 ERROR: Reconnecting... 3/5 ERROR: Reconnecting... 4/5 ERROR: Reconnecting... 5/5 ERROR: unexpected status 503 Service Unavailable: Service Unavailable, url: https://chatgpt.com/backend-api/codex/responses, cf-ray: a209f112dc827089-CMH, auth error: 503, auth error code: biscuit_baker_service_me_circuit_open ERROR: unexpected status 503 Service Unavailable: Service Unavailable, url: https://chatgpt.com/backend-api/codex/responses, cf-ray: a209f112dc827089-CMH, auth error: 503, auth error code: biscuit_baker_service_me_circuit_open

Implementation audit requested repair: Off-switch must reverse enabling override paths: model.init_args.config.variable_width.bottleneck_layer_ratio, model.init_args.config.variable_width.expand_method, model.init_args.config.variable_width.parameter_match, model.init_args.config.variable_width.quantize_to, model.init_args.config.variable_width.shape; Activation is not validator-accepted for the current candidate: parsed_activation is null and activation_validation_error reports that the off-switch does not reverse model.init_args.config.variable_width.shape, bottleneck_layer_ratio, expand_method, parameter_match, and quantize_to. Provide a validator-accepted activation/off-switch pair that reverses every enabling variable_width override path before any GPU run.; Trusted host verification is incomplete for the current diff: host_verification.verified is false, and touched_tests has a new failure in tests/titan/test_variable_width_moe.py::test_variable_width_config_defaults_are_baseline_off_switch from CPU FlexAttention backward. Repair the CPU-compatible off-switch identity test path and rerun trusted verification bound to the current diff.; TransformerMoEArgs.resolve_layer_widths still parameter-matches by searching endpoint dbar while computing bottleneck_width from dbar * bottleneck_width_ratio. That makes the configured 0.3 bottleneck relative to the searched endpoint width, not the baseline/reference hidden width required by the fixed x-shaped schedule. Compute bottleneck_width from reference_dim or dim during endpoint search, and add a regression test rejecting the dbar-relative variant.; VariableWidthConfig exposes activation-facing schedule freedoms beyond the preregistered fixed intervention, including layer_widths, bottleneck_layer_idx_1based, max_residual_dim, reference_dim, and symmetric_widths. Constrain the experiment activation boundary to one fixed x-shaped schedule with bottleneck around 0.75L, bottleneck width around 0.3 of baseline hidden width, quantize_to=32, parameter_match=true, and copy semantics.; No trusted zero-skip CUDA evidence is supplied for this action: trusted_gpu_evidence is null. Do not claim GPU coverage outside the supplied downstream scheduler-owned prelaunch protocol until trusted GPU artifacts are supplied for the exact current action diff.

Reproduce / inspect failed implementation

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_8e9b7a1ffeda402d
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Branch
auto-research/idea_33d3f28e73594438/action_8e9b7a1ffeda402d
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/implementation/action_8e9b7a1ffeda402d
Failed at
2026-07-25T08:54:45.059160+00:00

No training launch command was recorded. The provenance above identifies the exact revision and configuration evidence that is available.

Evidence, sources, and controls
Hypothesis

Changing decoder-only Transformer blocks from uniform hidden width to an x-shaped layerwise width schedule with wider early and late layers, narrower middle layers, and parameter-free residual coordinate copying should improve held-out base-model loss at matched training tokens or matched measured FLOPs because capacity is allocated to depth regions that use residual-stream dimensions more effectively while the middle layers avoid representation collapse.

Evidence

The source proposes a decoder-only Transformer with nonuniform hidden width across depth: early and late layers are wider, middle layers are narrowed, and inactive residual-stream coordinates bypass narrow layers through parameter-free copying, with zero padding only when no prior coordinate exists. The default recipe uses an x-shaped schedule with bottleneck index around 0.75L and bottleneck dimension around 0.3d, rounded to compatible dimensions. Reported experiments compare parameter-matched constant-width baselines across 200M-2B dense LMs and a 3B total/1B active MoE on DCLM with cl100k_base, muP-aware AdamW, SwiGLU, bf16, and power LR decay. The x shape outperforms other variable-width shapes, copying features beats zero padding or learned projection for expansion, and the final x-shaped models reportedly improve language-modeling loss while reducing attention/KV-related cost.

Current evidence
  • internal repository analysisTitan repository analysis: X-shaped variable layer widths

    The target snapshot has no variable_width implementation. The smallest faithful local path is to add an off-by-default TransformerMoEArgs.variable_width config, compute an x-shaped rounded layer-width schedule, keep a full residual strea...

  • github repositoryZhaofengWu/variable-width-transformers

    # Variable-Width Transformers This repository contains the model, configuration, and training code for our paper [Variable-Width Transformers](https://arxiv.org/abs/2606.18246). ## Setup Clone with submodules, or initialize the submod...

  • arxivVariable-Width Transformers

    Scaling model size, specifically depth and width, has driven significant progress in transformer-based language models. However, most architectures maintain a constant width across all layers, allocating a fixed parameter and computation...

  • internal implementation failureImplementation failure: X-shaped variable layer widths

    Implementation audit requested repair: Trusted check trusted_gpu_verification failed: tests.titan.test_compile_strategies::test_parallelize_transformer_moe_compile[overlapped] [failure] torch.distributed.DistBackendError: NCCL error in: ...

321 earlier records are available in the full idea history.

Required controls
  1. Parameter-matched constant-width Titan MoE baseline with identical data, tokenizer, optimizer, LR schedule, context length, batch construction, and training tokens.
  2. Same seed for candidate and control when practical; repeat or calibrate against local baseline variance before promotion.
  3. Primary equal-token comparison at the local 3000-step MoE falsifier; report measured active FLOPs and throughput because variable widths change attention FLOPs and kernel efficiency.
  4. Secondary compute-normalized interpretation if measured training FLOPs differ materially; do not claim sample efficiency solely from parameter matching.
  5. Use one fixed width schedule for the falsifier, e.g. x-shaped layer widths with bottleneck index about 0.75L and bottleneck width about 0.3 of baseline hidden width, rounded to hardware-compatible dimensions.
  6. Keep objective, MoE routing, tokenizer, data mixture, and evaluation unchanged; the only intervention is layerwise hidden-width allocation plus parameter-free residual resizing.
  7. Account for MoE active-parameter mismatch, since the source's MoE variable-width model had about 3% fewer active parameters despite total-parameter matching.

Post-QKV depthwise convolution

P0Score 0.73implementation blocked

Changing each decoder attention block to apply a causal residual depthwise k=3 convolution to the projected Q, K, and V tensors before attention should improve held-out base-model loss under matched pretraining tokens because local neigh...

Evidence

The source studies lightweight causal depthwise Conv1D modules inside decoder Transformer blocks. Its placement ablation over 17 locations finds the best reported loss/perplexity when convolution is applied to the projected Q, K, and V r...

Implementation repair

Implementation audit requested repair: Trusted host verification is not clean for the current action: `host_verification.verified` is false because `mypy` failed. Even with preexisting errors reported, this audit input does not provide a...

View details
Idea details

Post-QKV depthwise convolution

Lifecycleimplementation blocked
PriorityP0
Score0.73
Decision now

This idea is in implementation blocked. The current gate and any live recovery appear below.

Why it did not advance

Current retry status: Implementation audit requested repair: Trusted host verification is not clean for the current action: `host_verification.verified` is false because `mypy` failed. Even if the reported errors are preexisting, this audit input does not provide a verified passed type check for the exact current diff before a GPU run.; The required distributed acceptance evidence is missing. `trusted_gpu_evidence` is null, and the trusted host `touched_tests` output shows the CUDA ATP/TP tests were skipped, so the ATP/TP and forward/backward gradient control is not satisfied before launch.; Focused distributed coverage in the current diff is still insufficient for the production paths. `test_qkv_depthwise_conv_non_atp_tp_synchronizes_gradients` tests `sync_replicated_module_gradients` directly on an `Attention` module, and the ATP production test mainly validates DTensor placement plus gradients, but there is no trusted zero-skip CUDA evidence for production dense, MoE, and MTP-MoE forward/backward behavior across the required topologies.

Implementation audit requested repair: Trusted host verification is not clean for the current action: `host_verification.verified` is false because `mypy` failed. Even with preexisting errors reported, this audit input does not provide a verified passed type check for the current diff before launch.; The required ATP/TP validation has no trusted zero-skip CUDA evidence. `trusted_gpu_evidence` is null, and the trusted host `touched_tests` output shows `test_qkv_depthwise_conv_non_atp_tp_synchronizes_gradients` and `test_qkv_depthwise_conv_atp_production_parallelization_plans` were skipped, so the distributed acceptance control is not satisfied.; Focused distributed coverage in the current diff is still not strong enough: `test_qkv_depthwise_conv_non_atp_tp_synchronizes_gradients` exercises `sync_replicated_module_gradients` directly on an `Attention` module, while `test_qkv_depthwise_conv_atp_production_parallelization_plans` parallelizes models but then calls `apply_causal_depthwise_conv` on the conv modules instead of running full production attention/model forward/backward through the dense, MoE, and MTP-MoE parallelizers. Add zero-skip CUDA tests that verify production-plan forward/backward behavior, ATP channel sharding, and non-ATP replicated conv weight and bias gradient synchronization.

Reproduce / inspect failed implementation

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_0ab11e1b7c674c07
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Branch
auto-research/idea_365e9af077b84604/action_0ab11e1b7c674c07
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/implementation/action_0ab11e1b7c674c07
Failed at
2026-07-28T17:33:25.405731+00:00

No training launch command was recorded. The provenance above identifies the exact revision and configuration evidence that is available.

Evidence, sources, and controls
Hypothesis

Changing each decoder attention block to apply a causal residual depthwise k=3 convolution to the projected Q, K, and V tensors before attention should improve held-out base-model loss under matched pretraining tokens because local neighboring-token context is injected into attention inputs before global aggregation without materially changing parameter count.

Evidence

The source studies lightweight causal depthwise Conv1D modules inside decoder Transformer blocks. Its placement ablation over 17 locations finds the best reported loss/perplexity when convolution is applied to the projected Q, K, and V representations before attention. Follow-up ablations favor a residual k=3 depthwise convolution without extra normalization, activation, a second module, or multi-branch reparameterization.

Current evidence
  • internal repository analysisTitan repository analysis: Post-QKV depthwise convolution

    Implementable as a scoped attention-local architecture flag. The target tree has two Attention implementations: dense Attention in transformer.py, used by dense Transformer and MTP BaseTransformer, and MoE Attention in transformer_moe.py...

  • internal primary source resolutionPrimary source resolution: Post-QKV depthwise convolution initialization and placement

    Primary-source resolution for Convolution for Large Language Models (arXiv:2607.18413v1): the selected QKV Conv1D ablation uses one biased causal depthwise Conv1D over the concatenated post-projection QKV channels in every layer, kernel ...

  • arxivConvolution for Large Language Models

    Large language models (LLMs) largely rely on Transformers, where self-attention provides global token interaction but does not explicitly encode the locality of natural language. We study whether lightweight depthwise convolutions can su...

  • internal implementation failureImplementation failure: Post-QKV depthwise convolution

    Implementation audit requested repair: Activation is incomplete for the supported 17B MTP path: the supplied parsed activation toggles only `model.init_args.config.qkv_depthwise_conv_enabled`, while the current diff adds and uses the nes...

55 earlier records are available in the full idea history.

Required controls
  1. Exact Titan baseline architecture, data, tokenizer, objective, optimizer, LR schedule, context length, and 3000-step horizon unchanged except for the QKV convolution module
  2. Equal-token candidate/control at 3000 steps, 100 warmup, 900 cooldown, same seed and data order when practical
  3. Report measured training FLOPs and throughput because the convolution changes attention-input computation even with less than 0.01% added parameters
  4. Parameter-count confound tracked; no width reduction unless scientific review requires strict parameter matching
  5. Ablate off switch to recover exact baseline Q, K, V tensors before attention

Smoke / local test

Ready, queued, running, or replicating

0

No cards here.

Local result / failure

Promising, rejected, inconclusive, or failed

13

Two-point dynamic ShortConv in attention and residual writes

P10Score 0.78local rejected

Add identity-initialized causal dynamic depthwise short convolutions at two architectural locations in each decoder block: directly after the key and value projections, and on the attention-output and MLP-output residual branches immedia...

Evidence

Implementation audit requested repair: Current scientific review is identifiable: scientific_review.review_id=review_9494e7cbae2d4b03 and scientific_review_sha256=369e02f92e1428fbd5b48b0eaa20c258eef8ae35be5e1d5cd3cfe8a9d97033ea.; Host ve...

LOCAL completedCompleted matched seed-44 3000-step ShortConv candidate shortconv-v1-full-pp2dp4-seed44-r1-0717 versus disabled control shortconv-v1-full-control-pp2dp4-seed44-r1-0717. Audited step-3000 training loss was 3.1805 versus 1.9188 (delta +1.2...
Training loss 3.18 at step 3000
View details
Idea details

Two-point dynamic ShortConv in attention and residual writes

Lifecyclelocal rejected
PriorityP10
Score0.78
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

LOCAL completed

Training loss 3.18 at step 3000
Matched baseline

shortconv-v1-full-control-pp2dp4-seed44-r1-0717

Experiment conclusion

Completed matched seed-44 3000-step ShortConv candidate shortconv-v1-full-pp2dp4-seed44-r1-0717 versus disabled control shortconv-v1-full-control-pp2dp4-seed44-r1-0717. Audited step-3000 training loss was 3.1805 versus 1.9188 (delta +1.2617, +65.75%); candidate was worse at 288/301 matched observations, throughput was 13.48% lower, and peak reserved memory was 11.87 GiB higher. Catastrophic negative matched training-direction and compute result; reject locally and do not repeat. No held-out or composite_v2 claim is made.

Evidence, sources, and controls
Hypothesis

Add identity-initialized causal dynamic depthwise short convolutions at two architectural locations in each decoder block: directly after the key and value projections, and on the attention-output and MLP-output residual branches immediately before each rejoins the main residual stream. Local input-dependent filtering at both memory formation and residual writing should improve held-out pretraining loss and sample efficiency without replacing global attention.

Evidence

Implementation audit requested repair: Current scientific review is identifiable: scientific_review.review_id=review_9494e7cbae2d4b03 and scientific_review_sha256=369e02f92e1428fbd5b48b0eaa20c258eef8ae35be5e1d5cd3cfe8a9d97033ea.; Host verification is not clean: host_verification.verified is false and format_normalization failed on tests/titan/test_dynamic_shortconv.py with PT018, so this candidate is not ready before a GPU run.; Activation is not valid at the required boundary. The current diff adds the typed dynamic_shortconv_v1 config field and rank=16 default, but the supplied parsed activation/off switch still uses flat model.init_args.config.dynamic_shortconv_enabled and flat apply/rank/kernel overrides rather than job_config.model.init_args.config.dynamic_shortconv_v1.enabled=false for control and the typed bundle for candidate.; Repository alignment fails for the MTP distributed boundary. The normative repository evidence requires ShortConv TP/FSDP handling in poolside/titan/parallelisms/parallelize_transformer_mtp_moe.py for MTP blocks, but the current unified_diff does not modify that file.; The MoE attention tensor-parallel path remains semantically unsafe. Attention.k_shortconv and Attention.v_shortconv are constructed with global config.n_kv_heads * head_dim, while attention_tensor_parallel=true makes wk/wv produce local K/V feature shards before the ShortConv call; the module only slices weights inside forward and does not prove the parameter geometry is consistently sharded with the local K/V layout.; The TP plans add proj_in/proj_out entries and manually replicate static_w, but there is no focused distributed test in the current diff asserting exact placements and finite gradients for every k_shortconv, v_shortconv, attn_write_shortconv, mlp_write_shortconv proj_in, proj_out, and static_w parameter. This would not reject plausible but wrong sharding variants.; Compute accounting is not satisfied before launch. The downstream protocol requires implementation exposure of extra forward timing, but the current unified_diff does not add timing exposure or a mechanism to report distributed communication changes.; Coverage is still incomplete for the exact launch requirements: tests cover causal equation, K/V-only behavior, residual-write source ordering, identity recovery, typed MTP config presence, and resolved-sublayer checkpoint cache behavior, but not the actual typed activation/off-switch config path used by the runner, the required MTP parallelizer behavior, or distributed placement under the target topology.; Current review is identifiable: scientific_review.review_id=review_c4ddc421a1874f72 and scientific_review_sha256=522e111e540624808e9b8861a396919f14105a2bb69cd5f13f2fa6a16a8d5641.; Host verification is not clean: host_verification.verified is false and the touched_tests check failed, so this candidate is not ready before a GPU run.; Activation is not valid against the repository requirement. The current diff wires flat dynamic_shortconv_* ModelArgs and TransformerMoEArgs fields plus a derived property, and parsed activation uses model.init_args.config.dynamic_shortconv_enabled, while the normative activation requires the typed job_config.model.init_args.config.dynamic_shortconv_v1 bundle with enabled=false as the off-switch.; The implementation uses rank=15 in DynamicShortConvV1Config defaults, assertions, model config fields, tests, and parsed activation. Repository evidence requires rank=16, so this is an invented activation value.; Repository alignment fails for required MTP propagation. The diff changes ModelArgs inheritance surfaces but does not implement or test the required typed dynamic_shortconv_v1 bundle in both TransformerMoE base config and mtp_config for MTPTransformerMoE.; Repository alignment fails for distributed placement. The current diff does not modify poolside/titan/parallelisms/parallelize_transformer_moe.py or poolside/titan/parallelisms/parallelize_transformer_mtp_moe.py, and adds no

Current evidence
  • internal repository analysisTitan repository analysis: Two-point dynamic ShortConv in attention and residual writes

    The target tree has no dynamic ShortConv implementation or config fields yet, but the local 1B implementation is exact and feasible without unresolved scientific choices. The smallest change is a typed dynamic_shortconv_v1 bundle, a reus...

  • arxivDynamic Short Convolutions Improve Transformers

    Transformers have become the dominant architecture for large language models, largely due to the scalability and flexibility of attention, feed-forward layers, residual connections, and normalization. This paper introduces dynamic short ...

  • github repositoryOliverSieberling/dynamic-conv1d

    Triton kernels for dynamic causal short convolutions. # Dynamic Short Convolutions (Triton) Triton kernels for causal depthwise separable convolutions with per-token (dynamic) convolution weights. Two variants: - `headwise.py`: general...

  • internal implementation failureImplementation failure: Two-point dynamic ShortConv in attention and residual writes

    Implementation audit requested repair: Current scientific review is identifiable: scientific_review.review_id=review_9494e7cbae2d4b03 and scientific_review_sha256=369e02f92e1428fbd5b48b0eaa20c258eef8ae35be5e1d5cd3cfe8a9d97033ea.; Host ve...

9 earlier records are available in the full idea history.

Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
03bd60411c194302545a359c8c481ee56ed838bd
Branch
preserved/shortconv-fae7dad
Preserved worktree
/persistent/.local/state/george-auto-research/preserved_worktrees/shortconv-fae7dad
Configuration
/persistent/.local/state/george-auto-research/run_configs/shortconv-v1-full-pp2dp4-seed44-r1-0717.local.yaml
Config SHA-256 (recorded, unverified)
ada7d078d3ab5748f3d29987f3cd862b157d2bf0e2bc37d1e4487b6b30e85af4
Actual config SHA-256
ada7d078d3ab5748f3d29987f3cd862b157d2bf0e2bc37d1e4487b6b30e85af4
Resolved config SHA-256 (recorded, unverified)
56e0cf76583107ce1e7098745881f6ff89f31e70a9c0cb59683b5e9d7aa97831
Seed
44
Recorded launch command
bash /persistent/.local/state/george-auto-research/launch_manifests/shortconv-v1-final-run-one-seed44-0717.sh shortconv-v1-full-pp2dp4-seed44-r1-0717
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Official unit-Stiefel Manifold Muon

P10Score 0.76local rejectedRQC v10 staleSmoke passed

Apply the official Thinking Machines unit-Stiefel Manifold Muon update to one audited class of eligible 2D hidden weights. Transpose W and G iff W.shape[0] < W.shape[1]; at eta=0 initialize W with msign(W); initialize Lambda=-0.25*(W.T@G...

Evidence

The request is locally feasible as a narrow optimizer-only change. The target tree already has the needed Muon owner-rank P2P gather/scatter, replica broadcast, parameter grouping, search_param_name matching, optimizer metrics, and MoE/M...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.054529
100.0%300 / 300 (100.0%)Training loss 3.381 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.380638 vs control 3.326109 (delta +0.054529). No 3000-step pair was launched.

View details
Idea details

Official unit-Stiefel Manifold Muon

Lifecyclelocal rejected
PriorityP10
Score0.76
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.381 at step 300
Matched baseline

probe-dp4-control_dcd82370150e751afffe

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.054529

Directional gate

Global loss gate did not pass: candidate 3.380638 vs control 3.326109 (delta +0.054529). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Apply the official Thinking Machines unit-Stiefel Manifold Muon update to one audited class of eligible 2D hidden weights. Transpose W and G iff W.shape[0] < W.shape[1]; at eta=0 initialize W with msign(W); initialize Lambda=-0.25*(W.T@G+G.T@W), compute A=msign(G+2*W@Lambda) and H=W.T@A+A.T@W, then retract with new_W=msign(W-eta*A) and transpose back iff required. The unit-Stiefel constraint may improve held-out decoder pretraining loss or stability over standard Muon at matched tokens, while initialization and forward/gradient-scale consequences are measured rather than canceled by an invented fan-scaled radius.

Evidence

The request is locally feasible as a narrow optimizer-only change. The target tree already has the needed Muon owner-rank P2P gather/scatter, replica broadcast, parameter grouping, search_param_name matching, optimizer metrics, and MoE/MTP wrapper wiring. The smallest diff is to add a literal official unit-Stiefel Manifold Muon update, split exactly layers.0.feed_forward.w1.weight into its own Muon group when the regex is non-null, run the replacement full-logical update on the existing owner path, and activate through generated candidate/control configs derived from scripts/runs/tiny.yaml. No scientific choice blocks the local 1B implementation; the main risks are performance from tensor-valued early stopping and scale compatibility that must be tested before 17B launch.

Current evidence
  • internal repository analysisTitan repository analysis: Official unit-Stiefel Manifold Muon

    The request is locally feasible as a narrow optimizer-only change. The target tree already has the needed Muon owner-rank P2P gather/scatter, replica broadcast, parameter grouping, search_param_name matching, optimizer metrics, and MoE/M...

  • internal failure diagnosisTraining failure diagnosis: Official unit-Stiefel Manifold Muon

    The experiment enabled Manifold Muon while leaving `muon.use_cuda_graphs` set to true. The candidate code explicitly rejects that combination during optimizer construction, so training fails before any step runs.

  • internal failure diagnosisTraining failure diagnosis: Official unit-Stiefel Manifold Muon

    The experiment activation enabled Manifold Muon while leaving `optimizer.init_args.muon.use_cuda_graphs` set to true. The candidate code explicitly rejects that combination during `Muon.__init__`, so optimizer construction fails before t...

  • internal implementation failureImplementation failure: Official unit-Stiefel Manifold Muon

    Implementation audit requested repair: The matched-control weight-decay exclusion is not enforced at the implementation boundary shown in the current diff. `OptimizersContainer._get_parameter_groups` forces `weight_decay=0.0` only when `...

23 earlier records are available in the full idea history.

Research question certificate

RQC v10

RQC v10 stale
StatusStale or invalidated
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Implement the reversible candidate and focused functional tests, then run the configured eight-GPU Titan MoE with about 1B total and 100M active parameters for exactly 3000 steps, 100 warmup steps, and 900 cooldown steps. Compare against matched standard Muon using the same seed when practical and the same token budget. Falsify if held-out loss or composite_v2 gain is within measured baseline variance, if equal-compute accounting removes the apparent gain, if dual/retraction overhead is unacceptable, or if distributed owner-rank equivalence fails before launch.

Mechanism and tension

Changing one audited eligible 2D hidden-weight class from standard Muon to the official unit-Stiefel Manifold Muon update should improve held-out decoder pretraining loss or composite_v2 at matched tokens because constraining the update and retraction to the unit-Stiefel geometry may improve gradient conditioning and weight geometry without changing data, tokenizer, architecture, or active expert routing. Tension: Incorrect orientation handling for wide matrices could silently apply the wrong Stiefel constraint.; A nonliteral Lambda update, eta placement, or symmetrization variant would test a different algorithm.; Owner-rank gather/update/reshard behavior may differ from unsharded reference behavior under DTensor.; Candidate-only CUDA graph disabling may introduce throughput and runtime differences that complicate scaling.; Matrix-sign and dual-loop numerical behavior may be unstable in training precision or under large gradients.; Optimizer grouping regex mistakes could affect additional parameters or miss the intended tensor.

Certificate cannot authorize work

[ "material context changed", "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Apply the official Thinking Machines unit-Stiefel Manifold Muon update to one audited class of eligible 2D hidden weights. Transpose W and G iff W.shape[0] < W.shape[1]; at eta=0 initialize W with msign(W); initialize Lambda=-0.25*(W.T@G+G.T@W), compute A=msign(G+2*W@Lambda) and H=W.T@A+A.T@W, then retract with new_W=msign(W-eta*A) and transpose back iff required. The unit-Stiefel constraint may improve held-out decoder pretraining loss or stability over standard Muon at matched tokens, while initialization and forward/gradient-scale consequences are measured rather than canceled by an invented fan-scaled radius.",
  "idea_id": "idea_80448b61b5ec4507"
}
matched control
{
  "change": "Use the standard Muon baseline with the same data, tokenizer, architecture, training schedule, parameter grouping, and evaluation.; Match the exact token budget: configured eight-GPU Titan MoE, about 1B total and 100M active parameters, exactly 3000 steps, 100 warmup steps, and 900 cooldown steps.; Use the same seed when practical, or preregister paired seed handling if distributed launch requires a seed set.; Apply the same weight_decay_regex exclusion for ^layers\\.0\\.feed_forward\\.w1\\.weight$ in both candidate and control.; Keep embeddings, output weights, norms, biases, routers, MTP paths, and unsupported sharded matrices on baseline optimizer paths.; Report active FLOPs, optimizer overhead, throughput, wall time, initialization scale, forward scale, gradient scale, and dual-loop convergence behavior.",
  "idea_id": "idea_80448b61b5ec4507"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
  "idea_id": "idea_80448b61b5ec4507",
  "implementation_material_sha256": "7109fc951bb2545f1e939111b16d1e1d069313900401d5bb88ac9c68baff1273",
  "metric_identities": [
    {
      "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_c89114f439274554",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_88962dcaaedf4b0c
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
ef0e285c7253f02cc1df7c90ae5a7e216b8a2712
Branch
auto-research/idea_80448b61b5ec4507/probe-dp4-candidate_47a203c910e9b52f9d44
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_47a203c910e9b52f9d44
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_47a203c910e9b52f9d44.local.yaml
Config SHA-256 (recorded, unverified)
ce44be7cff62d17680ab4adf2a37564d02d150023122f78f03653a37a89aa4d9
Actual config SHA-256
ce44be7cff62d17680ab4adf2a37564d02d150023122f78f03653a37a89aa4d9
Resolved config SHA-256 (recorded, unverified)
55f59471af71699036b39f2973f66fe78b2de3396e9be2e80652a21266517a65
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_47a203c910e9b52f9d44.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

StableMask gamma 0.5 causal pseudo logits

P10Score 0.71local rejectedRQC v16 staleSmoke passed

Adding StableMask's parameter-free, head-wise gamma=0.5 future-position pseudo logits before softmax and zeroing future probabilities after softmax will let real-token attention mass fall below one, reduce attention sinks, encode absolut...

Evidence

The primary paper evaluates 71M through 1.4B causal decoder LMs and reports gains across datasets and positional encodings. In its 1.4B OpenLLaMA/RoPE Pile experiment, perplexity is 15.4 to 15.0 at 5B tokens and 10.7 to 10.4 at 25B token...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.045636
100.0%300 / 300 (100.0%)Training loss 3.335 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.335222 vs control 3.289586 (delta +0.045636). No 3000-step pair was launched.

View details
Idea details

StableMask gamma 0.5 causal pseudo logits

Lifecyclelocal rejected
PriorityP10
Score0.71
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.335 at step 300
Matched baseline

probe-dp4-control_51495037c4c69892d6db

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.045636

Directional gate

Global loss gate did not pass: candidate 3.335222 vs control 3.289586 (delta +0.045636). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Adding StableMask's parameter-free, head-wise gamma=0.5 future-position pseudo logits before softmax and zeroing future probabilities after softmax will let real-token attention mass fall below one, reduce attention sinks, encode absolute position without leakage, and lower held-out next-token loss/AUC under the fixed Titan TPP30 protocol.

Evidence

The primary paper evaluates 71M through 1.4B causal decoder LMs and reports gains across datasets and positional encodings. In its 1.4B OpenLLaMA/RoPE Pile experiment, perplexity is 15.4 to 15.0 at 5B tokens and 10.7 to 10.4 at 25B tokens. The method is parameter-free and the paper describes integration with optimized attention.

Current evidence
  • internal repository analysisTitan repository analysis: StableMask gamma 0.5 causal pseudo logits

    StableMask is locally implementable as a small default-off Flex-attention change on the existing dense, MoE, and MTP metadata paths. The faithful equation is fixed gamma=0.5, future pseudo logit -gamma * physical zero-based key index for...

  • internal scientific decisionStableMask exact sealed design and activation binding

    The only supported StableMask implementation is the exact seven-file sealed revision: separate default-off stablemask_enabled and fixed stablemask_gamma=0.5 fields, Flex-only LSE rescaling, dense/MoE/MTP propagation, physical key-column ...

  • internal scientific decisionStableMask failed-revision to sealed-repair reconciliation

    The old semantic failure belongs to action_a0c6baded6c6403f (verifier diff cd8e0679..., five files). The later sealed repair is a distinct seven-file revision (manifest 28ad836f..., combined diff 3f385b63...) that directly repairs every ...

  • internal implementation failureImplementation failure: StableMask gamma 0.5 causal pseudo logits

    Operational workflow failure before scientific evaluation: The service restarted during verification; use a fresh implementation attempt

10 earlier records are available in the full idea history.

Research question certificate

RQC v16

RQC v16 stale
StatusStale or invalidated
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Run the fixed Titan TPP30 protocol on 8 GPUs: 3-step smoke (finite, off-switch byte-parity, invariant asserts), then 300-step full-shape prefix probe preserving the 3000-step horizon (100 warmup, cooldown from step 2100), then the matched 3000-step A/B where the only delta is stablemask_enabled true vs false with gamma=0.5 in both arms, from scripts/runs/tiny.yaml. Falsify if: any future-token leakage or nonzero future probability is detected; dense-reference forward/backward parity or disabled-path parity fails; the 300-step prefix is worse than control in both final held-out loss and pre-specified AUC beyond measured noise; or the 3000-step run fails to improve both final held-out loss and loss AUC beyond the composite_v2 variance threshold. Also fail the production path if Flex overhead breaks the <1-hour budget or materially erases the measured sample-efficiency gain.

Mechanism and tension

Adding StableMask's parameter-free, head-wise gamma=0.5 future-position pseudo-logits before softmax and zeroing future-token probabilities after softmax (implemented as Flex causal-LSE rescaled by logaddexp(causal_lse, future_lse)) should lower held-out next-token loss and held-out-loss AUC on the canonical ~1B-total/~100M-active Titan MoE at TPP30, matched seed/data/tokenizer/optimizer/schedule/evaluator, because letting real-token attention row mass fall below one reduces attention-sink concentration and injects an absolute-position signal without any future-token leakage, while keeping active parameters and active FLOPs essentially unchanged. Tension: Materializing per-window future-LSE could reduce fused-Flex throughput or increase peak memory, breaking the <1-hour budget.; Absolute-position signal may conflict with sequence packing and document-boundary semantics, degrading packed-document batches.; SWA window eligibility (kv_idx - q_idx <= attention_window) applied incorrectly could change in-window masking versus control.; Interaction with attention sinks (both manipulate denominator mass); must remain mutually exclusive or numerator/denominator accounting is wrong.; Flex-only path forces the 17B arms off cuDNN, so an unmatched control could confound the loss delta with a backend change.; MTP nested attention path must apply matched semantics or the auxiliary block diverges from base attention.; Small-scale sink-reduction benefit may wash out at MoE/RoPE scale (as gated XSA did), yielding a false-positive prefix signal.

Certificate cannot authorize work

[ "material context changed", "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Adding StableMask's parameter-free, head-wise gamma=0.5 future-position pseudo logits before softmax and zeroing future probabilities after softmax will let real-token attention mass fall below one, reduce attention sinks, encode absolute position without leakage, and lower held-out next-token loss/AUC under the fixed Titan TPP30 protocol.",
  "idea_id": "idea_390098622868482f"
}
matched control
{
  "change": "Single boolean delta: candidate stablemask_enabled=true vs control false, gamma=0.5 in both arms, no bundled architecture or optimizer change; disabled path byte-identical to canonical baseline.; Matched TPP30 token budget and equal-FLOP interpretation (parameter-free) at the ~1B-total/~100M-active scale on 8 GPUs.; Identical seed, data order and manifest, tokenizer, global batch, sequence length, optimizer and all hyperparameters, LR schedule, parallelism, compile mode, and evaluator.; Both 1B arms on the same Flex baseline (scripts/runs/tiny.yaml) so the only change is the mask; for 17B, both arms switch base and MTP to flex and only the candidate toggles StableMask.; Pre-training dense-reference parity: forward values and gradients match, zero gradient/influence from future-token content, disabled path equals standard causal attention.; Physical zero-based key indexing with same-document eligibility and SWA window bound verified against the closed-form geometric series.; Attention sinks kept disabled and asserted incompatible with StableMask; cuDNN/TE backends rejected.; 300-step full-shape prefix probe treated as diagnostic gate only, not final evidence.",
  "idea_id": "idea_390098622868482f"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
  "idea_id": "idea_390098622868482f",
  "implementation_material_sha256": "18b05e9d4b4b5040b81abd852d9b9f1389b1a955197511109e09766d5e1eada4",
  "metric_identities": [
    {
      "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_5120befca3c94a11",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Implement one switch whose disabled path is numerically identical to the canonical baseline; do not bundle any second architecture or optimizer change.
  2. First run a 3-optimizer-step smoke. If depth is shortened, change only n_layers and trim attention_window to the shortened pattern; preserve width, experts, head geometry, and all other model behavior.
  3. Then run a 300-step full-shape prefix probe on 8 GPUs, preserving the complete 3000-step scheduler horizon (100 warmup, cooldown beginning at step 2100). Treat this as a diagnostic, not final evidence.
  4. Only proceed to the matched 3000-step A/B if the smoke is finite, the off-switch parity check passes, and the 300-step loss/AUC and systems metrics show no regression that already falsifies the idea.
  5. Use the exact canonical about-1B-total/about-100M-active TPP30 protocol on 8 GPUs, with identical seed, data order, tokenizer, global batch, optimizer, schedule, parallelism, compile mode, and evaluator.
  6. Record resolved config, git SHA, seed, tokenizer version, dataset manifest, actual token count/TPP, wall time, tokens/s, peak memory, allocation retries/OOMs, and W&B run ids in the separate Autoresearch project.
  7. Use the paper's fixed gamma=0.5, separately for each head but without learned parameters or a gamma sweep in the first A/B.
  8. For 1-indexed key position j, set future pseudo logit p_(i,j) = -(j-1) * 0.5 only when j > i; compute softmax over real causal logits plus these pseudo logits, then multiply by the ordinary causal mask so future output probabilities are exactly zero and real-token row mass may be below one.
  9. Before training, compare the optimized path against a dense reference in forward values and gradients, assert zero gradient/influence from future token content, and assert the disabled path matches standard causal attention.
  10. Measure real-token attention row mass, attention entropy, and BOS/punctuation sink mass by layer/head at sparse diagnostic intervals.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_25def381d850468b
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
98d22f5c81ff61650a9f7f5bd539abd96461d27f
Branch
auto-research/idea_390098622868482f/probe-dp4-candidate_d02a68c08381af813a9d
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_d02a68c08381af813a9d
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_d02a68c08381af813a9d.local.yaml
Config SHA-256 (recorded, unverified)
998b5e0171d282d36e14e557765550f21a05fd2327c118eae4ae1a1f8498dff4
Actual config SHA-256
998b5e0171d282d36e14e557765550f21a05fd2327c118eae4ae1a1f8498dff4
Resolved config SHA-256 (recorded, unverified)
5cd1adbdcb37d72e1546195aec4e6433e762daed602d365c0d6985f05e16ac7a
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_d02a68c08381af813a9d.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Identity ResFormer 0.5 first-value residual

P9Score 0.78local rejectedRQC v27 currentSmoke passed

For each attention layer n >= 2, replacing only its value tensor V_n with 0.5 * V_1 + 0.5 * V_n, while retaining that layer's own Q, K, attention matrix, output projection, and all ordinary hidden-state residuals, will preserve early tok...

Evidence

The v5 primary paper tests Llama-like pre-norm, SwiGLU, RoPE decoder LMs on SlimPajama from 82M to 468M parameters at 20B tokens and a 1.6B model at 200B tokens. It reports equivalent validation loss with 16.11% fewer parameters or 20.3%...

Current blocker

Identity ResFormer local result needs an architecture-parity evaluator rerun

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.000470
100.0%300 / 300 (100.0%)Training loss 3.277 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.277053 vs control 3.276583 (delta +0.000470). No 3000-step pair was launched.

View details
Idea details

Identity ResFormer 0.5 first-value residual

Lifecyclelocal rejected
PriorityP9
Score0.78
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.277 at step 300
Matched baseline

probe-dp4-control_b5330472f0fd3a7f9c68

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.000470

Directional gate

Global loss gate did not pass: candidate 3.277053 vs control 3.276583 (delta +0.000470). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Current blocker

Identity ResFormer local result needs an architecture-parity evaluator rerun

Gate: evaluator parity.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

For each attention layer n >= 2, replacing only its value tensor V_n with 0.5 * V_1 + 0.5 * V_n, while retaining that layer's own Q, K, attention matrix, output projection, and all ordinary hidden-state residuals, will preserve early token information and lower held-out next-token loss/AUC under the fixed Titan TPP30 protocol without a material systems regression.

Evidence

The v5 primary paper tests Llama-like pre-norm, SwiGLU, RoPE decoder LMs on SlimPajama from 82M to 468M parameters at 20B tokens and a 1.6B model at 200B tokens. It reports equivalent validation loss with 16.11% fewer parameters or 20.3% fewer training tokens. At 468M, the reported WikiText perplexity is 24.8 for Transformer and 23.8 for fixed Identity-ResFormer.

Current evidence
  • internal repository analysisTitan repository analysis: Identity ResFormer 0.5 first-value residual

    The exact local 1B implementation is feasible with no unresolved scientific blocker. The smallest safe change is a disabled-by-default TransformerMoE config switch that captures layer-0 V after wv and reshape, reuses that same local tens...

  • internal failure diagnosisTraining failure diagnosis: Identity ResFormer 0.5 first-value residual

    The candidate added `_unwrap_transformer_moe_block(layer)` inside `TransformerMoE.forward`, but the smoke run executes the model after training parallelization/compilation, where entries in `self.layers` can be wrapper modules rather tha...

  • internal failure diagnosisTraining failure diagnosis: Identity ResFormer 0.5 first-value residual

    The candidate added `_unwrap_transformer_moe_block(layer)` and assumes every entry in `self.layers.items()` is either a `TransformerMoEBlock` or has `_checkpoint_wrapped_module`. In the smoke run, after training-time wrapping/compilation...

  • internal implementation failureImplementation failure: Identity ResFormer 0.5 first-value residual

    Implementation audit requested repair: Trusted check mypy failed: {"baseline": "{\"file\": \"tests/integration/dagster_launch_backend.py\", \"line\": 315, \"column\": 23, \"end_line\": 315, \"end_column\": 65, \"message\": \"Value of typ...

9 earlier records are available in the full idea history.

Research question certificate

RQC v27

RQC v27 current
StatusCurrent and approved
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Implement the disabled-by-default switch and run focused functional tests. Then run a 3-step smoke with at least two attention layers and off-switch parity. Run a 300-step full-shape prefix probe under the complete 3000-step schedule horizon as a diagnostic. The decisive gate is a matched 3000-step 8-GPU TPP30 A/B at about 1B total and 100M active parameters. Reject if off-switch parity or finite-gradient checks fail, if systems regression exceeds the stated runtime/memory budget, or if the matched 3000-step candidate does not improve both final held-out loss and held-out-loss AUC beyond the measured baseline variance rule.

Mechanism and tension

Changing each attention layer n >= 2 to use V_mix = 0.5 * V_1 + 0.5 * V_n, while preserving that layer's own Q, K, attention probabilities, output projection, residuals, MLP/MoE path, optimizer, data, and schedule, should improve composite_v2 under matched TPP30 tokens because an untransformed first-layer value stream may preserve early lexical/token information across depth. Tension: Off-switch path may accidentally change numerics, state dict metadata, or parameter-transfer behavior.; Activation checkpointing, FSDP, TP/SP wrappers, or compile paths may drop or mis-handle first_value.; Activation memory can rise because V_1 must remain live across depth.; A wrong tensor layout under attention tensor parallelism could silently mix mismatched KV-head shards.; The candidate could degrade loss AUC even if final loss is noisy or neutral.; Evaluation could be confounded if run against an MTP or otherwise non-identical control.

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "For each attention layer n >= 2, replacing only its value tensor V_n with 0.5 * V_1 + 0.5 * V_n, while retaining that layer's own Q, K, attention matrix, output projection, and all ordinary hidden-state residuals, will preserve early token information and lower held-out next-token loss/AUC under the fixed Titan TPP30 protocol without a material systems regression.",
  "idea_id": "idea_c82794cd571f4819"
}
matched control
{
  "change": "Disabled config switch must be numerically identical to the canonical TransformerMoE baseline, including parameter count and state dict behavior.; Use the exact canonical about-1B-total/about-100M-active Titan TPP30 baseline on 8 GPUs with matched tokens, seed, data order, tokenizer, batch, optimizer, LR schedule, parallelism, compile mode, and evaluator.; Change only the identity_resformer_value_residual mechanism: no learnable lambda, no hidden-state residual, no Q/K/attention-map change, no optimizer or objective change.; Run required focused smoke and functional tests before launch, including off-switch parity, exact 0.5 value equation, finite gradients, wrapper compatibility, AC/FSDP path, and gradient contribution to first-layer W_V from later layers.; Use a 300-step full-shape prefix probe only as a diagnostic gate, then a matched 3000-step A/B with warmup 100 and cooldown 900 for the decision.",
  "idea_id": "idea_c82794cd571f4819"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
  "idea_id": "idea_c82794cd571f4819",
  "implementation_material_sha256": "009a5bc78f3a519239a357fa1425f506b938c823898611e09499044a9b3f83c2",
  "metric_identities": [
    {
      "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_9cea7fa62ed14562",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Implement one switch whose disabled path is numerically identical to the canonical baseline; do not bundle any second architecture or optimizer change.
  2. First run a 3-optimizer-step smoke. If depth is shortened, change only n_layers and trim attention_window to the shortened pattern; preserve width, experts, head geometry, and all other model behavior.
  3. Then run a 300-step full-shape prefix probe on 8 GPUs, preserving the complete 3000-step scheduler horizon (100 warmup, cooldown beginning at step 2100). Treat this as a diagnostic, not final evidence.
  4. Only proceed to the matched 3000-step A/B if the smoke is finite, the off-switch parity check passes, and the 300-step loss/AUC and systems metrics show no regression that already falsifies the idea.
  5. Use the exact canonical about-1B-total/about-100M-active TPP30 protocol on 8 GPUs, with identical seed, data order, tokenizer, global batch, optimizer, schedule, parallelism, compile mode, and evaluator.
  6. Record resolved config, git SHA, seed, tokenizer version, dataset manifest, actual token count/TPP, wall time, tokens/s, peak memory, allocation retries/OOMs, and W&B run ids in the separate Autoresearch project.
  7. The mechanism is exact: V_1 = H_0 W_V_1; for every layer n >= 2 use V_mix = 0.5 * V_1 + 0.5 * (H_(n-1) W_V_n), then multiply that layer's own attention probabilities by V_mix.
  8. The smoke must contain at least two attention layers so the candidate path executes; assert V_1 receives gradient contributions from later layers.
  9. Measure V_1/V_n cosine similarity and norms by depth, first-layer W_V gradient norm, per-layer attention entropy, and attention mass on BOS/punctuation sinks at sparse diagnostic intervals.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_89e7f3b061ed4fb9
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
1a99e336d0011431ea9a5ca0cdbd9977b5cf2e2c
Branch
auto-research/idea_c82794cd571f4819/probe-dp4-candidate_d9e7a06283f56e4bd236
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_d9e7a06283f56e4bd236
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_d9e7a06283f56e4bd236.local.yaml
Config SHA-256 (recorded, unverified)
d2438165ce97f77b7f4235658473ccfe4ce8becd6a91a236b79453fb39cafb38
Actual config SHA-256
d2438165ce97f77b7f4235658473ccfe4ce8becd6a91a236b79453fb39cafb38
Resolved config SHA-256 (recorded, unverified)
5b2c5247ac849cbd3dbe6e171a92f11839921914492272436dbdf8e423b37685
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_d9e7a06283f56e4bd236.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Cautious momentum update masking

P0Score 0.82local rejectedSmoke passed

Changing momentum-based optimizer updates to an elementwise cautious variant that applies only update coordinates aligned with the current gradient should improve held-out decoder pretraining loss at matched tokens because it suppresses ...

Evidence

The source proposes a cautious variant of momentum-based optimizers such as AdamW and Lion: suppress update coordinates when the proposed momentum update and current gradient are not aligned. It claims this preserves useful stability pro...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.718270
100.0%300 / 300 (100.0%)Training loss 4.025 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 4.025300 vs control 3.307000 (delta +0.718300). No 3000-step pair was launched.

View details
Idea details

Cautious momentum update masking

Lifecyclelocal rejected
PriorityP0
Score0.82
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 4.025 at step 300
Matched baseline

probe-dp4-control_f14243b6b2d9082a2700

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.718270

Directional gate

Global loss gate did not pass: candidate 4.025300 vs control 3.307000 (delta +0.718300). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing momentum-based optimizer updates to an elementwise cautious variant that applies only update coordinates aligned with the current gradient should improve held-out decoder pretraining loss at matched tokens because it suppresses momentum-driven overshoot and oscillatory coordinates while preserving the base optimizer's main hyperparameters.

Evidence

The source proposes a cautious variant of momentum-based optimizers such as AdamW and Lion: suppress update coordinates when the proposed momentum update and current gradient are not aligned. It claims this preserves useful stability properties and improves LLM pretraining perplexity in 100M LLaMA C4 runs and FineWeb-Edu scaling comparisons, with minimal hyperparameter changes.

Current evidence
  • internal repository analysisTitan repository analysis: Cautious momentum update masking

    The local 1B Titan falsifier is implementable as an optimizer-local Muon change. The target run uses scripts/runs/tiny.yaml over configs/ablations/baseline_4b_moe.yaml, whose optimizer class is poolside.titan.optimizers.Muon with mixed M...

  • arxivCautious Optimizers: Improving Training with One Line of Code

    AdamW has been the default optimizer for transformer pretraining. For many years, our community searched for faster and more stable optimizers with only constrained positive outcomes. In this work, we propose a \textbf{one-line modificat...

  • arxivCautious Optimizers: Improving Training with One Line of Code

    AdamW has been the default optimizer for transformer pretraining. For many years, our community searched for faster and more stable optimizers with only constrained positive outcomes. In this work, we propose a \textbf{one-line modificat...

  • internal implementation failureImplementation failure: Cautious momentum update masking

    Superseded as a confirmed duplicate of tested implementation action action_60a5a690ca6e410c

Required controls
  1. Exact baseline optimizer match: compare against Titan's current optimizer recipe with identical parameter groups, weight decay, LR schedule, warmup, gradient clipping, batch size, tokenizer, data, and model config.
  2. Token match: run candidate and control for the same 3000-step local token budget before interpreting any throughput-adjusted result.
  3. Seed policy: use the same seed and data order when practical; repeat or compare against established local baseline variance if the effect is near noise.
  4. Intervention isolation: only add the cautious elementwise alignment mask to eligible momentum-based update tensors; no LR retuning in the first falsifier.
  5. Optimizer-specific confound: if applying to Muon rather than AdamW, separately verify the mask is well-defined for Titan's matrix update direction and does not bundle an optimizer-family change.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_60a5a690ca6e410c
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
caa6e0f4300f8eac0b88e3754d9cfd4532e199fa
Branch
auto-research/idea_720cfdb19bfc4041/probe-dp4-candidate_e64ea0c60ca321c56c6b
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_e64ea0c60ca321c56c6b
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_e64ea0c60ca321c56c6b.local.yaml
Config SHA-256 (recorded, unverified)
fee71d876b6d6579a15e1a06eb968f2ed19324552b14fd34522599eafed98ec3
Actual config SHA-256
fee71d876b6d6579a15e1a06eb968f2ed19324552b14fd34522599eafed98ec3
Resolved config SHA-256 (recorded, unverified)
51c78e6513e086cd950f6655bcf7fd70090085edb503b6dab7105592ce377221
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_e64ea0c60ca321c56c6b.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Horizon-free inverse-sqrt LR schedule

P0Score 0.82local rejectedSmoke passed

Changing the pretraining learning-rate schedule from fixed-horizon cosine/WSD to a warmup plus shifted inverse-square-root base with final linear decay should improve held-out base-model loss at matched tokens and optimizer steps because...

Evidence

WSqD replaces WSD's constant stable learning-rate phase with a shifted inverse-square-root base schedule followed by a final linear cooldown. The claimed benefit is that the base schedule is horizon-independent, so the peak learning rate...

LOCAL completedMatched step-3000 evaluation found no benefit: composite_v2 1.818244 versus 1.814486 control (candidate +0.003758 worse; lower is better), all four components favored control, and the result failed the predeclared requirement to beat the...
100.0%3000 / 3000 (100.0%)Composite score 1.818 at step 3000W&B poolside/Monstertitan
View details
Idea details

Horizon-free inverse-sqrt LR schedule

Lifecyclelocal rejected
PriorityP0
Score0.82
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

LOCAL completed

100.0%3000 / 3000 (100.0%)Composite score 1.818 at step 3000
Matched baseline

local_baseline_seed42_v1

Experiment conclusion

Matched step-3000 evaluation found no benefit: composite_v2 1.818244 versus 1.814486 control (candidate +0.003758 worse; lower is better), all four components favored control, and the result failed the predeclared requirement to beat the measured MDE. Do not spend another seed on this configuration.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing the pretraining learning-rate schedule from fixed-horizon cosine/WSD to a warmup plus shifted inverse-square-root base with final linear decay should improve held-out base-model loss at matched tokens and optimizer steps because the horizon-independent base schedule avoids suboptimal peak-rate and stable-phase choices when the effective training horizon changes.

Evidence

WSqD replaces WSD's constant stable learning-rate phase with a shifted inverse-square-root base schedule followed by a final linear cooldown. The claimed benefit is that the base schedule is horizon-independent, so the peak learning rate need not be retuned when training is extended. The source reports language-model pretraining experiments on SlimPajama where WSqD matches or outperforms tuned WSD and other schedules across multiple horizons while reusing one peak learning rate.

Current evidence
  • internal repository analysisTitan repository analysis: Horizon-free inverse-sqrt LR schedule

    WSqD is locally implementable as a narrow extension to the existing trapezoidal_lr scheduler. The safe activation is exactly one optional scalar, lr_scheduler.init_args.shift_steps=2900, with shift_steps=None preserving the current trape...

  • internal repository analysisTitan repository analysis: Horizon-free inverse-sqrt LR schedule

    WSqD is locally implementable as a tightly scoped extension of the existing trapezoidal_lr scheduler plus focused scheduler tests. No model, optimizer, loss, data, tokenizer, masking, wrapper, or parallelism code needs to change. The saf...

  • internal repository analysisTitan repository analysis: Horizon-free inverse-sqrt LR schedule

    The request is locally implementable as an LR-only intervention. The target tree already routes configs through poolside.titan.optimizers.trapezoidal_lr and LambdaLR/LRSchedulersContainer, so the smallest implementation is a single optio...

  • internal implementation failureImplementation failure: Horizon-free inverse-sqrt LR schedule

    Operational workflow failure before scientific evaluation: The service restarted during Codex execution; the preserved worktree requires inspection

13 earlier records are available in the full idea history.

Required controls
  1. Baseline: current Titan optimizer and learning-rate schedule for the same 1B-total/100M-active MoE config, with all architecture, data mixture, tokenizer, batch size, optimizer hyperparameters, and training length unchanged except LR schedule.
  2. Token/FLOP match: compare at identical token count and optimizer step count; also report any wall-clock or throughput difference but do not count it as quality evidence.
  3. Seed policy: use the same seed and data order as the matched baseline when practical; if variance is material, run at least the canonical repeated-seed baseline calibration or a second WSqD seed.
  4. Intervention-specific confound: tune peak LR budget equivalently to WSD/cosine or freeze the existing peak LR by design; avoid giving WSqD extra hyperparameter search.
  5. Cooldown confound: predefine cooldown start and length for each horizon, and include a WSD baseline with the same cooldown length where applicable.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
f381a509a71eab4bab1853e236964c52b9a0f846
Branch
auto-research/idea_e17af23e8a484933/local_b717ec317f1d4a7bd5e9_recovery_nograph
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/local_b717ec317f1d4a7bd5e9_recovery_nograph
Configuration
/persistent/.local/state/george-auto-research/run_configs/local_b717ec317f1d4a7bd5e9_recovery_dp4_fullac.local.yaml
Config SHA-256 (recorded, unverified)
ae629fadf6961fb921c46a50dc85b18af4ca3c4bc21bc30eec8f3feb1a51fc44
Actual config SHA-256
ae629fadf6961fb921c46a50dc85b18af4ca3c4bc21bc30eec8f3feb1a51fc44
Resolved config SHA-256 (recorded, unverified)
8a35de507e06b8ef748b5c6c5e60cfbcedb8736ecb40f5a66b4ea2fec86495ba
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/local_b717ec317f1d4a7bd5e9_recovery_dp4_fullac.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Weight-decayed RMS-matched Muon

P0Score 0.78local rejectedRQC v8 staleSmoke passed

Changing matrix-parameter optimization from AdamW or unscaled Muon to weight-decayed, update-RMS-matched Muon should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because orthogonalized matrix u...

Evidence

The source claims Muon scales to large decoder-only LLM pretraining when two recipe changes are added: AdamW-style weight decay to control weight and activation RMS growth, and per-matrix update scaling/RMS matching so Muon updates resem...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.040382
100.0%300 / 300 (100.0%)Training loss 3.35 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.349509 vs control 3.309127 (delta +0.040382). No 3000-step pair was launched.

View details
Idea details

Weight-decayed RMS-matched Muon

Lifecyclelocal rejected
PriorityP0
Score0.78
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.35 at step 300
Matched baseline

probe-dp4-control_23aca65423f2706e73fa

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.040382

Directional gate

Global loss gate did not pass: candidate 3.349509 vs control 3.309127 (delta +0.040382). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing matrix-parameter optimization from AdamW or unscaled Muon to weight-decayed, update-RMS-matched Muon should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because orthogonalized matrix updates provide better spectral-norm-conditioned descent while the added scaling and weight decay stabilize large-scale RMS growth.

Evidence

The source claims Muon scales to large decoder-only LLM pretraining when two recipe changes are added: AdamW-style weight decay to control weight and activation RMS growth, and per-matrix update scaling/RMS matching so Muon updates resemble AdamW update magnitudes. It reports dense scaling-law evidence versus tuned AdamW and a large MoE model trained with the resulting optimizer recipe.

Current evidence
  • internal repository analysisTitan repository analysis: Weight-decayed RMS-matched Muon

    Feasible locally with configuration changes and focused tests. The target tree already has the essential optimizer mechanism: Muon for suitable matrix parameters, Adam fallback for embeddings/output/0D/1D parameters, AdamW-style decouple...

  • arxivMuon is Scalable for LLM Training

    Recently, the Muon optimizer based on matrix orthogonalization has demonstrated strong results in training small-scale language models, but the scalability to larger models has not been proven. We identify two crucial techniques for scal...

  • internal implementation failureImplementation failure: Weight-decayed RMS-matched Muon

    Implementation audit requested repair: Trusted check trusted_gpu_verification failed: tests.titan.test_optimizers::test_muon_step_2device [failure] AssertionError: assert {'param_group..., 'state': {}} == {'param_group..., 'state': {}} O...

1 earlier records are available in the full idea history.

Research question certificate

RQC v8

RQC v8 stale
StatusStale or invalidated
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Run the standard eight-GPU Titan MoE local falsifier, approximately 1B total and 100M active parameters, for exactly 3000 optimizer steps with 100 warmup steps and 900 cooldown steps. Candidate changes only the matrix-parameter optimizer recipe to the specified weight-decayed, RMS-matched Muon path; baseline uses the current matched Titan optimizer recipe. Reject if composite_v2 or held-out validation loss is not better than the matched baseline by more than measured local baseline variance, or if the gain disappears under measured optimizer-FLOP and throughput accounting.

Mechanism and tension

Changing matrix-shaped Transformer and MoE expert parameters from the current AdamW or unscaled Muon baseline to Muon with AdamW-style decoupled weight decay, five-step Newton-Schulz orthogonalization, momentum 0.95, sqrt(max(A,B)) per-matrix update scaling, and AdamW-like update RMS matching should lower held-out decoder pretraining loss and composite_v2 at matched tokens or matched measured FLOPs because orthogonalized updates improve spectral-norm-conditioned descent while weight decay and RMS matching control large-scale weight and activation RMS growth. Tension: Incorrect parameter grouping could send embeddings, LM head, RMSNorm, scalar, or vector parameters through the Muon path.; A variant weight-decay equation could test the wrong mechanism, especially LR-independent shrinkage rather than the source-style coupled decoupled update.; Distributed Muon state or DTensor behavior could regress checkpointing, state_dict serialization, or multi-GPU equivalence.; Optimizer metrics may undercount weight-decay update norm, update RMS, communication overhead, or FLOPs.; Numerical range issues could appear in bf16/fp8 despite small local tests passing.

Certificate cannot authorize work

[ "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Changing matrix-parameter optimization from AdamW or unscaled Muon to weight-decayed, update-RMS-matched Muon should improve held-out decoder pretraining loss under matched tokens or matched measured FLOPs because orthogonalized matrix updates provide better spectral-norm-conditioned descent while the added scaling and weight decay stabilize large-scale RMS growth.",
  "idea_id": "idea_2507927fd7424bc4"
}
matched control
{
  "change": "Use a matched Titan baseline inheriting the same tiny.yaml source config with identical data, tokenizer, architecture, batch, scheduler, warmup, cooldown, and 3000-step token budget.; Compare against Titan's current optimizer recipe, not an artificially weak or untuned AdamW baseline.; Use the same seed when practical; otherwise report matched seed policy and baseline variance.; Report both equal-token results and measured optimizer FLOPs/throughput so compute-adjusted interpretation is explicit.; Keep non-matrix parameter handling on AdamW and identical except for the source-defined fallback rule.; Pin Muon coefficients a=3.4445, b=-4.7750, c=2.0315, N=5, momentum 0.95, decoupled weight decay, and 0.2*sqrt(max(A,B)) style scaling in focused tests.",
  "idea_id": "idea_2507927fd7424bc4"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
  "idea_id": "idea_2507927fd7424bc4",
  "implementation_material_sha256": "dbd6881e435c9954fdb46b53c253d4b3a68ab79688c06674dec655d82c072ba1",
  "metric_identities": [
    {
      "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_f2b69225630d4470",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Matched AdamW baseline with tuned scaling-law hyperparameters at equal compute budget
  2. Same seed when practical for Titan local test
  3. Equal-token 3000-step local comparison and measured-FLOP reporting for optimizer overhead
  4. Keep non-matrix parameter handling identical except for the reported AdamW fallback rule
  5. Compare against Titan's current Muon or AdamW baseline depending on the active recipe, not against an untuned optimizer
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_915f27bf5bba45ac
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
f5b95625e729ea067bc6685f742bf5b53a774b33
Branch
auto-research/idea_2507927fd7424bc4/probe-dp4-candidate_80999ab4e48e7676b9ef
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_80999ab4e48e7676b9ef
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_80999ab4e48e7676b9ef.local.yaml
Config SHA-256 (recorded, unverified)
dd8cbbe59e3d56e15aeec493e642f83e77096709a766c670e18d4042677e9cbb
Actual config SHA-256
dd8cbbe59e3d56e15aeec493e642f83e77096709a766c670e18d4042677e9cbb
Resolved config SHA-256 (recorded, unverified)
81fb201229ba3912fc9850d60a2693b4a470b4e66f66b5fa94f0104df8492f3c
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_80999ab4e48e7676b9ef.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Cosine MLP width taper

P0Score 0.78local rejectedRQC v24 staleSmoke passed

Changing uniform per-layer MLP intermediate width to a cosine front-loaded taper at fixed total parameters and active FLOPs should improve held-out decoder pretraining loss under matched tokens because earlier MLPs write more novel resid...

Evidence

The source proposes Tapered Language Models: replace a constant MLP intermediate dimension with a monotone per-layer width schedule under a fixed total parameter budget. The reported best default is a cosine taper with start/end MLP widt...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.024637
100.0%300 / 300 (100.0%)Training loss 3.317 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.317148 vs control 3.292511 (delta +0.024637). No 3000-step pair was launched.

View details
Idea details

Cosine MLP width taper

Lifecyclelocal rejected
PriorityP0
Score0.78
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.317 at step 300
Matched baseline

probe-dp4-control_be15d7e1243573f04baf

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.024637

Directional gate

Global loss gate did not pass: candidate 3.317148 vs control 3.292511 (delta +0.024637). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing uniform per-layer MLP intermediate width to a cosine front-loaded taper at fixed total parameters and active FLOPs should improve held-out decoder pretraining loss under matched tokens because earlier MLPs write more novel residual information while later MLPs are more redundant and can use less capacity.

Evidence

The source proposes Tapered Language Models: replace a constant MLP intermediate dimension with a monotone per-layer width schedule under a fixed total parameter budget. The reported best default is a cosine taper with start/end MLP widths at 1.5/0.5 times the uniform width, rounded to efficient multiples while preserving total MLP parameters. Other dimensions and training hyperparameters are held fixed. The claimed mechanism is that early MLPs add more novel residual information while later MLPs increasingly reinforce existing residual content, so capacity should be front-loaded across depth.

Current evidence
  • internal repository analysisTitan repository analysis: Cosine MLP width taper

    The cosine MLP width taper is locally feasible as a narrow Titan MoE architecture change, but the target snapshot does not yet contain mlp_taper support. The smallest faithful implementation adds a budget-preserving per-layer width sched...

  • internal failure diagnosisTraining failure diagnosis: Cosine MLP width taper

    The MLP taper creates heterogeneous routed/shared expert widths across MoE layers, which leads Muon Newton-Schulz normalization to see multiple tensor shapes during optimizer.step. The attempted guard only disables CUDA graphs, but the f...

  • internal failure diagnosisTraining failure diagnosis: Cosine MLP width taper

    The new MLP taper creates layer-dependent expert intermediate widths, which makes Muon process Newton-Schulz blocks with heterogeneous tensor shapes. The candidate only gates CUDA graph use, but the failing frame is TorchDynamo recompila...

  • internal implementation failureImplementation failure: Cosine MLP width taper

    Implementation audit requested repair: The focused acceptance coverage required before launch is incomplete. The authoritative `unified_diff` adds schedule, shape, accounting, activation-checkpoint, and Muon helper/unit tests, but it doe...

16 earlier records are available in the full idea history.

Research question certificate

RQC v24

RQC v24 stale
StatusStale or invalidated
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Implement a reversible mlp_taper config for the standard 1B-total, 100M-active Titan MoE candidate using cosine_1p5_0p5. After focused functional tests pass, train candidate and uniform control for exactly 3000 steps with matched seed/data order when practical. Reject if held-out loss or composite_v2 does not improve beyond measured matched-baseline variance at equal tokens and comparable measured active FLOPs; mark inconclusive if rounding or throughput makes the compute comparison materially unequal.

Mechanism and tension

Changing uniform per-layer MoE MLP intermediate width to a cosine front-loaded taper with start/end ratios 1.5/0.5 should improve held-out decoder pretraining loss or composite_v2 under matched tokens and active FLOPs because earlier MLPs may write more novel residual information while later MLP capacity is more redundant. Tension: Incorrect width rounding could silently change parameter or active-FLOP budgets.; Heterogeneous expert shapes could break QAT, checkpoint loading, distributed sharding, or overlapped expert execution.; Muon Newton-Schulz compilation could recompile or fail on heterogeneous parameter shapes if the repair is incomplete.; Throughput loss could erase any equal-token gain under equal-compute accounting.; Front-loaded capacity could change router dynamics or layerwise activation/gradient stability.

Certificate cannot authorize work

[ "material context changed", "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Changing uniform per-layer MLP intermediate width to a cosine front-loaded taper at fixed total parameters and active FLOPs should improve held-out decoder pretraining loss under matched tokens because earlier MLPs write more novel residual information while later MLPs are more redundant and can use less capacity.",
  "idea_id": "idea_cc4eda14e35f47fa"
}
matched control
{
  "change": "Uniform per-layer MLP intermediate width baseline with same total parameters, active parameters, active FLOPs, depth, hidden size, attention, router, top-k, tokenizer, data, optimizer, LR schedule, batch, and sequence length.; Candidate differs only by cosine MLP width taper d_start/d_uniform=1.5 and d_end/d_uniform=0.5, with first and last widths fixed and interior widths adjusted to preserve total MLP budget.; Run the standard 1B-total, 100M-active MoE pilot for exactly 3000 steps, 100 warmup steps, and 900 cooldown steps.; Use the same seed and data order when practical; otherwise compare against the measured matched-baseline variance threshold.; Audit and report total parameters, active parameters, active FLOPs, width schedule, and throughput before launching the experiment.",
  "idea_id": "idea_cc4eda14e35f47fa"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
  "idea_id": "idea_cc4eda14e35f47fa",
  "implementation_material_sha256": "08b2e060bb6e19b32ae21366cad58276cb8677ee6dfacfcaeb23f448a329210d",
  "metric_identities": [
    {
      "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_78b8e15d261a4685",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Uniform per-layer MLP intermediate width baseline with the same total parameter count, training FLOPs, inference FLOPs, depth, residual dimension, attention head count, key-value dimension, tokenizer, data, optimizer, LR schedule, and batch size.
  2. Equal-token local falsifier on the standard approximately 1B-total/100M-active MoE 3000-step pilot, with candidate and control sharing seed and data order when practical.
  3. Equal-active-FLOP interpretation for MoE: changing expert MLP width by layer must preserve active expert FLOPs and total/active parameter accounting, or report any mismatch explicitly.
  4. Single intervention only: cosine depth taper of MLP intermediate width; no concurrent changes to router, top-k, attention windows, optimizer, objective, or tokenizer.
  5. Endpoint ratio preregistered from the source default, d_ff start/end = 1.5/0.5 times the uniform width, rounded to hardware multiples while preserving the same total MLP parameter budget.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_48234c89910b4b42
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
cb2457dd57a37527fc6d84e95fdd0eafebf6fbbd
Branch
auto-research/idea_cc4eda14e35f47fa/probe-dp4-candidate_314013bcdd62017902e1
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_314013bcdd62017902e1
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_314013bcdd62017902e1.local.yaml
Config SHA-256 (recorded, unverified)
dbf6336c5890dfe8c6f0746ba04ec21270b4a0047c17fa8454071720f7fabadc
Actual config SHA-256
dbf6336c5890dfe8c6f0746ba04ec21270b4a0047c17fa8454071720f7fabadc
Resolved config SHA-256 (recorded, unverified)
fa30896fbae272fd45bd945523bf2675c2ff66024eee6f390759abd009283d1c
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_314013bcdd62017902e1.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Global-batch MoE load balancing

P0Score 0.78local rejectedRQC v5 staleSmoke passed

Changing MoE load-balancing loss from micro-batch-local frequency estimates to global-batch frequency estimates should improve held-out decoder pretraining loss at matched tokens because it relaxes per-sequence uniform routing pressure a...

Evidence

The source argues that standard MoE load-balancing loss is often computed within tiny micro-batches, effectively forcing each sequence to spread tokens uniformly across experts and suppressing specialization. It proposes computing the ex...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.003253
100.0%300 / 300 (100.0%)Training loss 3.297 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.297273 vs control 3.294019 (delta +0.003253). No 3000-step pair was launched.

View details
Idea details

Global-batch MoE load balancing

Lifecyclelocal rejected
PriorityP0
Score0.78
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.297 at step 300
Matched baseline

probe-dp4-control_eec63d0ba7f03d5051c5

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.003253

Directional gate

Global loss gate did not pass: candidate 3.297273 vs control 3.294019 (delta +0.003253). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing MoE load-balancing loss from micro-batch-local frequency estimates to global-batch frequency estimates should improve held-out decoder pretraining loss at matched tokens because it relaxes per-sequence uniform routing pressure and permits domain-specialized experts while preserving corpus-level load balance.

Evidence

The source argues that standard MoE load-balancing loss is often computed within tiny micro-batches, effectively forcing each sequence to spread tokens uniformly across experts and suppressing specialization. It proposes computing the expert selection frequency term over the global batch via synchronization across micro-batches, preserving corpus-level balance while allowing sequence or domain-level routing concentration.

Current evidence
  • internal repository analysisTitan repository analysis: Global-batch MoE load balancing

    The idea is locally implementable as a narrow MoELayer router-loss scope switch, but the current target tree already computes the existing global balance loss from TP-gathered scores and DP/TP-reduced token counts for each forward microb...

  • arxivDemons in the Detail: On Implementing Load Balancing Loss for Training Specialized Mixture-of-Expert Models

    This paper revisits the implementation of $\textbf{L}$oad-$\textbf{b}$alancing $\textbf{L}$oss (LBL) when training Mixture-of-Experts (MoEs) models. Specifically, LBL for MoEs is defined as $N_E \sum_{i=1}^{N_E} f_i p_i$, where $N_E$ is ...

  • internal implementation failureImplementation failure: Global-batch MoE load balancing

    Operational workflow failure before scientific evaluation: Implementation Codex exited 1: /action_9ea7951192194736 does not exist. 2026-07-16T23:34:11.364366Z ERROR codex_protocol::permissions: Resolved gitdir path /persistent/poolside/t...

Research question certificate

RQC v5

RQC v5 stale
StatusStale or invalidated
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Implement a reversible moe_global_balance_loss_scope knob with micro_batch control and global_batch candidate. Before launch, run focused functional tests for exact LBL equation differences, padding exclusion, unchanged routed outputs, unchanged router metrics, and 4-GPU distributed DP/TP/EGP coverage. Then train matched eight-GPU approximately 1B-total, 100M-active Titan MoE control and candidate for 3000 steps with 100 warmup and 900 cooldown. Falsify if candidate fails to improve held-out validation loss or composite_v2 beyond calibrated baseline variance, or if the gain disappears after measured throughput/communication overhead is included.

Mechanism and tension

Changing MoE load-balancing loss from micro-batch-local expert selection frequency estimates to global-batch frequency estimates should improve held-out decoder pretraining loss at matched tokens because it relaxes near sequence-level uniform-routing pressure while preserving corpus-level expert load balance, enabling more useful expert specialization. Tension: Incorrect collective placement could change routing, expert dispatch, or activation-checkpoint replay semantics.; Padding exclusion or fused token/padding count handling could regress under the new scope knob.; Router specialization could destabilize load balance or create expert starvation.; Extra DP/TP synchronization could reduce throughput or alter equal-compute interpretation.; Metrics based on tokens_per_expert could accidentally change if dispatch counts and LBL counts are conflated.; 17B MTP and FP8 paths could expose distributed behavior not covered by single-process tests.

Certificate cannot authorize work

[ "material context changed", "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Changing MoE load-balancing loss from micro-batch-local frequency estimates to global-batch frequency estimates should improve held-out decoder pretraining loss at matched tokens because it relaxes per-sequence uniform routing pressure and permits domain-specialized experts while preserving corpus-level load balance.",
  "idea_id": "idea_fa55e0cc92d34f43"
}
matched control
{
  "change": "Matched Titan MoE baseline using existing micro-batch LBL frequency scope with identical architecture, data, tokenizer, optimizer, schedule, global batch, sequence length, router top-k, LBL coefficient, padding behavior, and seed when practical.; Candidate changes only moe_global_balance_loss_scope from micro_batch to global_batch by synchronizing selected-expert frequency statistics across the full global batch before computing LBL.; Run control and candidate for exactly 3000 optimizer steps with 100 warmup steps and 900 cooldown steps on the standard eight-GPU approximately 1B-total, 100M-active MoE gate.; Interpret equal-token loss alongside measured throughput and communication overhead so any gain can be assessed under matched compute.",
  "idea_id": "idea_fa55e0cc92d34f43"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
  "idea_id": "idea_fa55e0cc92d34f43",
  "implementation_material_sha256": "949a6114d6888d3b291d0195065ba8810c7574cc4e7654761931581b5916400a",
  "metric_identities": [
    {
      "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_311d6891b6b4464e",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Matched Titan MoE baseline using existing micro-batch LBL with identical architecture, data, tokenizer, optimizer, schedule, global batch, sequence length, and router top-k.
  2. Candidate changes only LBL aggregation scope by synchronizing selected-expert frequencies across the full global batch before computing LBL.
  3. Run candidate and control for the same 3000 optimizer steps and token budget with the same seed when practical.
  4. Report measured throughput and communication overhead; interpret equal-token loss both raw and with measured-FLOP adjustment.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_b0d79214316e445a
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
2a17ae471879b4261ec94d27d897928951f11402
Branch
auto-research/idea_fa55e0cc92d34f43/probe-dp4-candidate_4bd40a476607d711d3ce
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_4bd40a476607d711d3ce
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_4bd40a476607d711d3ce.local.yaml
Config SHA-256 (recorded, unverified)
f6d8ef544ef59d3cec5a9d47cf917eb654b35495a0fb31bf115a4e703895dbe3
Actual config SHA-256
f6d8ef544ef59d3cec5a9d47cf917eb654b35495a0fb31bf115a4e703895dbe3
Resolved config SHA-256 (recorded, unverified)
0e85f444bd17a45dd8859e62f60241705f69dda6d90ab1de50cef2fa7777127a
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_4bd40a476607d711d3ce.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Selective Muon for associative memories

P0Score 0.76local inconclusiveRQC v48 staleSmoke passed

Changing optimizer assignment so only VO attention weights and FFN matrices use Muon while other parameters retain the baseline optimizer should improve held-out decoder pretraining loss at matched tokens because Muon's orthogonalized ma...

Evidence

The source argues that Muon's advantage over Adam in LLM pretraining comes primarily from transformer associative-memory parameters: attention value/output projections and FFN matrices. It reports FineWeb NanoGPT ablations that apply Muo...

Current blocker

Local result is blocked by mismatched or invalid evidence

LOCAL completedLocal result is blocked by mismatched or invalid evidence
100.0%3000 / 3000 (100.0%)Composite score 1.819 at step 3000W&B poolside/Autoresearch
View details
Idea details

Selective Muon for associative memories

Lifecyclelocal inconclusive
PriorityP0
Score0.76
Decision now

This idea is in local inconclusive. The current gate and any live recovery appear below.

Experiment

LOCAL completed

100.0%3000 / 3000 (100.0%)Composite score 1.819 at step 3000
Matched baseline

local-pp3dp2-control_e42c1f814e7313efc8ca

Experiment conclusion

Local result is blocked by mismatched or invalid evidence

Current blocker

Local result is blocked by mismatched or invalid evidence

Gate: local result integrity.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing optimizer assignment so only VO attention weights and FFN matrices use Muon while other parameters retain the baseline optimizer should improve held-out decoder pretraining loss at matched tokens because Muon's orthogonalized matrix updates better fit associative-memory outer-product learning on heavy-tailed token distributions.

Evidence

The source argues that Muon's advantage over Adam in LLM pretraining comes primarily from transformer associative-memory parameters: attention value/output projections and FFN matrices. It reports FineWeb NanoGPT ablations that apply Muon to individual transformer components and combined subsets, finding VO and FFN blocks are the main contributors, and supports the claim with a one-layer associative-memory analysis under heavy-tailed class frequencies.

Current evidence
  • internal repository analysisTitan repository analysis: Selective Muon for associative memories

    Selective Muon is locally feasible as a small optimizer parameter-group extension. The target tree already has broad Muon grouping for all eligible matrix parameters except tok_embeddings/output, plus search_param_name canonicalization f...

  • internal failure diagnosisTraining failure diagnosis: Selective Muon for associative memories

    The candidate change intended to call `cache_model_ema_weight_refs(model_parts)` before EMA updates, but in the failing distributed training path the router being updated still has `self._ema_weight_refs is None`. This means the cache ca...

  • internal failure diagnosisTraining failure diagnosis: Selective Muon for associative memories

    The training path reaches router EMA update before router EMA weight references have been cached. The earliest root exception is an AssertionError in `poolside/titan/models/moe/routers.py:301` with message `cache_ema_weight_refs was not ...

  • internal implementation failureImplementation failure: Selective Muon for associative memories

    Implementation audit requested repair: Trusted check trusted_gpu_verification failed: tests.titan.test_moe_router_ema::test_router_ema_parallelism_invariant [failure] torch.distributed.DistBackendError: NCCL error in: /pytorch/torch/csrc...

11 earlier records are available in the full idea history.

Research question certificate

RQC v48

RQC v48 stale
StatusStale or invalidated
Maximum runs4
Maximum tokens12582912000
Falsifiable hypothesis

Run the standard approximately 1B-total, 100M-active Titan MoE falsifier on eight GPUs for exactly 3000 steps with 100 warmup and 900 cooldown steps. Candidate sets training.muon_params_regex to select only layers.<n>.attention.wv/wo weights, dense feed_forward w1/w2/w3 weights, moe.routed_experts w1/w2/w3 tensors, and moe.shared_expert w1/w2/w3 weights after mandatory existing Muon eligibility. Control leaves selector null/unset. Falsify if candidate composite_v2 on validation does not beat control by more than measured local baseline variance, or if any apparent gain is explained by throughput/compute accounting or parameter-selection test failure.

Mechanism and tension

Changing optimizer assignment so only attention value/output projection weights and dense, routed-expert, and shared-expert FFN matrices use Muon, while all other parameters keep the baseline optimizer assignment, should lower validation composite_v2 at matched tokens because Muon's orthogonalized matrix updates better match associative-memory outer-product learning under heavy-tailed token frequencies. Tension: Silent parameter selector mismatch in wrapped, checkpointed, or MoE expert names.; Checkpoint/resume incompatibility from changed mixed optimizer parameter groups.; Regression if removing broad Muon from Q/K or other matrices hurts Titan's current optimizer recipe.; Distributed DTensor Muon stepping could fail on the PP/FSDP path despite CPU selector tests.; Throughput or optimizer memory changes could alter equal-compute conclusions.

Certificate cannot authorize work

[ "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "commit 4832b2c2d6858b859e24f90000ae1c5a08ef9c12, resolved configuration a71773ccd73d6c592c11e2a61a152189d1ade29ab1969ea81f6d419b7027b07c",
  "experiment_id": "local-pp3dp2-candidate_b6e3c2379498d795cac6"
}
matched control
{
  "change": "commit 4832b2c2d6858b859e24f90000ae1c5a08ef9c12, resolved configuration 58b5b396bdc601b077914a82033271f5e6060899ab2706f877b861cd41007823",
  "experiment_id": "local-pp3dp2-control_e42c1f814e7313efc8ca"
}
minimal decisive test
{
  "artifact_node_ids": [
    "claim_node_configuration_b16093badf31935f58a0204c",
    "claim_node_configuration_bc88ee9fa7481c49a7cfbb80"
  ],
  "candidate_experiment_id": "local-pp3dp2-candidate_b6e3c2379498d795cac6",
  "control_experiment_id": "local-pp3dp2-control_e42c1f814e7313efc8ca",
  "evaluator_protocol_hash": "712df48dd8f77c92eb9f286cef91c46c88f77af918b844c77a858d68534491ad",
  "metric_forecasts": [
    {
      "direction": "lower",
      "evaluation_horizon": {
        "steps": 3000,
        "tokens": 3145728000
      },
      "expected_delta": -0.01,
      "falsification_probability": 0.26548172250224655,
      "metric": "composite_v2",
      "metric_identity": {
        "evaluator_version": "712df48dd8f77c92eb9f286cef91c46c88f77af918b844c77a858d68534491ad",
        "name": "composite_v2",
        "split": "validation"
      },
      "split": "validation",
      "uncertainty_interval": {
        "lower": -0.01458450626635916,
        "upper": -0.005415493733640841
      }
    }
  ],
  "metric_identities": [
    {
      "evaluator_version": "712df48dd8f77c92eb9f286cef91c46c88f77af918b844c77a858d68534491ad",
      "name": "composite_v2",
      "split": "validation"
    }
  ]
}
metrics
{
  "primary": {
    "evaluator_version": "712df48dd8f77c92eb9f286cef91c46c88f77af918b844c77a858d68534491ad",
    "name": "composite_v2",
    "split": "validation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 43200.0,
    "max_runs": 2,
    "max_tokens": 6291456000
  },
  "max_gpu_seconds": 86400.0,
  "max_runs": 4,
  "max_steps_per_run": 3000,
  "max_tokens": 12582912000
}
evaluator versions
{
  "composite_v2": "712df48dd8f77c92eb9f286cef91c46c88f77af918b844c77a858d68534491ad"
}
required update after failure
Append the realized forecast error, then weaken or refute the mechanism before planning another test when the preregistered falsifier occurs.
Required controls
  1. Titan baseline optimizer and parameter groups unchanged except for the tested VO/FFN Muon assignment.
  2. Equal token budget and equal optimizer-step schedule for candidate and control at 3000 steps.
  3. Same seed and data order for candidate and baseline when practical.
  4. Compare against both current Titan baseline optimizer grouping and a full eligible-matrix Muon setting if the baseline already uses Muon-like updates.
  5. Report measured throughput and active FLOPs because partial optimizer grouping can change optimizer cost but not model FLOPs.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_f2ee2bfd1b4f4963
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
4832b2c2d6858b859e24f90000ae1c5a08ef9c12
Branch
auto-research/idea_de12bc7d887e43a8/local-pp3dp2-candidate_b6e3c2379498d795cac6
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/local-pp3dp2-candidate_b6e3c2379498d795cac6
Configuration
/persistent/.local/state/george-auto-research/run_configs/local-pp3dp2-candidate_b6e3c2379498d795cac6.local.yaml
Config SHA-256 (recorded, unverified)
fd9d8bef70f96bc0c5e20cf75b1e47c66caa7274050b5e4a44bfb1416a9ce93f
Actual config SHA-256
fd9d8bef70f96bc0c5e20cf75b1e47c66caa7274050b5e4a44bfb1416a9ce93f
Resolved config SHA-256 (recorded, unverified)
a71773ccd73d6c592c11e2a61a152189d1ade29ab1969ea81f6d419b7027b07c
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/local-pp3dp2-candidate_b6e3c2379498d795cac6.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Learnable RoPE frequency scalars

P0Score 0.76local rejectedRQC v9 staleSmoke passed

Changing fixed RoPE frequencies to shared learnable per-frequency log scalars should improve held-out base-model loss at matched pretraining tokens and approximately matched FLOPs because the model can preserve useful high-frequency posi...

Evidence

LeRoPE replaces fixed RoPE frequency bands with shared learned log-space scalars alpha_m, initialized at zero so the model starts exactly as standard RoPE. The source reports decoder-only LM pretraining ladders where LeRoPE beats standar...

Current blocker

Local result is blocked by mismatched or invalid evidence

LOCAL completedPromotion gate failed after the fresh matched 4.27B eight-GPU 300-step prefix: candidate loss improved by 0.0117 nats, but steady throughput regressed 1.63 percent, peak memory increased by 9.54 GiB, only one seed was run, no evaluator/c...
100.0%3000 / 3000 (100.0%)Training loss 1.864 at step 3000W&B poolside/Autoresearch
View details
Idea details

Learnable RoPE frequency scalars

Lifecyclelocal rejected
PriorityP0
Score0.76
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

LOCAL completed

100.0%3000 / 3000 (100.0%)Training loss 1.864 at step 3000
Matched baseline

local-dp4-control_1a96d75164638027440a

Experiment conclusion

Promotion gate failed after the fresh matched 4.27B eight-GPU 300-step prefix: candidate loss improved by 0.0117 nats, but steady throughput regressed 1.63 percent, peak memory increased by 9.54 GiB, only one seed was run, no evaluator/composite/MDE/family-corrected result exists, and targeted learned_rope_alpha DCP reload fails at steps 200 and 300. Do not repeat, extend to 3000 steps, or launch cluster compute without a newly reviewed hypothesis and complete evidence.

Current blocker

Local result is blocked by mismatched or invalid evidence

Gate: local result integrity.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing fixed RoPE frequencies to shared learnable per-frequency log scalars should improve held-out base-model loss at matched pretraining tokens and approximately matched FLOPs because the model can preserve useful high-frequency positional bands while suppressing bands better used for content-invariant matching.

Evidence

LeRoPE replaces fixed RoPE frequency bands with shared learned log-space scalars alpha_m, initialized at zero so the model starts exactly as standard RoPE. The source reports decoder-only LM pretraining ladders where LeRoPE beats standard RoPE and partial RoPE, with the largest reported model requiring about 3.4% more RoPE compute to match LeRoPE loss. The method uses one shared frequency vector across layers and heads, omits weight decay on those parameters, and clips their gradients independently.

Current evidence
  • internal repository analysisTitan repository analysis: Learnable RoPE frequency scalars

    The LeRoPE mechanism is locally implementable in this Titan snapshot, but it is not a config-only toggle. The smallest correct implementation adds one shared zero-initialized learned_rope_alpha vector, applies exp(alpha) to RoPE inverse-...

  • internal failure diagnosisFailure diagnosis correction: Learnable RoPE FSDP boundary

    Correction to action_de2e6758dbe94a95: the failed smoke had tensor_parallel_degree=1 and data_parallel_shard_degree=-1 on four GPUs. The learned_rope_alpha DTensor was created by FSDP fully_shard before init_buffers, not by TP replicatio...

  • internal failure diagnosisTraining failure diagnosis: Learnable RoPE frequency scalars

    After tensor parallelism, learned_rope_alpha can be a replicated DTensor, but precompute_freqs_cis builds inv_freq_extrapolation and inv_freq_interpolation as ordinary torch.Tensor values and multiplies them by alpha_scale derived from t...

  • internal implementation failureImplementation failure: Learnable RoPE frequency scalars

    Implementation audit requested repair: Trusted host verification is not clean: `host_verification.verified` is false and the current touched test run fails in `tests/titan/test_lerope.py::test_learned_rope_alpha_is_parameter_and_regex_we...

5 earlier records are available in the full idea history.

Research question certificate

RQC v9

RQC v9 stale
StatusStale or invalidated
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Run the standard eight-GPU Titan MoE falsifier at about 1B total and 100M active parameters for exactly 3000 steps, 100 warmup steps, and 900 cooldown steps. Control is the current fixed-RoPE config. Candidate enables one shared zero-initialized learned_rope_alpha vector, exp(alpha) scaling of RoPE inverse-frequency bands, no weight decay on alpha, and independent alpha gradient clipping. Reject if held-out loss or composite_v2 is not better than the matched baseline by more than measured baseline variance, or if the gain disappears after active-FLOP and throughput accounting.

Mechanism and tension

Changing fixed RoPE frequencies to shared learned per-frequency log scalars alpha_m, with theta_hat_m = exp(alpha_m) * theta_m, should improve held-out base-model loss or composite_v2 at matched pretraining tokens and approximately matched active FLOPs because the model can retain useful high-frequency positional bands while suppressing bands better used for content-invariant matching. Tension: Alpha DTensor placement may break TP/FSDP frequency construction or silently use a shard-local vector.; MTP runs could accidentally create independent alpha parameters, violating the shared-frequency intervention.; Incorrect alpha initialization would fail to recover exact RoPE at step zero.; No-weight-decay regex or independent clipping could affect other parameters if matched incorrectly.; Differentiable RoPE table rebuild may reduce throughput or alter memory behavior.; Partial RoPE, GA/SWA rope_dim slicing, YaRN, or NTK-by-parts paths could be mishandled.

Certificate cannot authorize work

[ "material context changed", "scientific review evidence is not current" ]

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Changing fixed RoPE frequencies to shared learnable per-frequency log scalars should improve held-out base-model loss at matched pretraining tokens and approximately matched FLOPs because the model can preserve useful high-frequency positional bands while suppressing bands better used for content-invariant matching.",
  "idea_id": "idea_e9e639e8151d4f93"
}
matched control
{
  "change": "Baseline is the identical Titan decoder/MoE config with existing fixed RoPE frequencies and no learned alpha parameters.; Primary comparison is matched-token at exactly 3000 steps, with 100 warmup steps and 900 cooldown steps, using the same tokenizer, data order, optimizer, schedule, and batch settings.; Use the same seed when practical; repeat only if the observed gain is within measured local baseline variance.; Candidate changes only shared per-frequency log scalars initialized to zero, theta_hat_m = exp(alpha_m) * theta_m, shared across layers and heads.; Exclude learned_rope_alpha from weight decay and apply independent alpha gradient clipping while keeping all other optimizer behavior fixed.; Report measured throughput and active FLOPs; do not give the candidate extra tokens or steps for any throughput difference.",
  "idea_id": "idea_e9e639e8151d4f93"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
  "idea_id": "idea_e9e639e8151d4f93",
  "implementation_material_sha256": "8286a7f07bafabcb6f36875ee2c831ae64029c70b047fd85526b2e463945aa3c",
  "metric_identities": [
    {
      "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_fdb7c6a013e44203",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "1f6a47102116d5c7dd47bb8a2c0dfa184700c8da86fe19fdffcae28e865f6432"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Baseline: identical Titan decoder/MoE config with existing RoPE frequencies and no learned frequency parameters.
  2. Token/FLOP match: run equal-token primary comparison and report active-FLOP-adjusted interpretation; LeRoPE adds only d_head/2 shared parameters so compute delta should be negligible but measured.
  3. Seed policy: use matched seed and data order for candidate/control; repeat if gain is within established local baseline variance.
  4. Intervention isolation: only learn shared per-frequency log scalars alpha_m initialized to zero, with theta_hat_m=exp(alpha_m)*theta_m.
  5. Optimizer confound: exclude LeRoPE parameters from weight decay and apply the specified independent gradient clipping, while keeping all other optimizer settings fixed.
  6. Comparison confound: include partial-RoPE or slower-base RoPE only as secondary controls, not as replacements for the exact baseline.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_9a63e405f5b94801
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
8f926c68fc4bee349b35d9a39de086e9ef4dd090
Branch
auto-research/idea_e9e639e8151d4f93/local-dp4-candidate_85350819372fec6fb2ef
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/local-dp4-candidate_85350819372fec6fb2ef
Configuration
/persistent/.local/state/george-auto-research/run_configs/local-dp4-candidate_85350819372fec6fb2ef.local.yaml
Config SHA-256 (recorded, unverified)
5f118eee28c6baae0b2794c082a14b55091186baf09e44679ead74d16c6194b4
Actual config SHA-256
5f118eee28c6baae0b2794c082a14b55091186baf09e44679ead74d16c6194b4
Resolved config SHA-256 (recorded, unverified)
a74d05390ef4466830dee96f2c6cf3009d84cfe01a15ab5bba777121097f01c7
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/local-dp4-candidate_85350819372fec6fb2ef.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

EMA pullback AdamW control

P0Score 0.64local rejectedRQC v26 currentSmoke passed

Changing AdamW training to add PACE's clipped per-coordinate pullback from live weights toward the EMA iterate should improve held-out decoder pretraining loss under matched tokens because the returned averaged model is explicitly optimi...

Evidence

PACE is a lightweight AdamW wrapper for iterate-averaged language models. It keeps an EMA of the weights and adds a clipped, per-coordinate pullback from the live weights toward the EMA, with gain scaled by the Adam second-moment precond...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+1.367324
100.0%300 / 300 (100.0%)Training loss 4.689 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 4.688534 vs control 3.321210 (delta +1.367324). No 3000-step pair was launched.

View details
Idea details

EMA pullback AdamW control

Lifecyclelocal rejected
PriorityP0
Score0.64
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 4.689 at step 300
Matched baseline

probe-dp4-control_75a5a52990a231eb2ec0

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+1.367324

Directional gate

Global loss gate did not pass: candidate 4.688534 vs control 3.321210 (delta +1.367324). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing AdamW training to add PACE's clipped per-coordinate pullback from live weights toward the EMA iterate should improve held-out decoder pretraining loss under matched tokens because the returned averaged model is explicitly optimized to stay closer to the low-oscillation iterate-average estimator while retaining AdamW preconditioning.

Evidence

PACE is a lightweight AdamW wrapper for iterate-averaged language models. It keeps an EMA of the weights and adds a clipped, per-coordinate pullback from the live weights toward the EMA, with gain scaled by the Adam second-moment preconditioner, EMA power, learning rate, pullback strength, and update frequency. The source reports GPT-2 124M FineWeb pretraining improvements over AdamW and EMA baselines across schedules, plus 1-2B fine-tuning evidence.

Current evidence
  • internal repository analysisTitan repository analysis: EMA pullback AdamW control

    PACE is locally implementable as an optimizer/training-loop intervention, not a model change. The smallest faithful implementation is a new AdamW-compatible optimizer with checkpointed EMA state and explicit EMA swap support, plus contai...

  • github repositoryleonou2010/pace-optimizer

    PACE: AdamW with an lr-scaled pullback toward an EMA of the iterates. Training pipeline + one-command reproduction of all paper figures. # PACE A drop-in PyTorch optimizer for iterate-averaged language-model training, and the code comp...

  • arxivTraining for the Model You Return: Improving Optimization for Iterate-Averaged Language Models

    Many modern Language Model (LM) pipelines return an averaged model, such as an exponential moving average of the training iterates, rather than the final iterate itself. This raises a fundamental question: given that we will return an it...

  • internal implementation failureImplementation failure: EMA pullback AdamW control

    Implementation audit requested repair: Scientific control 4 is not enforced by the supplied activation/control boundary. The parsed off/control overrides set `optimizer.init_args.adam.use_ema_eval=false` and `pace_enabled=false`, while t...

8 earlier records are available in the full idea history.

Research question certificate

RQC v26

RQC v26 current
StatusCurrent and approved
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

Run the canonical eight-GPU Titan MoE local falsifier at approximately 1B total and 100M active parameters for exactly 3000 steps, 100 warmup steps, and 900 cooldown steps. Candidate enables PACE on AdamW-compatible groups with preregistered EMA and pullback settings. Control uses identical AdamW updates, identical EMA evaluation, and lambda_pullback=0.0. Falsify if composite_v2 or held-out loss does not improve beyond calibrated paired-seed baseline variance, or if the gain disappears after accounting for throughput and memory overhead.

Mechanism and tension

Changing AdamW training to add PACE's clipped per-coordinate pullback from live weights toward the EMA iterate should improve held-out decoder pretraining composite_v2 under matched tokens because the optimizer directly trains the returned EMA model while retaining Adam second-moment preconditioning. Tension: AdamW equivalence may break at lambda_pullback=0 because of operation ordering or EMA state handling.; EMA eval swap could corrupt live weights or checkpoints if train/eval transitions are not exact.; Additional EMA buffers may increase memory enough to alter batch size, sharding, or throughput.; Pullback gain based on Adam second moments may behave poorly with sparse MoE parameter groups.; Hyperparameter tuning could overfit the local falsifier if not preregistered.; Distributed resume could restore EMA counters or buffers incorrectly.

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Changing AdamW training to add PACE's clipped per-coordinate pullback from live weights toward the EMA iterate should improve held-out decoder pretraining loss under matched tokens because the returned averaged model is explicitly optimized to stay closer to the low-oscillation iterate-average estimator while retaining AdamW preconditioning.",
  "idea_id": "idea_1b09901ac1144189"
}
matched control
{
  "change": "Use the same Titan model, tokenizer, data order, batch, schedule, warmup, cooldown, weight decay, gradient clipping, and seed for candidate and control.; Primary matched control must be EMA-evaluated AdamW with lambda_pullback=0.0 and the same EMA schedule/update frequency as PACE.; Match exactly 3000 optimizer steps and report matched-token composite_v2 plus measured active FLOPs, memory, and throughput.; Use the same seed and data order for the first paired run; repeat on calibrated local seeds if the delta is inside baseline variance.; Pre-register PACE hyperparameters or a tiny fixed grid before launch, with the same tuning budget for candidate and control.",
  "idea_id": "idea_1b09901ac1144189"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
  "idea_id": "idea_1b09901ac1144189",
  "implementation_material_sha256": "0c29fd7e2c53a66b6d114d3f4e40a0c022eb15270f678b6e3ddf34707fe0061b",
  "metric_identities": [
    {
      "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_0772572733fd46d8",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Exact baseline match: Titan AdamW or current optimizer baseline with the same architecture, data order, tokenizer, batch, schedule, warmup, cooldown, weight decay, gradient clipping, and EMA evaluation policy.
  2. Token match: 3000 optimizer updates for both candidate and control in the local 1B-total/100M-active MoE falsifier; report measured active FLOPs and throughput as interpretation.
  3. Seed policy: use the same seed and data order as the matched control; repeat on calibrated local seeds if the delta is within baseline noise.
  4. Intervention-specific confound: PACE must be compared against an EMA-evaluated baseline using the same EMA power and update frequency so the only optimizer change is the clipped per-coordinate pullback.
  5. Hyperparameter control: preregister a small c and kappa sweep or use the source-selected values if recoverable; do not tune candidate against a single fixed baseline.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_3207ed0deb8f4d14
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
f2ef1d9305f01f6fadbba737fa9db0a1202cfd05
Branch
auto-research/idea_1b09901ac1144189/probe-dp4-candidate_b855920271e261d42c4b
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_b855920271e261d42c4b
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_b855920271e261d42c4b.local.yaml
Config SHA-256 (recorded, unverified)
f4131a6965931ae2cf3e2f0a57e5f40453b294b9200e92f860f870501c0c82d9
Actual config SHA-256
f4131a6965931ae2cf3e2f0a57e5f40453b294b9200e92f860f870501c0c82d9
Resolved config SHA-256 (recorded, unverified)
7f3349b1c146df658d2b9461df1b60b5daaefed073b6ad8ba7f5b32970bc319b
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_b855920271e261d42c4b.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

Schedule-free averaged Muon

P0Score 0.62local rejectedRQC v26 currentSmoke passed

Changing the pretraining optimizer from scheduled AdamW or Muon to AMUSE, which combines Muon matrix updates with schedule-free iterate averaging and a time-varying gradient-evaluation interpolation, should improve held-out base-model lo...

Evidence

AMUSE modifies Muon optimization by evaluating gradients at an interpolation between the fast Muon sequence and an averaged sequence, with a time-varying beta_t that starts closer to the fast trajectory and gradually shifts toward the st...

Recovery completed (not a scientific result)Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.615464
100.0%300 / 300 (100.0%)Training loss 3.945 at step 300W&B poolside/Autoresearch
Directional gate

Global loss gate did not pass: candidate 3.944723 vs control 3.329259 (delta +0.615464). No 3000-step pair was launched.

View details
Idea details

Schedule-free averaged Muon

Lifecyclelocal rejected
PriorityP0
Score0.62
Decision now

This idea is in local rejected. The current gate and any live recovery appear below.

Experiment

Recovery completed (not a scientific result)

100.0%300 / 300 (100.0%)Training loss 3.945 at step 300
Matched baseline

probe-dp4-control_9e8df2c9870c4411decd

Experiment conclusion

Matched 300-step healthy-DP4 screen did not improve training loss: delta=+0.615464

Directional gate

Global loss gate did not pass: candidate 3.944723 vs control 3.329259 (delta +0.615464). No 3000-step pair was launched. The 300-step recovery remains health-only; runtime and scientific evidence are excluded.

Test history

The current implementation passed its distributed smoke.

Evidence, sources, and controls
Hypothesis

Changing the pretraining optimizer from scheduled AdamW or Muon to AMUSE, which combines Muon matrix updates with schedule-free iterate averaging and a time-varying gradient-evaluation interpolation, should improve held-out base-model loss at matched pretraining tokens and optimizer steps because early gradients are evaluated near the fast Muon trajectory while later training shifts toward the averaged sequence to suppress high-curvature oscillations.

Evidence

AMUSE modifies Muon optimization by evaluating gradients at an interpolation between the fast Muon sequence and an averaged sequence, with a time-varying beta_t that starts closer to the fast trajectory and gradually shifts toward the stable average. The supplied record reports decoder-only Llama-style pretraining on FineWeb-100B at 124M, 720M, and 1B parameters, with tied embeddings, SwiGLU, RMSNorm, RoPE, sequence length 512, GPT-2 tokenizer, and bfloat16 training. AMUSE fixes Muon momentum at 0.95, uses AdamW-style handling for non-Muon parameters with beta_2 fixed to 0.999, and sweeps beta_1 in {0.4, 0.6} and rho in {0.6, 0.8}. The claimed mechanism is that Muon accelerates low-curvature bulk progress but can amplify dominant-direction oscillations, while schedule-free averaging stabilizes late training without requiring an explicit LR decay schedule.

Current evidence
  • internal repository analysisTitan repository analysis: Schedule-free averaged Muon

    AMUSE is locally implementable as a Muon-family optimizer change, not a model wrapper. The current Titan tree already has the Muon distributed matrix update, parameter grouping, checkpoint state plumbing, and MoE/MTP parallel paths neede...

  • github repositorykjeiun/amuse

    AMUSE optimizer implementation <h1 align="center">AMUSE</h1> <p align="center"> <strong>AMUSE: Anytime Muon with Stable Gradient Evaluation</strong> </p> <p align="center"> Jueun Kim* ? Baekrok Shin* ? Jihun Yun ? Beomhan Baek ? M...

  • arxivAMUSE: Anytime Muon with Stable Gradient Evaluation

    Modern deep learning commonly relies on AdamW with prescribed learning rate schedules, but recent works challenge both components: Schedule-Free optimization removes explicit schedules via iterate averaging, and Muon improves the update ...

  • internal implementation failureImplementation failure: Schedule-free averaged Muon

    Implementation audit requested repair: Trusted host verification did not pass: `host_verification.verified` is false because `touched_tests` has 6 new failures in `tests/titan/test_amuse.py::test_lr_scheduler_load_recovery_applies_lr_for...

17 earlier records are available in the full idea history.

Research question certificate

RQC v26

RQC v26 current
StatusCurrent and approved
Maximum runs2
Maximum tokens57791677440
Falsifiable hypothesis

On the standard eight-GPU Titan 1B-total, 100M-active MoE, train AMUSE for exactly 3,000 steps with 100 warmup steps and 900 cooldown-equivalent horizon handling, same data order, tokenizer, batch, model, and seed as the baseline. Reject if held-out loss or composite_v2 fails to improve beyond measured baseline variance, or if measured optimizer overhead removes the gain under equal-FLOP interpretation. Run focused tests for beta_t schedule, Z/X/Y transitions, averaged validation weights, checkpoint resume, distributed Muon-family grouping, and non-Muon parameter handling before launch.

Mechanism and tension

Changing Titan pretraining from the existing scheduled Muon/AdamW-family baseline to AMUSE should lower held-out base-model loss at matched tokens and optimizer steps because gradients are evaluated at a time-varying interpolation between a fast Muon trajectory and an averaged trajectory, preserving early Muon progress while reducing late high-curvature oscillations. Tension: Existing Muon parameter grouping could regress if AMUSE is registered incorrectly.; Validation may silently use fast weights instead of averaged weights.; Checkpoint resume could restore inconsistent Z/X/Y optimizer state.; MoE router or expert parameters may be assigned to the wrong optimizer path.; Additional state may cause 17B memory regressions or hidden collectives.; Schedule-free semantics may interact poorly with existing LR scheduler loading.

Exact preregistered test and update rule

Preregistered controls

intervention
{
  "change": "Changing the pretraining optimizer from scheduled AdamW or Muon to AMUSE, which combines Muon matrix updates with schedule-free iterate averaging and a time-varying gradient-evaluation interpolation, should improve held-out base-model loss at matched pretraining tokens and optimizer steps because early gradients are evaluated near the fast Muon trajectory while later training shifts toward the averaged sequence to suppress high-curvature oscillations.",
  "idea_id": "idea_d01bc6b550634654"
}
matched control
{
  "change": "Exact baseline match against current Titan scheduled Muon or AdamW-family baseline with same model, data, tokenizer, sequence length, batch size, weight decay, and loss.; Match pretraining tokens and optimizer steps for the primary comparison; report measured optimizer overhead for equal-FLOP interpretation.; Use same seed and data order when practical; compare against measured composite_v2 baseline variance.; Keep Muon matrix eligibility fixed between control and candidate except for AMUSE Z/X/Y averaging and beta_t interpolation.; Pre-register beta_init=0.6 and rho=0.8 for the first local test unless a reviewed grid is explicitly budgeted.; Use averaged weights consistently for validation and checkpoint-resume semantics.",
  "idea_id": "idea_d01bc6b550634654"
}
minimal decisive test
{
  "artifact_node_ids": [],
  "evaluator_protocol_hash": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
  "idea_id": "idea_d01bc6b550634654",
  "implementation_material_sha256": "b053633e85b7ed15509ca360dc827f1247cd2e0c5c1270c9b3002331c57dd037",
  "metric_identities": [
    {
      "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
      "name": "scientific_review",
      "split": "implementation"
    }
  ],
  "scientific_review_id": "review_5fc9403fe1c64d79",
  "stage": "implementation"
}
metrics
{
  "scientific_review": {
    "evaluator_version": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93",
    "name": "scientific_review",
    "split": "implementation"
  }
}
stopping rule
{
  "cooldown_steps": 900,
  "steps": 3000,
  "warmup_steps": 100
}
compute cap
{
  "allowed_tiers": [
    "smoke",
    "local"
  ],
  "evaluation_allowance": {
    "max_gpu_seconds": 0,
    "max_runs": 0,
    "max_tokens": 0
  },
  "max_gpu_seconds": 57600,
  "max_runs": 2,
  "max_steps_per_run": 3000,
  "max_tokens": 57791677440
}
evaluator versions
{
  "scientific_review": "8a53613829e26da5100822a815730ec77047b7171954ecbeda414660e269be93"
}
required update after failure
Return the idea to scientific review when implementation or its preregistered falsifier fails.
Required controls
  1. Match the current Titan baseline optimizer, LR schedule, warmup, weight decay, batch size, data order, tokenizer, sequence length, and model shape except for the optimizer update rule.
  2. Compare at equal pretraining tokens and optimizer steps; also report equal-training-FLOP interpretation including any added Newton-Schulz, averaging, or optimizer-state overhead.
  3. Use the same seed as baseline when practical; if local variance is not calibrated, run at least the canonical baseline seed plus one repeat or judge against measured baseline variance.
  4. Keep Muon application scope fixed: matrix-valued hidden parameters use orthogonalized momentum updates, while embeddings, norms, biases, and other non-matrix parameters use the specified non-Muon optimizer path.
  5. Tune AMUSE only over the declared minimal grid for initial interpolation beta_1 and rho, or pre-register one setting, to avoid optimizer-specific tuning-budget confounds.
  6. Disable explicit LR decay for AMUSE as part of the intervention, while preserving baseline schedule for the matched baseline.
Reproduction and full run evidence
Reproduce / inspect code

Inspect the recorded revision and configuration evidence. The command below is provenance, not an automatic relaunch.

Implementation action
action_982519ded7ca403c
Base commit
14048b8a98717d7037a6733b093ababc8560dc8f
Candidate commit
a5a776894322e210c0235bb9ec66a9782d5f381e
Branch
auto-research/idea_d01bc6b550634654/probe-dp4-candidate_96c4b1703a57d16801dc
Preserved worktree
/persistent/.local/state/george-auto-research/worktrees/probe-dp4-candidate_96c4b1703a57d16801dc
Configuration
/persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_96c4b1703a57d16801dc.local.yaml
Config SHA-256 (recorded, unverified)
92725958c8af665fb0f645e7fab2db9d7afde685db4d31e2903ea0fad3e02c1d
Actual config SHA-256
92725958c8af665fb0f645e7fab2db9d7afde685db4d31e2903ea0fad3e02c1d
Resolved config SHA-256 (recorded, unverified)
c8125e45785bd3b86bc96072904e2b3a6161fdc21439e1c645d9b60baf749276
Seed
42
Recorded launch command
titan-pretrain --config /persistent/.local/state/george-auto-research/run_configs/probe-dp4-candidate_96c4b1703a57d16801dc.local.yaml
Full terminal evidence

Loading exact configuration, logs, checkpoints, failure, and recovery evidence.

4B

Qualification through scale result

1
Baseline gate

Canonical 4B baseline calibration

Processing resultsSeeds 42, 43, 443 baseline runs complete0 qualified 4B candidate launches
Current

All exact seed controls finished and their metrics are being validated.

Next: Promotion remains gated until the calibrated variance is registered.
Open calibration details
4B workflow

Canonical 4B baseline calibration

StatusProcessing results
Seeds needed42, 43, 44
Slots reserved0
Current gate

All exact seed controls finished and their metrics are being validated. Promotion remains gated until the calibrated variance is registered.

4B launch scope

3 completed 4B baseline calibration runs (seeds 42, 43, 44); 0 qualified 4B candidate launches.

Historical reconstruction

0 exact prior runs accepted; 0 non-matching runs rejected. The detailed reasons remain in the audit log.

Prepared controls
  • 4b-baseline-calibration-seed42-v2 - seed 42
  • 4b-baseline-calibration-seed43-v2 - seed 43
  • 4b-baseline-calibration-seed44-v2 - seed 44
Evaluator protocol

1360574bf153a05ac035e340ac2086e8b08bce9b7dc675d2376b1863324d08e2

17B / PR

Manual scale validation and handoff

0

No cards here.

Read-only snapshot generated Jul 28, 17:43 UTC. Refreshes are published by the private research runtime.