Methodology

How the score is built

1. Collect. Each indicator is pulled from a named public source on a defined cadence (see the table per pillar).
2. Normalise. Each indicator's current reading is mapped to its empirical percentile against an expanding baseline running from 2019-01-01 to today, excluding the COVID shock window 2020-04-01–2020-06-30. The baseline includes today's reading itself; for series with hundreds of observations, this contributes <1/n to the rank and is harmless. We also compute a z-score against the same baseline and surface it on the homepage tiles for context, but the score itself does not use the z-score as an input.
   Why this window: 2019-01-01 is the earliest date for which the four-pillar mix (gilt yields, OBR fiscal vintages, ONS LMS, MHCLG quarterly housing) is jointly available without splicing methodology breaks. The upper bound is "today" — every recompute folds today's reading back into the baseline, so the percentile mass shifts glacially as new data arrives. The 2020-Q2 exclusion drops the three-month window when GDP fell ~20% in a quarter and gilt issuance broke 9% of GDP — including those points would mean a normal-times reading like "gilt 30y at 5%" landed at the 60th percentile rather than its true ~95th, because the dispersion would be artificially fattened by a shock that has now passed. The exclusion is fixed and disclosed (versus a moving window or a "robust" trimming that would silently change the score).
3. Direct. Where a rising raw value is bad for the underlying condition (e.g. gilt yields, borrowing, inactivity), we invert the percentile (p → 1 - p) so every indicator yields a public score on the same axis: higher = more room to move, lower = closer to the rope giving way.
4. Bound to [0, 100]. The direction-adjusted percentile is multiplied by 100. The chart below illustrates the shape, but note: production uses the empirical CDF over each indicator's actual baseline, not a normal CDF — the shape varies per indicator (gilt yields are roughly log-normal; planning consents heavily skewed).
5. Pillar score. Weighted arithmetic mean of the pillar's indicators. Arithmetic at the pillar level means individual inputs are additive and debuggable.
6. Headline Tightrope Score. Weighted geometric mean of the four pillar scores. Geometric at the headline level means one weak pillar pulls the headline down hard — the correct behaviour for a tightrope metric where one failing support cannot be fully offset elsewhere.

Inputs, weights and sources by pillar

A note on the Direction column: it describes whether a rising raw value is good or bad for the underlying condition (e.g. rising gilt yields = "Rising = worse"). The public Tightrope Score is always high-good — we apply the inversion in step 3 above before the score reaches the page. So a "Rising = worse" indicator can sit next to a healthy-looking pillar score without contradiction: the indicator's raw direction and the pillar's score axis are not the same axis.

What the historical chart covers

Every trajectory and sparkline on this site reads from stored pillar scores. Those scores are produced by two pipelines and the difference matters:

• Live recompute — runs every five minutes against every indicator in a pillar. This is what powers the headline score, the 24-hour change, and the latest points on every chart.
• Historical backfill — writes one row per UTC day for every day in range. For quorum and scoring, it uses only indicators whose values carry a defensible time-series. Two kinds of indicator are excluded: those whose values are editorial interpretations of political milestones (e.g. delivery progress scores), and those whose upstream feed only exposes today's snapshot with no machine-addressable history (e.g. DMO gilts-in-issue). In both cases a score prior to today was never a score those indicators contributed to.

Implemented by historicalIndicatorsForPillar() in packages/shared/src/historicalSubset.ts and exercised by packages/shared/src/historicalSubset.test.ts. Drop hasHistoricalSeries: false on a catalog entry and the disclosure above picks it up automatically.

Missing days on the trajectory

Each trajectory sparkline covers a 30-day window with one plot-point per UTC day. A day is plotted when the pillar meets quorum: at least half of its observed indicators are within their freshness window. A day that fails quorum is not plotted — the line skips that day rather than carrying forward the previous value.

Under each trajectory chart we report "Scored N of 30 days" so readers can see how complete the rendered series is. If N < 30, the missing days failed quorum (typically a batch of indicators not yet ingested for that day, or an adapter outage). The homepage's stale chip surfaces today's quorum state; the trajectory coverage count surfaces the last 30 days at a glance.

Last successful ingestion per source

success = fetch returned a payload different from the previous run (new data). unchanged = fetch returned the same bytes as last time (upstream has not republished since the previous "success" row; common for monthly ONS / semi-annual OBR series between publications). Both are healthy states.

Pillar quorum & staleness

Not every indicator is fresh every day. ONS PSF publishes monthly with a 45-day lag; OBR EFO publishes twice a year; even the BoE's daily rate feed is quiet at weekends. We want the headline score to keep running when a single upstream goes quiet, but we also don't want to publish a pillar score composed mostly of stale readings. The quorum rule is the bright line between those.

• Per-indicator freshness. Every indicator carries its own maxStaleMs — tuned to the publisher's cadence, not a pillar-wide window. An ONS PSF observation is "fresh" if it is within ~90 days; an OBR EFO figure is "fresh" within ~220 days. See the inputs table above.
• Pillar quorum = half the observed indicators. For each pillar we count how many indicators have any observation on file (observedCount). The quorum is ceil(observedCount × 0.5), floored at 1. If fewer than that many indicators are fresh, the pillar is marked stale.
• Missing ≠ stale. An indicator with no observations at all (a data-engineering gap) is excluded from the quorum denominator. It shows up in the /sources page as "no data" without tripping the pillar into stale.
• What happens when a pillar is stale. The ingest recompute still computes a pillar score from the observations on file, but it does not persist a new pillar_scores row for that pillar and does not write the headline row. The UI surfaces the stale chip on that pillar tile and on the nav bar.
• Historical backfill is stricter. The backfill only writes a pillar_scores row for days that met quorum, so gap days never carry forward (see "Missing days on the trajectory" below). The headline row is written only when all four pillars met quorum on that day.

Implemented by evaluatePillarFreshness() in packages/shared/src/staleness.ts. Tested via packages/shared/src/staleness.test.ts. The exact fraction (0.5) is exported as PILLAR_FRESHNESS_QUORUM_FRACTION so live recompute and backfill share one constant.

Upstream revisions & our correction policy

Official statistics are revised. The ONS labour-market release, the PSF outturn figures, and MHCLG's quarterly housing numbers are all routinely restated — sometimes for several releases in a row. Our ingest policy acknowledges that:

• Upstream revisions overwrite silently. Our indicator_observations writes use INSERT OR REPLACE keyed on (indicator_id, observed_at). When ONS issues a revised value for February's PSF, the next ingest run replaces the old row. The current snapshot on this site always reflects the latest upstream vintage.
• What we don't do: we don't keep a vintage history of every prior value ONS published. Reconstructing "what the ONS said on Tuesday vs Thursday" is not a goal of this project — that's what the ONS revision log is for. We link to it from each affected indicator's source card.
• What counts as a correction: a Tightrope correction is a change we made on our side — a methodology change, a sign fix, a label mistake, an editorial figure restated. Every one appears dated in the corrections log with both original and revised values. Upstream revisions by the ONS, OBR, BoE, etc. are not Tightrope corrections — they are restatements by the primary source, and we link to the source rather than duplicate its version history here.
• Backfill idempotency: when we re-ingest historical data, the default is INSERT OR REPLACE so a reprocessed batch converges to the upstream's current truth. The admin path can flip to INSERT OR IGNORE to freeze a vintage (used, e.g., when auditing what a prior recompute had seen).

Implemented in apps/ingest/src/lib/observations.ts (writeObservations / writeHistoricalObservations). Tested in apps/ingest/src/tests/backfillObservations.test.ts.

Open questions & known limitations

• The baseline window excludes 2020 Q2 but retains the 2021–22 energy shock period. Changing the baseline requires a versioned methodology update — no silent rebaselining.
• Intra-pillar weights sum to 1 per pillar; they are normalised at scoring time even if the raw weight values in INDICATORS don't sum to exactly 1 (they are target weights).
• Delivery progress indicators are rising-good: higher raw progress produces a higher public score, just like higher real pay or stronger market confidence.
• The geometric mean at the headline level cannot handle a zero input. In practice no pillar score reaches 0. We guard against it anyway by adding a tiny epsilon (1e-6) inside the log and subtracting the same epsilon after exp — so a zero pillar pulls the headline strongly toward zero (as an unguarded geometric mean would) without producing log(0). See weightedGeometricMean in packages/methodology/src/normalise.ts.

Corrections, source code, snapshots

Every correction to a published number appears in the corrections log, dated, with the original and revised values and the reason. The source code for the scoring library is MIT-licensed on GitHub, and the nightly snapshot of the D1 database is committed publicly — if you believe a number on this site is wrong, you can verify it end-to-end.

Licensing & attribution

UK public-sector data on this site (Bank of England, OBR, ONS, DMO, MHCLG, DESNZ, gov.uk, parliament.uk, legislation.gov.uk) is reproduced under the Open Government Licence v3.0. Per-source terms — including non-OGL feeds (S&P Global PMI, EODHD, Moneyfacts, RICS, GfK / NIESR) — are listed on the sources page. The application code is MIT-licensed.