---
id: ADR-PFM-MTD-002
title: Registry-based configuration eligibility
product_area: platform
module: metadata
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
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.
constrains:
- DOM-PFM-MTD-001
- DOM-PFM-MTD-002
- DOM-PFM-MTD-003
- DOM-PFM-MTD-004
- DOM-PFM-MTD-005
- DOM-PFM-MTD-006
- SVC-PFM-MTD-metadata
- SVC-PFM-MTD-layouts
origin: R2-ARCH-001 v1.0, Custom Fields Are Opt-In Per Entity (Andrew, 2026-10-19, decisions D1 to D4; services-
  platform:docs/standards/custom-field-capability.md); PLAT-M9 Product Accepted 2026-10-19
alternatives:
- option: Separate eligibility lists in each consumer
  why_not: Independent lists can diverge from the registered answer required by the standard.
- option: Allowing fields on every category
  why_not: The approved classification deliberately limits configurable complexity.
- option: Inheriting capabilities through relationships
  why_not: "Being linked to a configurable category does not grant that category\u2019s capabilities."
consequences:
- Creation, descriptions, query models and presentation validation consume effective capability eligibility.
- "The module\u2019s 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.
supersedes: []
evidence:
- 'services-platform at ad3f6a65: modules/metadata/capabilities/approved-custom-field-objects.ts, effective-capabilities.ts;
  modules/layouts/services/persistence/layout-resources.ts; docs/standards/custom-field-capability.md'
---

# 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.