re: the 8 values per asteroid are index, quaternion, position

Measured over every Frame_*Asteroid* record on the disc - 384 records, 37518
items (6253 per language pack x 6; the remaining 380 per pack belong to the
seven record-less Alpha frames, the same 57-vs-64 split as before).

  slot 0    equals the running index 0..N-1   37518 / 37518, max 587, and the
            largest FrameCount is 588, so the last index is N-1
  slots 1-4 a unit quaternion                 37518 / 37518 within 1e-4 of 1.0
            (min 0.999999, max 1.000001)
  slot 4    sign of the real part             min +0.001, never negative -
            canonical w-last, so the order is (x, y, z, w)
  slots 5-7 position in metres                -163858..+79572, -114308..+76422,
            -105224..+110263 - inside the +/-250 km half-extent of
            mapmesh_box_500km

len(anonymous fields) == 8 * FrameCount on 384 of 384, zero mismatches.

The unit-norm test is the control: an arbitrary 4-tuple has no reason to sit on
the unit sphere and every one of the 37518 does. Two further cross-checks fell
out - the maximum index is exactly max(FrameCount) - 1, and every position lies
inside the 500 km box the corpus already knows (world unit = 1 metre).

There is no scale slot: an asteroid's size comes from its group's
AsteroidModelName, which is why a group is one model plus one placement list.

Not settled: whether the quaternion is object->world or world->object and its
handedness - a norm test cannot separate those; and why S28_p1 has an asteroid
volume with no definition.

All fifteen artefacts byte-identical.

docs/re/structures/asteroid-fields.md

@@ -112,9 +112,37 @@ works here. (`Stage\` scores identically — the hash lower-cases.)
 **Two independent joins, 9/9 agreement**, and both leave the same tenth object
 unreferenced.
 
+## ✅ 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,
+37 518 items** (6 253 per language pack × 6; the other 380 per pack belong to the
+seven record-less `Alpha` frames). One raw item, for shape:
+
+```
+0   0.268744  0.505919  0.579670  0.579487   15667.14  -7199.61  -58794.88
+1  -0.053496 -0.540765 -0.260996  0.797868  -43571.37 -60583.68   -3417.80
+2  -0.696396  0.682371  …
+```
+
+| slot | test | result |
+|---|---|---|
+| 0 | equals the running index `0…N−1` | **37 518 / 37 518**, max **587** — and the largest `EnumAsteroid`/`FrameCount` is **588**, so the last index is `N−1` |
+| 1–4 | is it a **unit quaternion**? `\|q\|` | **37 518 / 37 518 within 1e-4 of 1.0** (min 0.999999, max 1.000001) |
+| 4 | sign of the real part | min **+0.001**, never negative — the canonical **w-last** form, so the order is `(x, y, z, w)` |
+| 5–7 | position, metres | ranges **−163 858…+79 572**, **−114 308…+76 422**, **−105 224…+110 263** — inside the ±250 km half-extent of `mapmesh_box_500km` |
+
+And `len(anonymous fields) == 8 × FrameCount` on **384 of 384** records, zero
+mismatches.
+
+The unit-norm test is the control: an arbitrary 4-tuple has no reason to sit on
+the unit sphere, and **every one of the 37 518 does**. World unit = 1 metre, so
+these are metres from the map origin. **There is no scale slot** — an asteroid's
+size comes from its group's `AsteroidModelName`, which is why one group is one
+model plus one placement list.
+
 ## 🟡 Not settled
 
-* What the 8 values per asteroid are — position/rotation/scale is the obvious
-  reading, untested here; [[regn-map-grid]] has the neighbouring work.
 * Why `S28_p1` has an asteroid volume and no definition (S28 is the challenge
   mission that alone flies `rou_f004`, see [[stage-numbering-and-player-craft]]).
+* Whether the quaternion is object→world or world→object, and its handedness —
+  the norm test cannot tell them apart.