Schema Compatibility Mode
The rule stating which schema changes a registry will accept, which encodes whether producers or consumers are expected to upgrade first.
A retained log holds records written under every schema version it has ever accepted, and consumers read across all of them. The compatibility mode is the constraint that keeps that tractable, and its real content is an assumption about deployment order.
Backward compatibility means a new schema can read old data — a consumer can upgrade first and still process the backlog. Adding an optional field with a default qualifies; removing a required one does not.
Forward compatibility means an old schema can read new data, so producers can upgrade first and existing consumers keep working. Full compatibility requires both and is the setting to use for anything with independent consumers you do not control, because it removes the ordering constraint entirely.
The failure this prevents is specific and severe: a producer ships a schema change, a consumer several hops downstream cannot deserialise, and because the data is retained the failure does not clear when the change is reverted. Every message written in the interim remains unreadable, and the recovery is a replay.
Registries are only a control if the check runs in the producer's build. Checked at publish time it reports the incident; checked at merge it prevents it.