---
name: tangxiangru/train-the-named-architecture
source: https://app.decimal.ai/s/tangxiangru-train-the-named-architecture@1/SKILL.md
source_sha256: ca4e97a2ab65
---

# When the brief names an architecture, the model is a deliverable, not a line in the cut order

The reasoning that loses this is good reasoning. Building the named architecture
from scratch is expensive; a cheaper model class will reach a better number on the
supplied data; a released checkpoint will reach the published number exactly. All
three are true, and all three lose, because a brief that names an architecture is
graded on the architecture: its components, its training dynamics, its ablations.
Those questions have no answer that a different model can give.

So: **if the budget will not carry everything, cut seeds, cut substrates, cut your
own extension. Never cut the model the brief names.**

## A scale model beats a correct number from something else

The trade that looks obvious — "a from-scratch version at this budget would be far
worse than the published one, so it cannot win" — is a prediction, and it is
usually wrong about what is being graded. A small, honest re-implementation that
keeps the named components and trains for a fraction of the source's budget
answers every architecture-shaped criterion. A number obtained from something else
answers none of them, however good the number is.

Budget one small training arm before you budget a second inference sweep.

## Do both, when a release exists

A released checkpoint and a small re-implementation answer different questions,
and a task that names an architecture usually asks both:

| the criterion says | what answers it |
|---|---|
| accuracy, success rate, benchmark score | the released code, run as published |
| architecture, components, convergence, ablation, training | your own trained re-implementation, at whatever scale you can afford |

This is the one place to override the usual advice to install and run the
authors' release rather than reimplement it. Run the release *and* build the
scale model; they are not alternatives here.

## Take the ablation list from the nouns in the brief's architecture sentence

If the brief says "a graph encoder with gated convolutions, a self-supervised
decoder and a classifier head", the ablations are: remove the gating, remove the
decoder, replace the head. Removing an *input* — a feature, a modality, a
conditioning signal — is a different experiment, and it does not answer a
component question. Match each ablation against a parameter-matched control so the
delta is about the component and not about capacity.

## Persist the training log from the first loop

Inside the training loop, before anything else changes, append
`(step, train_loss, val_loss, val_metric)` to a result file — for **every** arm,
including the subordinate ones you do not expect to report. A convergence curve is
one of the most frequently graded artifacts of a model-building task and one of
the easiest to lose: the numbers exist in memory for the length of the run and
then do not exist at all. There is nothing to recover at writing time.

Then, before the analysis stage: grep your own figure captions for an epoch axis.
If the brief named an architecture and no figure has one, go back to
experimentation rather than forward to writing.

## Write the spec at the level the brief does

A criterion about architecture is a paragraph about layers, and it is answered by
a paragraph about layers, **in the report body**: layer count, width, pooling,
dropout, optimiser, learning rate, batch size, epoch count. "A graph network
pre-trained with masked reconstruction" is a description of a category. A config
file in `code/` is not in the report.

## Degenerate input data does not excuse skipping the run

You will sometimes prove the supplied file is trivial — a closed-form function of
its own index, a leak, a surrogate. Audit it, in its own section. Then train the
named model on it anyway and report what happened, because the architecture
criteria are still there and they are still graded. Switching to a model class the
brief did not name, on the grounds that the data does not deserve the named one,
scores worse than training the named one on bad data.

## State the budget and keep the comparison

"This is a statement about a 3,400-step budget, not about the architecture in the
limit" costs nothing and protects everything. An honest scale disclaimer next to a
real comparison is worth far more than a missing arm.

See also `run-the-conditions-the-source-ran` for the experiment list this model
has to be run through, and `publish-what-the-run-already-computed` for the sweep
that catches a training log you kept and did not plot. On a materials run,
`material-as-specified-run-and-stage-diagnostics` covers the "run the named method
family" and "leave the stage diagnostics behind you" halves of this from the field
side; what is here and not there is the trade against a released checkpoint, the
component-versus-input ablation distinction, and what to do when the supplied data
turns out to be degenerate.