Sample mattersEvery client, case, and document on this deployment is invented for demonstration. This is purposefully a demo environment.

The deployment that says its matters are sample

NAVIGATOR_SIMULATED_MATTERS is the second selector, and it answers a different question from the first. The profile above decides which runtime wiring a boot gets; this decides whether the matters in front of a visitor are invented.

Left unset or empty it follows the profile: a dev boot carries sample matters because that is all a dev boot has, and a production boot does not, because production is where the real files are. Exactly true or false overrides that in both directions, and every other value — TRUE, 1, yes, a case or whitespace variant — is rejected rather than resolved to the permissive answer. That exactness is the point: a typo that quietly read as true would seed invented clients into a database of real ones.

The override that matters is true under a production profile, which is exactly what neon-law-stg is. Both of its selectors are production on purpose, so nothing in the running process can tell it apart from the row holding real client files. It therefore says so itself, in deployments/neon-law-stg/config.toml:


NAVIGATOR_SIMULATED_MATTERS = "true"

Two things follow from that value. store::seed applies the sample-matter fixture, so the row carries sample-litigation, sample-transactional, and sample-estate rather than an empty portfolio. And every page publishes a site-wide banner saying the matters are sample — which is why staging.neonlaw.com is a link worth handing to somebody, because a demo matter cannot be mistaken for a client's file.

It is a coordinate, not a credential, so it lives in config.toml beside the buckets and hostnames rather than in that deployment's secrets.enc.yaml. Adding it needs no SOPS re-encryption on either row.

neon-law-prod states "false" for documentation rather than for behaviour. The code already reads a missing value as false under a production profile, and ops ship renders false into the web env when a deployment's config omits the key, so the substitution is deliberately optional: a config that never mentions it still renders and still ships. A key that could halt a production rollout by being deleted would be a worse failure than the one it guards against.