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 sample-matter fixture —
three synthetic Projects, their participants, and their walkthrough rows — is the second, idempotent layer. It is
applied wherever NAVIGATOR_SIMULATED_MATTERS resolves true: every dev boot, whether local KIND or the disposable
staging lane, plus neon-law-stg, which says so explicitly because its own runtime profile is production. So
staging.neonlaw.com serves the three demo matters under the sample-matter banner, and www.neonlaw.com holds live
matters and no fixture; both receive the same canonical reference data. Both layers are applied by one environment-aware
orchestration call (store::seed::seed_environment), so a reset or recreate restores the same baseline automatically.
Provider simulation is a separate axis: the test harness permits fakes, while non-harness dev uses sandbox integrations.
Test suites add further records inside isolated test schemas.