@@ -307,7 +307,7 @@ Reference to a record in another object (foreign key).
 
 | Property | Type | Default | Description |
 |:---|:---|:---|:---|
-| `reference` | `string` | **required** | Target object name (snake_case) |
+| `reference` | `string` | **required** | Target object name (snake_case). A stored-metadata table (`sys_metadata`, `sys_metadata_history`) is refused — see [below](#a-relationship-never-targets-a-stored-metadata-table) |
 | `referenceFilters` | `string[]` | — | **Removed** (#2377, ADR-0049) — no longer a recognized field property. `FieldSchema` is a strict object, so an unknown key is **rejected with guidance**, not silently stripped (ADR-0078): the error echoes the offending key and prescribes the replacement. Use structured `lookupFilters` + `dependsOn` instead; see [Relationships](/docs/data-modeling/relationships) |
 | `deleteBehavior` | `'restrict' \| 'cascade' \| 'set_null'` | `'set_null'` | Behavior when referenced record is deleted. On a *required* lookup `set_null` is escalated to `restrict`, since a NOT NULL foreign key cannot be cleared — **whether the `set_null` was defaulted or written out explicitly**. On a `multiple: true` required lookup the escalation is judged per referencing row: only a row the member removal would leave EMPTY is refused. `cascade` and `restrict` are the values honored as written. Where `set_null` does run, a `multiple: true` lookup loses only the deleted **member** — the other members are kept, and a set emptied that way is stored as `[]`, never `null` |
 
@@ -329,7 +329,7 @@ Parent-child relationship (cascading delete by default).
 
 | Property | Type | Default | Description |
 |:---|:---|:---|:---|
-| `reference` | `string` | **required** | Target (master) object name |
+| `reference` | `string` | **required** | Target (master) object name. A stored-metadata table is refused — see [below](#a-relationship-never-targets-a-stored-metadata-table) |
 | `referenceFilters` | `string[]` | — | **Removed** (#2377, ADR-0049) — no longer a recognized field property. `FieldSchema` is a strict object, so an unknown key is **rejected with guidance**, not silently stripped (ADR-0078): the error echoes the offending key and prescribes the replacement. Use structured `lookupFilters` + `dependsOn` instead; see [Relationships](/docs/data-modeling/relationships) |
 | `deleteBehavior` | `'restrict' \| 'cascade'` | `'cascade'` | Behavior when parent is deleted. `restrict` refuses the parent delete while children exist; `cascade` (and omitting the key) deletes the children with the parent. An explicit `set_null` is a **parse-time rejection** on this type (#9689) — a detail row cannot outlive its master; use a `lookup` if children must survive the parent |
 | `inlineEdit` | `boolean \| 'grid' \| 'form'` | — | Edit child records inline on the parent create/edit form (`true` = auto-pick, `'grid'`, or `'form'`) |
@@ -347,6 +347,10 @@ Parent-child relationship (cascading delete by default).
 }
 ```
 
+#### A relationship never targets a stored-metadata table
+
+A `lookup` or `master_detail` whose `reference` is `sys_metadata` or `sys_metadata_history` is refused by `os validate`, `os build` and the object save door alike. Those rows carry serialized metadata bodies, which are served only through the metadata API (`GET /api/v1/meta/:type/:name`), where the body is projected; the engine never hydrates a reference into them, so `$expand` would keep the stored id and never nest the row, and a master-detail child's `parent` root would stay unbound, refusing every write a `parent` rule judges. To point a record at a metadata item, store its type and name in `text` fields and read the item through the metadata API.
+
 ### `tree`
 Self-referential hierarchy (e.g., categories, org chart).
 
 
@@ -1472,10 +1472,23 @@ export const FieldSchema = lazySchema(() => {
    * engine's object registry for a definition that reaches it unparsed, so every
    * reader of the target — the delete walk that honours `deleteBehavior`,
    * `$expand`, the write-time reference check — sees an ordinary self-reference.
+   *
+   * [#24677] A `lookup` / `master_detail` never targets a stored-metadata-body
+   * table (`STORED_METADATA_BODY_OBJECTS`: `sys_metadata`,
+   * `sys_metadata_history`). Its rows are served only through the metadata
+   * protocol's own door, so the engine never hydrates a reference into one
+   * (`$expand` keeps the stored id; a master-detail `parent` root stays
+   * unbound). The refusal is the authoring rules', beside the refusal of a
+   * formula or validation rule reading through such a field
+   * (`@objectstack/lint`'s expression rule), so `os validate`, `os build` and
+   * the object save door refuse it alike.
    */
   reference: z.string().optional().describe(
     'Target object name (snake_case) for lookup/master_detail fields. '
     + 'Required for relationship types. Used by $expand to resolve foreign key IDs into full objects. '
+    + 'Never a stored-metadata table (`sys_metadata`, `sys_metadata_history`): their rows are served only '
+    + 'through the metadata API, so the engine never hydrates a reference into one, and `os validate`, '
+    + '`os build` and the object save door refuse it. '
     + 'On a `tree` field it is optional and, if given, must be the declaring object\'s own name — '
     + 'the object schema refuses any other target, and writes the own name when it is left out.'
   ),