re: Placement_*/RouteTest_* are Null_Test.tbl, and Enumeration is a self-index

The template object is stage\Null_Test.tbl: its key hashes as
name_hash("stage\" + "Null_Test.tbl"), the file stage-definition-table names as
EnumerateNullFrame. Ten records - 4 Frame_Test_Asteroid_01..04, 3
Placement_00..02, 2 RouteTest_00..01, Enumeration - and the nine carrying a
FrameCount are exactly the "9/9 for Null_Test.tbl" stage-mission-tables already
counted. The corpus knew the file and the count, not the record names. A second
object (the same five plus Enumeration, without the asteroid frames) matched
none of ten candidate names across sixteen prefixes.

Enumeration is a record that indexes its own object. Disc-wide: 7750 IDXD
objects, 360 carry one, and in 360/360 its field names equal exactly that
object's other record names - zero subsets, zero strays. Field/record counts
run from 2 past 25 ((3,3)x36, (9,9)x24, (13,13)x24, (2,2)x24, (25,25)x18,
(16,16)x12), every pair on the diagonal.

Enumeration vs Enumerate is one letter and opposite scope: Enumerate is
archive-naming's route-2 seed, a single-record object whose fields name OTHER
objects; Enumeration names the records of its own object. Written up in
idxd-container, which had left "an object's kind is known only from the caller
that loads it" open.

Sharper version of the previous correction: I credited the stage\ prefix to
archive_naming.py, but stage-mission-tables states it in prose ("The prefix is
stage\ - name_hash is case-insensitive") and its stagetbl.py examples pass
'stage\AIParams_S02.tbl'. Noted in asteroid-fields.md.

All fifteen artefacts byte-identical.

docs/re/structures/asteroid-fields.md

@@ -112,6 +112,12 @@ works here. (`Stage\` scores identically — the hash lower-cases.)
 **Two independent joins, 9/9 agreement**, and both leave the same tenth object
 unreferenced.
 
+⚠️ Sharper still, found a turn later: **[[stage-mission-tables]] already says it
+in words** — "The prefix is `stage\` — `name_hash` is case-insensitive, so its
+case is free" — and its `stagetbl.py` examples pass `'stage\AIParams_S02.tbl'`.
+The answer to my "🔴 does not reproduce by hash" was written in the doc that owns
+the stage tables.
+
 ## ✅ The 8 values are `index, quaternion(x,y,z,w), position(x,y,z)` (2026-08-28)
 
 Measured over every `Frame_*Asteroid*` record on the disc — **384 records,

docs/re/structures/idxd-container.md

@@ -167,3 +167,33 @@ of the four legacy magics), so that path is read-only knowledge, untestable here
   in 16-bit chars and its hash is different ([ixud-localised-text](ixud-localised-text.md)).
 * The type-identification question is now open rather than closed: with no schema
   field, an object's kind is known only from the caller that loads it.
+
+## ✅ `Enumeration` — a record that indexes its own object (2026-08-28)
+
+**360 of the disc's 7 750 IDXD objects carry a record named `Enumeration`.** Its
+fields are all valueless (`(tag, name, "")`), and:
+
+```
+its field names == the object's other record names, EXACTLY   360 / 360
+   a strict subset of them                                      0
+   naming something not in the object                           0
+```
+
+The matching field/record counts run from 2 up past 25 — `(3,3) ×36`, `(9,9) ×24`,
+`(13,13) ×24`, `(2,2) ×24`, `(25,25) ×18`, `(16,16) ×12` — and **every one is on
+the diagonal**. A field list that merely overlapped would not do that at 360/360
+across that range of sizes.
+
+So `Enumeration` is a **table of contents for the object it lives in**. The kind
+question above ("an object's kind is known only from the caller that loads it")
+gets a partial answer for these 360: the object states its own contents.
+
+⚠️ **Do not confuse it with `Enumerate`**, one letter shorter, which
+[[archive-naming]] uses as the route-2 seed: an object whose *single* record is
+named `Enumerate` and whose fields name **other objects** (resolving as
+`name_hash("<name>.tbl")`). Same idea, opposite scope — self-index versus
+declaration table — and the spelling is the only thing that distinguishes them.
+
+[[mission-wave-arrivals]] counted 28 `Enumeration_*` records while filtering
+non-route records out of a speed measurement; what it does not say is what they
+are.

docs/re/structures/stage-mission-tables.md

@@ -140,10 +140,21 @@ puts real timestamps there (`Route_ADN101_p1F`: t = 0, 20, 30). So a parser
 should read the slot as *time*, and not be surprised when a static table
 degenerates it to an index.
 
-❔ **Two record families new to the corpus**: `Placement_00…02` and
-`RouteTest_00…01` share a **six-record template object** — the sixth record is
-named `Enumeration` — and there are two such objects per language pack. Small,
-`_Test`-shaped, and not yet tied to anything that reads them.
+✅ **`Placement_00…02` and `RouteTest_00…01` are the contents of
+`Null_Test.tbl`.** The larger of the two objects holding them hashes as
+**`name_hash("stage\" + "Null_Test.tbl")`**, the file
+[[stage-definition-table]] names as `EnumerateNullFrame`. Its ten records are
+**4 `Frame_Test_Asteroid_01…04` + 3 `Placement_00…02` + 2 `RouteTest_00…01` +
+`Enumeration`** — and the nine with a `FrameCount` are exactly the "9/9 for
+`Null_Test.tbl`" counted above. The corpus knew the file and the count; it did
+not know the record names.
+
+The second object (six records: the same `Placement`/`RouteTest` five plus
+`Enumeration`, without the asteroid frames) did not match any candidate name I
+hashed, so it stays ❔ — a trimmed sibling of the same template.
+
+`Enumeration` itself turns out to be a general device — a **self-index**,
+360/360 disc-wide; see [[idxd-container]].
 
 ## ✅ `SUBObjectiveSettings_S<NN>.tbl` — the sub-objectives