Sequential, Functional & Subclassing

## What Sequential actually is `keras.Sequential` is a thin convenience wrapper over the same machinery the Functional API uses. You hand it an ordered list of layers, and it wires layer *n*'s single output into layer *n+1*'s single input. That contract is the whole story: **one input tensor, one output tensor, no branching**. If you pass `keras.Input(shape=...)` as the first element, Keras knows the input shape immediately and builds every layer's weights at construction time; without it, the stack stays unbuilt until the first batch or an explicit `model.build()`. Sequential is the right tool more often than people admit — a convolutional stack ending in a classifier head, an MLP, a preprocessing chain. It reads well and it is hard to get wrong. ## What the Functional API adds The Functional API is a small symbolic language. `keras.Input(shape=(32,))` does not allocate data; it returns a `KerasTensor`, a placeholder that carries a shape and a dtype but no values. Calling a layer on a `KerasTensor` returns another `KerasTensor` and records a node in a graph: *this layer was applied to that tensor*. When you finally write `keras.Model(inputs=..., outputs=...)`, Keras walks backwards from the outputs to the inputs and freezes that graph as the model's topology. Because the graph is data, not control flow, four things become possible that Sequential cannot express: 1. **Multiple inputs.** An image tower and a tabular tower merged before the head. `keras.Model(inputs=[image, meta], outputs=...)`. 2. **Multiple outputs.** One trunk, two heads — say a regression output and a classification output — returned as a list or dict. 3. **Non-linear topology.** Residual/skip connections (`keras.layers.Add()([x, shortcut])`), inception-style parallel branches, U-Net style concatenations from encoder to decoder. 4. **Shared layers.** Call the *same* layer instance on two different tensors and both calls use the same weights — the standard way to build siamese/twin-tower models. ## Why the explicit graph is worth having Because the topology is known before any data flows, Keras can propagate shapes through it. That buys you concrete, immediate benefits: - `model.summary()` prints each layer's real output shape and parameter count. - Shape mismatches raise while you are typing the architecture, not on the first training batch. - `keras.utils.plot_model(model)` can draw the graph. - `model.get_layer("name").output` gives you a handle on any intermediate tensor, so you can build a feature extractor or splice a new head onto an existing trunk without touching the original code. - The topology is plain configuration, so it round-trips through save/load without custom code. ## The failure mode to recognise The usual interview trap is a candidate trying to force a branch into Sequential — for example calling `model.add()` twice hoping for two heads, or trying to add two Sequential models together. Sequential simply has nowhere to put a second output. The second trap is treating a `KerasTensor` like real data inside the Functional build: `if x > 0:` or `x.numpy()` on a symbolic tensor fails, because there is no value yet. Data-dependent control flow is exactly the point where the declarative APIs run out and a subclassed model or a custom layer takes over. ## Choosing in practice A workable rule: start Sequential; move to Functional the first time the architecture stops being a line; keep the novel arithmetic inside a custom layer that the Functional graph then wires up. Converting a Sequential model to Functional is mechanical — you already have the layer list, you just name an input and thread it through — so starting with Sequential costs nothing. One last note on Keras 3: both APIs are backend-agnostic. The same Sequential or Functional model definition runs on the TensorFlow, JAX or PyTorch backend, selected by the `KERAS_BACKEND` environment variable, because the layer graph is Keras's own representation and not a backend graph.