An expanded schema can describe all the right fields and still lose information. In a Kubernetes report, I was trying to recognize standard Kubernetes types wherever they appeared inside custom resources.
A reference to ObjectMeta gave policy code a meaningful target. It could apply the relevant label rules there. A reference to Container could identify where resource requirements or environment transforms belonged. Those uses depended on knowing the named type, not merely recognizing a coincidentally similar collection of properties.
The CRD tooling expanded $ref targets into inline schemas, and the CRD format then in use did not retain the references or arbitrary extension hints. The fields survived. The explicit relationship to their original types did not.
I considered collecting the Go-generated OpenAPI definitions directly, regenerating a combined definition set, or building an API-server view containing the additional types. Each would recover information available earlier in the pipeline by going around the flattened result.
The proposal was to allow a known group/version/kind hint at the expansion site so consumers could restore the relationship when needed. The issue was closed into the broader CRD-reference discussion; the particular hint remained a proposal.
Structural validation may be satisfied by an expanded object. A consumer applying type-specific policy needs the identity that expansion removed. Two schemas can accept the same values while providing different information to tools that act on them.