The question
Unmodeled keys are namespaced strings written by a compiler — openapi:required, openapi:content, openapi:links, openapi:schema — and nothing states whether they are stable.
Two facts make this worth settling:
- The map itself has already been renamed.
ir/document.go:19-21 records the rename from preserved to unmodeled at IRVersion 0.3.0.
no_ir_home entries are explicitly expected to move. ir/unmodeled.go:96-99 calls that reason "a gap expected to close, not a boundary" — so a consumer reading such a key is depending on something the IR intends to delete.
Today a consumer has no choice about it: request-body optionality (see the Payload.Required issue) is available only through Unmodeled["openapi:required"], read by absence. So the IR simultaneously requires consumers to read these keys and gives them no stability promise about them.
What would settle it
A short statement in ir-design.md, of roughly the form:
- keys under a
vendor_extension or out_of_scope reason are as stable as the source construct;
- keys under
no_ir_home are explicitly unstable and may disappear when the gap closes;
- and a consumer that must read one has a versioned way to know which it is.
Raised because a prospective consumer is about to depend on these keys, not to propose a specific policy.
Found by a study of dexpace/spaceapi adopting morphic IR as its input format (spaceapi#56), 2026-09-05. Related: #418 (non-emitter consumer), #419 (cross-revision identity).
The question
Unmodeledkeys are namespaced strings written by a compiler —openapi:required,openapi:content,openapi:links,openapi:schema— and nothing states whether they are stable.Two facts make this worth settling:
ir/document.go:19-21records the rename frompreservedtounmodeledat IRVersion 0.3.0.no_ir_homeentries are explicitly expected to move.ir/unmodeled.go:96-99calls that reason "a gap expected to close, not a boundary" — so a consumer reading such a key is depending on something the IR intends to delete.Today a consumer has no choice about it: request-body optionality (see the
Payload.Requiredissue) is available only throughUnmodeled["openapi:required"], read by absence. So the IR simultaneously requires consumers to read these keys and gives them no stability promise about them.What would settle it
A short statement in
ir-design.md, of roughly the form:vendor_extensionorout_of_scopereason are as stable as the source construct;no_ir_homeare explicitly unstable and may disappear when the gap closes;Raised because a prospective consumer is about to depend on these keys, not to propose a specific policy.
Found by a study of
dexpace/spaceapiadopting morphic IR as its input format (spaceapi#56), 2026-09-05. Related: #418 (non-emitter consumer), #419 (cross-revision identity).