train-the-named-architecture

# 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 an...