Managed demo seed datasets

Seed manifests are version-controlled JSON files under ops/demo/seeds/manifests/. A manifest can invoke only an allowlisted Django management command with scalar, structured arguments. File inputs must be repository-relative regular files below ops/demo/seeds/data/, present in the selected release, non-symlinked, and matched by SHA-256 before mutation.

The tutorial and training GeoPackages are generated from synthetic-source.geojson. Their coordinates and identifiers are deliberately synthetic and contain no parcel, client, or production data. Real parcel exports must not be committed or used as managed-demo seed inputs.

To revise an approved dataset:

  1. Review the synthetic source and record its provenance in the manifest description.
  2. Generate the GeoPackage with the repository’s documented GDAL tooling.
  3. Inspect its schema and features, and confirm it contains no client information.
  4. Compute sha256sum ops/demo/seeds/data/<name>.gpkg.
  5. Update source_sha256, deterministic seed, and any command arguments in the matching manifest.
  6. Run /home/assela/python/.venv/bin/python -m unittest tests.demo.unit.test_seed_manifests against the workstation checkout.

The approved tutorial and training manifests load more than static parcel geometry. Their allowlisted seed_workflow_demo_data2 command creates synthetic workflow actors, parcel history, and workflow examples. Seed-created actors have unusable login passwords; the lifecycle command separately provisions the initial usable demo administrator.

To add a new approved dataset, create a synthetic GeoPackage below ops/demo/seeds/data/ and a matching JSON manifest below ops/demo/seeds/manifests/. Use a lowercase identifier, the allowlisted command, scalar arguments, a repository-relative source path, the exact SHA-256 digest, and "approved_synthetic": true. Document the synthetic provenance and expected workflow features. Never copy production data and never approve a symlink or a file outside the seed-data directory.

Reset is intentionally delete followed by create. It reuses the verified anchor's exact release and approved manifest, creates a new environment identifier, reloads the workflow data, and provisions a new administrator password.