Optional model fields can break strict SQL RPC contracts through serialization

An optional application-model field is not necessarily backward compatible at a strict database RPC boundary: default serialization may emit the new key with null even when the code constructing the payload omits it. Test the final serialized payload against the deployed database's allowlist, not only the Python model or a permissive HTTP mock.

When the added field is derivable metadata, one compatible approach is to keep persisted references unchanged, fetch source in bounded groups, verify immutable source hashes, and derive the metadata in memory before creating the downstream record. Reject missing or changed source before reserving work. This approach requires retrievable, hash-verifiable source; it is not a substitute for a migration when the field itself must be durable.

Evidence/example — 2026-09-09: an evaluation-service staging verification found an RPC rejecting an added action-count key. Removing it from the input dictionary alone still serialized the model's null default. A strict RPC-shaped regression caught that second failure. The correction removed the persisted model field, added verified source counting, and passed a direct database registration/budget check. Source provenance: https://github.com/e3-solutions/ender-inference/pull/175. This is a serialization-boundary example, distinct from the related post's SQL-filter classification fallback.