What must a Keras custom layer's get_config return to survive a .keras round trip?

## The contract Saving a layer calls `get_config()`; loading calls `from_config(config)`. The base `from_config` is essentially `cls(**config)`. Everything follows from that: whatever `__init__` needs must be present in the dict, and every value in the dict must be JSON-serializable. ``` def get_config(self): config = super().get_config() config.update({"units": self.units, "factor": self.factor}) return config ``` Starting from `super().get_config()` is not optional politeness. The base Layer config carries `name`, `dtype` and `trainable`. Return only your own keys and those are lost: the reloaded layer gets an auto-generated name, which breaks name-based lookups such as `model.get_layer("my_name")`. ## The silent-wrong-answer Omitting an argument does not raise. A layer built as `Scale(factor=3.0)` whose `get_config` forgets `factor` reloads as `Scale()` with the default `factor=2.0`. Weights load fine, shapes match, predictions are wrong. That is the reason to unit-test the round trip: build the layer with non-default arguments, save, reload, and assert the attributes and outputs match. The opposite failure is loud: put a key in the config that `__init__` does not accept and reconstruction raises a TypeError about an unexpected keyword argument. Loud is better, but both come from the same drift between the constructor signature and the config. ## JSON-serializable, and nested objects The config becomes `config.json`, so values must be numbers, strings, booleans, lists, dicts or None. A NumPy array, a tensor or an arbitrary Python object cannot go in as-is - convert it (for example with `.tolist()`) or reconsider whether that value is a constructor argument at all rather than a weight. Nested Keras objects are the case worth rehearsing. A layer that takes another layer, an initializer or an activation object as an argument should serialize it: ``` def get_config(self): config = super().get_config() config["inner"] = keras.saving.serialize_keras_object(self.inner) return config @classmethod def from_config(cls, config): config["inner"] = keras.saving.deserialize_keras_object(config["inner"]) return cls(**config) ``` Without the `from_config` override, the default `cls(**config)` hands your constructor a plain dict where it expected a layer, and you get a confusing error deep inside the first forward pass instead of at load time. `deserialize_keras_object` also honours the custom-object registry, so a registered nested class resolves without extra arguments. ## Build state Configuration is not the whole story for lazily built layers. A layer that creates weights in `build(input_shape)` needs that shape again to create the same variables before values can be loaded. Keras handles this with a separate build config: `get_build_config()` returns the recorded input shape and `build_from_config(config)` replays it. The defaults are right for the common case; you override them only when your build depends on something the default does not capture. ## Where interviewers push Expect the follow-up: does registering the class fix a bad get_config? No - the two are orthogonal. Registration makes the class findable by name; get_config makes the instance reconstructible with the right arguments. A registered class with an incomplete config loads happily and behaves wrongly, which is the worse of the two bugs precisely because nothing complains.