The canonical seed is not gated by environment: every web boot applies the SurrealDB schema and idempotently inserts
the bundled catalog and firm-owned baseline rows in every deployment, production included. Jurisdictions are the
clearest example of the distinction this table encodes. The full reference set — all 248 rows of
store/seeds/Jurisdiction.yaml, every US state plus DC and every sovereign a matter can touch — is seeded on every
boot in every environment, because an entity's domicile and an attorney's licensure must resolve wherever the
application runs; since ENG-20 those rows live in SurrealDB, but the rule is engine-blind. The simulated cases — the
Using the Navigator matters (Henderson Bungalow Purchase, the litigation demo, the training cohort) and their example
Projects, invoices, mail, and answers — are the opposite: a second, idempotent layer that only a dev boot (local KIND,
the disposable dev staging lane) applies and the test harnesses recreate, and that no persistent hosted row ever
receives from a boot. The persistent staging deployment at www.neonlaw.com holds only simulated matters, but by
data-plane policy — everything ever entered there is synthetic — not because the compiled portfolio seeds it; the firm's
production holds real matters and neither simulated cases nor test fixtures, while its jurisdictions are identical to
every other environment's. Both layers are applied by one environment-aware orchestration call
(store::seed::seed_environment), so a reset or recreate restores the same canonical + development baseline
automatically. Provider simulation is a separate axis again: the test harness permits fakes, while a non-harness dev
uses sandbox integrations. Test suites add further records inside isolated test schemas.