simd2006_pw_ca_quintile

PHS population-weighted quintile within ca; 1 = most deprived

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…)	SIMD2006CAQuintile		DataZone2001Code = DataZone

Scope: the row itself.

What was done to it: inverted. Published with 1 least deprived, so turned round as 6 - value; 1 is most deprived. (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.CAQuintile.range: every published band is within its range
• phs.2006.pw_ca_quintile.monotone: after any inversion, the band never falls as the rank rises, within its geography
• phs.2006.rank1_in_band1: the most deprived zone is in band 1 of every band: the direction is right
• join.<table>.simd2006_pw_ca_quintile.range: every joined band is within its range

Why: bands-are-looked-up, band-column-names-state-weighting, invert-2004-2006-phs-bands