diff --git a/docs/superpowers/specs/2026-10-06-inspection-status-beyond-ofsted-schools-design.md b/docs/superpowers/specs/2026-10-06-inspection-status-beyond-ofsted-schools-design.md
index 82c5dbe..607df88 100644
--- a/docs/superpowers/specs/2026-10-06-inspection-status-beyond-ofsted-schools-design.md
+++ b/docs/superpowers/specs/2026-10-06-inspection-status-beyond-ofsted-schools-design.md
@@ -234,9 +234,16 @@ E2E.
   not from a `ukprn` column on `stg_gias_establishments`. A `ref` to
   `stg_gias_establishments` from the Ofsted models would put them in the daily
   build's `stg_gias_establishments+` selection, where their Ofsted parents are
-  not built (`pipeline/tests/test_dag_selectors.py`). The daily build selects
-  `stg_gias_ukprn` by name; `stg_gias_establishments` gains only
-  `inspectorate_name`.
+  not built (`pipeline/tests/test_dag_selectors.py`). The monthly Ofsted build
+  selects `stg_gias_ukprn+`; the daily build must not rebuild it, because
+  rebuilding a view drops the views on it (CASCADE) and `dim_school` reads
+  them. `stg_gias_establishments` gains only `inspectorate_name`.
+- **First rollout order (each environment, once).** The new models need
+  `raw.gias_establishments."UKPRN"`, which only a daily run with PR 1 creates,
+  and `dim_school`'s unit tests need `int_ofsted_listed`, which only a monthly
+  run creates. So: run the daily DAG (its `dbt_build` fails once on
+  `dim_school`'s unit tests — expected), then `school_data_monthly_ofsted`,
+  then the daily DAG again. From then on both schedules run normally.
 - **A report card is recognised by `rc_inspection_date` as well as by its area
   labels** (`hasReportCard`), on the school page and in compare. An FE report
   card carries a safeguarding result and no school areas, so the label test