Keep domain knowledge explicit
The core cannot enumerate every industrial object, product component or rendering technique. Entity and component kinds are extensible vocabularies. An organization-specific kind such as x-acme.instrument-panel identifies a concept without pretending it is a standard kind.
Use the extensions container for extension payloads. Extension documentation should define its namespace, version, schema, required capabilities, processing rules, security considerations and fallback behavior. Reserve the standard vocabulary for meanings defined by this specification.
Optional does not mean silently lossy
A consumer may preserve an unknown optional extension without interpreting it. It must report an unsupported required extension or capability before claiming conforming output. Authors should provide a meaningful fallback where reduced fidelity is acceptable, and say which aspects that fallback changes.
An extension must not redefine the meaning of an existing field. It should reference existing IDs instead of copying an entire entity or component merely to attach metadata.
Design an extension for exchange
- Write down the concrete visual requirement that the core cannot represent.
- Define its data model and make units and defaults explicit.
- Provide a small valid example and examples of invalid input.
- Describe how a consumer detects support and behaves without it.
- Test a round trip through a consumer that does not interpret the extension.
- Propose an RFC if the requirement is broadly useful across implementations.
New profile proposals follow the same process. A custom profile is a documented specialization of the core, not permission to bypass its identity, reference or accessibility requirements.