Skip to content

simd2006_most15pc

PHS population-weighted 15% most deprived flag, as published

Table Type Nullable Category In the CSV export SQL Server type
history table (postcode_simd_history, SPD) int8 no PHS SIMD, population-weighted yes tinyint
main table (postcode_simd, SSPL) int8 no PHS SIMD, population-weighted yes tinyint

Provenance (the same in both tables)

Each table runs its own copy of the table-level checks, named .history. and .main..

Where it comes from

Input Field Condition Reaches the row by
PHS/simd2006_02042020.csv (pinned, SHA256 69f9fb1a2e51…) SIMD2006Most15pc DataZone2001Code = DataZone

Scope: the row itself.

What was done to it: copied. Copied as published, 1 or 0. (code: simd_ingest/core/phs.py: canonicalise_phs)

How it is checked (what each check tests; whether a build passed it is in that build's manifest.json["checks"])

  • source.hash.PHS/simd2006_02042020.csv: the pinned file's SHA256 equals the registry's: the bytes are exactly the ones reviewed
  • phs.2006.source.schema: the PHS file's header is the declared one
  • phs.2006.source.key_unique: each data zone appears once in the PHS file
  • cross.2006.same_zones: PHS and the Government publish the same data zones for the edition
  • join.<table>.phs.2006.every_record_matched: every record found its data zone in the edition: no empty cell
  • readback.<table>.attached_values: every attached value in the saved file is looked up again from the sources and equal
  • phs.2006.source.Most15pc.binary: every published flag is 0 or 1
  • phs.2006.flag_anchors: the most deprived zone is flagged most deprived, the least deprived least
  • join.<table>.simd2006_most15pc.binary: every joined flag is 0 or 1

Why: bands-are-looked-up, band-column-names-state-weighting