Registry-based configuration eligibility

Context

Custom-field support brings presentation and query obligations. The approved classification makes that support an explicit decision for each record category.

Decision

Record configuration follows registered custom-field and presentation capability flags, subject to the approved classification and compatibility transition; custom objects provide all three inherently.

Alternatives Considered

Separate eligibility lists in each consumer: Independent lists can diverge from the registered answer required by the standard. Allowing fields on every category: The approved classification deliberately limits configurable complexity. Inheriting capabilities through relationships: Being linked to a configurable category does not grant that category’s capabilities.

Consequences

Creation, descriptions, query models and presentation validation consume effective capability eligibility. The module’s configuration objects do not opt into extra custom fields; custom records consist of properties governed by the field machinery. Approved undeclared types receive compatibility defaults and a warning. The current Fields chooser still maintains a narrower client list.