Data integrity
How we keep ScoreView’s data trustworthy
By Richard Sutcliffe, Chief Technology OfficerAudit completed . Corpus last refreshed .
Why this matters
Housing professionals decide based on what ScoreView shows them.
Regulatory positioning, complaint-handling priorities, and board decisions all rest on these figures. We owe you a clear account of where each number comes from and what it does and does not show.
This page explains what we checked, what we changed, and how the platform defends itself against the kind of silent errors that creep into any data product.
What we checked
Three layers, end to end.
- Ingestion. How Housing Ombudsman determinations move from the public record into our database.
- Analytics. How individual records become benchmarks, trends, and peer comparisons.
- Presentation. How those numbers, and the AI briefings derived from them, reach you.
Across these layers we surfaced more than 30 specific risks: a number could be misread, a record could be silently mis-categorised, or an AI-generated briefing could be mistaken for an Ombudsman quote.
What we fixed
Six changes, one principle: never let a failure look like a finding.
Silent defaults killed
Previously, if our scraper failed to extract a determination’s outcome, the record would fall back to “no maladministration”, making an extraction failure indistinguishable from a landlord being cleared. Likewise, a missing publication date would silently become today’s date, surfacing the record in trend charts as fresh news. Both fallbacks are gone. Extraction failures now carry an explicit parse error flag and are excluded from every analytics view by invariant.
Failures filtered by enforced rule
Every analytics query (sector outcome rates, landlord rankings, time-to-determination percentiles, category-level remedy rates) filters out parse-error records. An automated check runs on every code change to prevent any new query from forgetting this filter.
Small samples are labelled
Benchmarks and peer comparisons built on fewer than 25 records are labelled. Fewer than 10: low‑confidence. Fewer than 5: very‑low‑confidence. AI briefings cannot declare sector trends from underpowered samples and must flag when the most recent quarter is still in progress.
Provenance you can quote
Every CSV, PDF, PowerPoint, and Word export carries a methodology page: the corpus snapshot date, the exact filter set used (as a reproducible hash), and a link back to the Housing Ombudsman source for every record. Email digests and the determination detail page do the same. AI-generated summaries are labelled clearly. They are ScoreView’s interpretation of structured metadata, never the Ombudsman’s wording.
Staleness is visible
Every dashboard shows when the corpus was last refreshed. If our scheduled ingestion fails or stalls beyond a 10-day window, a red warning appears on screen. You will know the data is stale before you cite it.
Source links on every record
Every determination on every screen (search results, detail pages, exports, alert emails, sector digests) links back to the original record on the Housing Ombudsman website. Crown copyright is respected: we store structured metadata only, never the determination text.
What we proved at launch
We applied the corrected extraction back over the stored record.
The fixes above were not just for new data. In the May 2026 audit we went back over the whole corpus and corrected 664 existing records: 50 had a wrongly defaulted outcome corrected, 245 were recategorised, 191 had their AI summaries regenerated from the corrected metadata, and 178 that could not be parsed reliably were excluded from analytics rather than left to pass as findings.
Continuous re-verification
We re-check our own record against the source, and publish what changes.
A one-off audit tells you a dataset was right on a particular day. It says nothing about the day after. So verification at ScoreView is a standing process: we periodically re-fetch determinations from the Ombudsman and re-extract them from scratch, then compare the result against what we hold. Where the two differ, the source wins and we say so here.
In August 2026 we ran that process across the full historical corpus, re-fetching and re-extracting 14,729 determinations against the live Ombudsman record. Extraction has improved considerably since the earliest records were ingested, in particular its handling of determinations that record several findings at once, and the re-run applies today’s extraction to every record regardless of when it first arrived.
- 11,694 outcomes were refined. Determinations previously recorded as no maladministration, where the determination in fact recorded a finding, now carry that finding: 4,354 maladministration, 666 severe maladministration, and the remainder service failure, reasonable redress or outside jurisdiction.
- Publication dates now come from the determination. Around 6,700 records had taken the date their source page was published to the web. They now carry the date of the determination itself.
- 23 landlords consolidated. Twenty-three local authorities were being matched under two spellings of their own name. Each is now a single entity scored across its whole record rather than a divided one.
Two things are worth drawing out. First, every correction moved toward showing more adverse findings, not fewer: the process does not flatter the landlords we cover. Second, the count of records we cannot read did not move at all. It was 160 before the re-run and 160 after. Where a page cannot be parsed we still refuse to guess at it, and it still stays out of every analytic.
This re-verification is now continuous rather than periodic. An automated integrity check runs against the production corpus every day and fails loudly if any single outcome accounts for an implausible share of the record, if publication dates cluster on one day, if the corpus stops updating, if a landlord appears under two identities, or if a score is recorded more than once for the same day. Each of those is a shape that a real defect makes in real data, and each is checked without anyone having to remember to look. They are specific checks for specific failures, not a guarantee that nothing else can go wrong.
We re-derive our history from source rather than trusting what we stored the first time, because a number you can check is worth more than a number you are asked to take on faith.
How we keep it true
The audit was a moment. These controls run continuously.
Seven controls are built into the platform:
- Database-level guards. Bulk-delete operations on the corpus table are blocked at the PostgreSQL level. Only an explicit, audited override can perform a corpus-wide write.
- Regression tests, mandatory. Every silent-default failure we fixed has a test that would catch its return. Tests run on every code change.
- Static analysis at merge. Any new analytics query that fails to exclude parse-error records is rejected automatically.
- Health-check thresholds on every scrape. If unclassifiable landlords exceed 10%, or unknown categories exceed 5%, the run is flagged for review before the data reaches production.
- AI briefing guard rails. The AI cannot claim a trend from a small sample, cannot characterise the latest in-progress period as a spike or decline, and cannot reproduce determination text.
- Append-only ingestion. The corpus grows by upsert, not by truncate-and-rebuild. Historical records cannot be silently lost.
- Backups before any retro-fix. Every script that touches historical data takes a database backup first, and refuses to run without one.
How to read what you see
Every figure on this platform is five things.
When you read a ScoreView number, you can take it as:
- Clean. Drawn from Housing Ombudsman determinations that parsed without error. Anything that failed extraction is excluded, labelled, and visible to our engineering team for follow-up.
- Fresh. Refreshed weekly. The “as of” date is shown on every dashboard. If the platform has not refreshed recently, you will see a warning.
- Reproducible. Every export records the filters used and the snapshot date, so a figure you quote today can be reproduced and defended later.
- Sized. Sample counts are shown; benchmarks below the confidence threshold are marked.
- Sourced. Every determination links to its public record on housing-ombudsman.org.uk. You can verify any single data point at source.
AI-generated content (synthesis briefings, summaries, weekly digests) is labelled, and works only from cleaned structured metadata. It is not the Ombudsman’s wording, and it is not a legal opinion.
Questions and corrections
If a number looks wrong, we want to know.
Email corrections@thinktribal.co.uk, quoting the URL and the date. No account needed. We acknowledge within five working days and respond substantively within fifteen. Where a regulator publishes a correction, withdrawal or revocation, we reflect it within five working days.
For the underlying source data we draw from, see our Data Sources and Methodology page.