Which Keras model API should a team standardize on across a shared codebase?

## Why this is a policy question, not a preference All three Keras model APIs train identically and reach identical accuracy. The differences are entirely about what happens to a model *after* it is written: who reads it, who exports it, who reuses half of it, and who is on call when it fails to load. That makes API choice an engineering-standards question with a real cost curve, which is why it is asked as a judgment question rather than a knowledge one. ## The axes that actually decide it **Who consumes the model.** A model that stays inside one notebook has no downstream consumers, and its author should use whatever is fastest to write. A model that is exported, served, versioned, or handed to another team acquires consumers who need to understand and manipulate it without reading its source. Declarative topologies serve those consumers; imperative ones require the code. **Reconstructability.** A Functional model's architecture is configuration. A subclassed model's architecture is a Python class that must be importable, at the right version, wherever the model is loaded. That is a real dependency between a stored artifact and a code repository, and it is the single most common cause of a model that cannot be reloaded a year later. **Reviewability.** A diff of a Functional model shows the graph changing. A diff of a subclassed `call()` shows control flow changing, and reviewers must simulate it mentally. For a team where models are reviewed like any other code, the declarative form is materially cheaper to review. **Tooling and instrumentation.** Feature extraction, transfer learning, activation debugging, perceptual losses and layer freezing all lean on addressing a named layer in a recorded graph. If any of these are part of the team's routine, giving them up across the codebase is a large recurring cost paid to save a small one-time cost. **Research velocity.** Against all of that: if the forward pass genuinely changes shape every week, forcing it through a declarative graph produces contorted code and slows the work the team exists to do. **Backend portability (Keras 3 specific).** Keras 3 runs on TensorFlow, JAX and PyTorch, selected by `KERAS_BACKEND`. Models built only from Keras layers are portable for free. Custom `call()` code is portable only if it stays within `keras.ops`. Without a stated rule, a team that believes it is multi-backend can discover late that half its custom layers are not. ## A policy that holds up 1. **Sequential** — baselines, ablations, preprocessing stacks. Cheap, obvious, no ceremony. Not a target for production models, because the first architectural change breaks it. 2. **Functional** — the default for anything shared. Every model that is exported, served or reused is assembled here. Every layer that anyone might want to address later gets an explicit `name`, because auto-generated names are not stable across refactors. 3. **Layer subclassing** — the sanctioned extension point. Novel computation goes into a `keras.layers.Layer` that a Functional graph then wires up. This captures nearly all of the expressiveness people reach for when they subclass a whole model. 4. **Model subclassing** — allowed, but by exception and with obligations: the forward pass must be genuinely value-dependent, the class must implement `get_config`/`from_config` so it round-trips, and it must be explicitly built (or smoke-tested with a dummy batch) so shape errors surface at import rather than mid-run. 5. **Custom numerics through `keras.ops`** — unless the team has consciously decided it is single-backend forever, in which case write that decision down rather than leaving it implicit. ## How to introduce it Do not retro-convert working models; the accuracy is identical, so the change buys nothing on its own and risks regressions. Apply the policy at the boundary instead: any model that becomes a shared dependency, gets exported, or acquires a second consumer is assembled functionally when it next changes. Existing research models keep their form until they graduate. ## The honest counter-argument A policy that is fought stops being a policy. If the team is overwhelmingly research-facing and models rarely leave, mandating Functional assembly is friction that buys tooling nobody uses. The defensible version of the decision is always conditional: name the consumers, name the operations the team performs on models, and let the standard follow from those. A principal who states the criteria and their weighting has answered the question; one who simply names a favourite API has not.