--- yip: title: status: Draft type: Schema | Meta | Informational author: created: supersedes: --- # YIP-XXXX: ## Motivation What problem does this solve? If these types were proven in a specific application before graduating to the global schema, say which, and what made them general enough to share. ## Specification The exact schema change. For new or revised types, list each type with: - **name / label / kind** (`abstract` | `concrete`), parent (`inherits_from`) - **new or changed fields**, with types and whether required - **what was generalized out** — any application-specific assumption removed so the type is reusable (e.g. a site's classification ladder → a generic optional field; a country-specific id → a generic `registry_id` + `registry_scheme`) ## Version impact State for each affected type whether this is: - a **new type** (starts at `1.0.0`), or - a **widening** change to an existing type (minor bump, backward compatible), or - a **breaking** change (new major version; old permalink stays immutable). State the resulting `ytypes/index.json` `version`. ## Backward compatibility Confirm the change is widening-only within its major version, or explain the break and the migration path. An accepted YIP must not invalidate a yObj that was valid under a prior same-major version. ## Files The concrete files added/changed (see YIP-0000 and CONTRIBUTING.md): ``` ytypes/<name>/<version>/<name>.ytype ytypes/<name>/latest.ytype # identical copy ytypes/index.json # entry added, version bumped ``` ## Validation Confirm: every `.ytype` validates against the meta-schema, each `schema` section is a runnable JSON Schema (Draft 2020-12 `check_schema`), and each concrete type ships a demo yObj that validates against it.