A transposed input batch trains without raising a shape error - how do you detect it?

## Why a transpose can be legal A fully-connected layer validates one thing: the trailing extent of its input must equal its stored input width. Everything to the left is treated as batch and ignored. That is what makes the layer usable at any batch size - and it is exactly what lets a wrongly oriented tensor through. Take a window of intensive-care vital signs: 60 timesteps of 20 channels per patient, flattened to 1200 features, batched 60 at a time. The intended input is `(60, 1200)`. A loader bug hands over `(1200, 60)` instead, or a stack along the wrong axis produces `(60, batch)` where `(batch, 1200)` was meant. If the first layer's input width happens to match the trailing extent that arrives - and with a symmetric-looking number like 60 appearing as both a batch size and a timestep count, coincidences are common - the product is defined, the loss is finite, and the run proceeds. Nothing in the forward pass is in a position to object. ## What the model is actually computing Under a transposed input, a "row" is no longer an example: it is one feature across many patients. The layer therefore mixes patients inside a single output row. Gradients still flow, the loss still decreases a little - a mangled input is not the same as a random one - and the model may reach a mediocre accuracy that looks like an architecture or capacity problem. This is why the bug survives so long: it presents as underfitting, not as a crash. ## Check one: vary the batch size The batch axis is defined by the fact that it is the axis you control. Request a batch of 32 and then a batch of 33 and print the input's shape at the model boundary. In a correct pipeline dimension 0 goes from 32 to 33 and dimension 1 stays at 1200. If dimension 1 moves and dimension 0 is pinned, the axes are swapped, and you have your answer in two runs of a few seconds each. Use a prime-ish, non-square batch size for this: a batch of 60 against 60 timesteps is precisely the case where nothing distinguishes the axes. ## Check two: the independence probe This is the definitive test and it does not require knowing the intended shapes at all. In any feed-forward stack without normalisation across the batch, each example is transformed independently: output row `i` is a function of input row `i` alone. So perturb a single row of the input - add a small constant to it - and compare outputs before and after. Exactly one output row should change. If many change, the rows are not examples. Run the model in evaluation mode for this, so that dropout is not resampling and confusing the comparison. A close relative is the permutation probe: shuffle the rows of a batch and confirm the per-example outputs are the same values in the shuffled order. Correct layouts satisfy this exactly. ## What does not work Counting elements is useless - a transpose preserves the element count exactly, so a check like `size == examples * features` passes either way. Comparing the parameter count is equally blind, since parameters never see the input layout. Verifying that the tensor is two-dimensional, or that the loss is finite, or that the loss is falling, tells you nothing about orientation. ## Making it stick Once diagnosed, the fix is not just the transpose. Add an assertion at the model's input boundary that names both axes: dimension 0 equals the batch size the loader was asked for, dimension 1 equals the feature width the first layer expects. Assert it once per forward pass in development; the cost is negligible next to a matrix product. Where the stack supports naming axes, name them, so an accidental swap is a type error rather than a coincidence of integers. The general principle for shape work is that conformable is not the same as correct: the arithmetic only checks that the numbers line up, and only an explicit statement of intent checks that they mean what you think.