What It Bought

Comparison methodology

This document defines how What It Bought represents and compares public projects. Every rule below is implemented in code and shown to visitors, so that no comparison depends on an undisclosed choice. The initial comparison is Folkestone - A Brighter Future (United Kingdom) against the Tsuruga City Central Hub District Urban Regeneration Project (Japan).

1. Programmes and components

A programme is the whole funded initiative as its accountable body reports it: one name, one headline budget or expenditure figure, one set of dates, and one or more public bodies. In the data model a programme is a Project.

A component is an individually identifiable work package within a programme: a square, a road, a walkway, a school. Components carry their own type, dimensions, cost and delivery state where these are published. In the data model a component is a ProjectComponent.

A headline programme figure is never treated as directly comparable with another programme's headline figure when the two programmes bundle materially different kinds of work. The UI always shows programme-level and comparable-scope figures as two separate things, labelled differently.

2. The two views

2.1 Programme comparison

Compares the overall scale of each programme: headline money, programme period, programme area where known, number and type of components, and delivery state. It is shown with a standing warning that the scopes differ.

2.2 Comparable works comparison

Compares only components inside an explicitly named comparison scope. The first scope is:

Town-centre transport and public realm

Component types included in this scope:

Component types excluded: education, building, parking, other.

A comparison stores, per component, whether it is included and the reason if not. Every component of both programmes is listed on the comparison page. Excluded components are shown, with their cost and size, under an "Excluded from this comparison" heading. Nothing is hidden.

The include_in_comparable_scope flag on a component is a curation default for the current methodology. The stored comparison scope is authoritative for a given comparison page.

2.3 Tsuruga exclusions and why

Component Decision Reason
Integrated primary / junior-high school (18,000 m², ¥1,845.3m) Excluded An education building. Folkestone's programme contains no equivalent, and school construction is not town-centre transport or public realm. It is 58% of Tsuruga's grant-eligible expenditure, so this exclusion is disclosed prominently.
East Station parking (1,450 m², ¥393.4m) Excluded Vehicle parking is a distinct asset class. Folkestone's programme builds no parking; it removes some (Bouverie Square car park becomes green space). Including it would count a car park on one side against its removal on the other. Disclosed as excluded.
All other published Tsuruga components (road 175, both station squares, covered walkway, Route 8 greening, east-side pedestrian and accessibility works) Included Station approaches, squares, walking infrastructure and greening.

All Folkestone components fall within the scope by type. That does not make Folkestone's programme cost a comparable-scope cost (see 3.3).

3. Money

3.1 Budget versus expenditure

Every monetary value is stored as a ProjectCost with an explicit cost_type, an is_actual flag and an is_final flag.

A programme's headline figure is its final actual expenditure where one exists, otherwise its programme budget. The label always says which. Folkestone's headline is therefore a budget; Tsuruga's is final expenditure. The UI states this on every page where the two appear together.

3.2 Programme cost versus contract value

The main construction contract value is stored separately from the programme budget and the construction estimate. It is shown beneath the budget breakdown, never in place of it.

3.3 Comparable-scope cost

The comparable-scope cost of a programme is the sum of component_cost records of components included in the scope. It is calculated only when every included component has a published component cost. Otherwise it is shown as Not published with an explanation. It is never substituted with the programme budget, construction estimate or contract value.

For Folkestone no component-level costs have been published, so its comparable-scope cost is Not published. The page notes that all of its components are in scope and that the programme budget is therefore an upper bound that also includes fees, contingency, art and inflation allowances.

3.4 Currency

Original values are stored and displayed in their original currency, always. Two derived values are shown beside them, each labelled as calculated:

Every conversion factor is an EconomicFactor row with a year, a type and a source. Converted values are calculated at render time from the stored original and the stored factor; they are never typed in. Each converted figure can be expanded to show the formula, the factor, its year and its source.

The reference year for the Folkestone–Tsuruga comparison is 2023: the final fiscal year of Tsuruga's programme and the year Folkestone's funding was awarded and its budget priced.

3.5 Price years and inflation

Tsuruga's expenditure is the nominal sum of outlays across FY2019–FY2023. Folkestone's budget is a 2022/23 price estimate that already contains an explicit inflation allowance. At present no inflation adjustment is applied before conversion. This is disclosed. The inflation_index factor type exists so that a common-price-year adjustment can be added without changing the schema; when it is added, both programmes must be adjusted to the same reference year before conversion, and the page must say so.

3.6 Cost variance

Cost variance = actual final expenditure − original programme budget, expressed in the original currency and as a percentage of the budget. It is calculated only when both values exist for the same programme and the same scope. Folkestone has no actual expenditure, so no cost variance is shown for it. Tsuruga has a final expenditure figure but the initial plan budget is recorded separately where published; if it is absent, no variance is shown.

3.7 Population and cost per resident

Each place stores a population, its year and its geography (for example "ONS built-up area" or "whole municipality"). Cost per resident = headline figure ÷ population and is shown with the geography stated in the label. When the two places use different geographies the comparison shows both figures with a warning that the denominators are not like-for-like. Cost per resident is shown on the headline figure only, never on the comparable-scope cost, because the population served by a subset of works is not defined.

4. Time

4.1 Planned versus actual dates

Dates are stored on milestones with separate planned_at and actual_at columns, plus optional text labels for dates published imprecisely ("Summer 2026", "Late 2026"). The label is displayed; the date is used for arithmetic.

Imprecise dates are converted to a single date using the latest day of the stated period: "Summer 2026" → 31 August 2026; "Late 2026" → 31 December 2026; "FY2023" (Japanese fiscal year) → 31 March 2024. Using the latest date is the interpretation most favourable to the delivering body and is stated wherever such a date is used.

4.2 Incomplete programmes

A programme with status other than completed has no actual_completed_at. The application refuses to compute a final duration for it. It shows elapsed time so far from construction start to today, labelled "ongoing", and a current expected completion. Nothing on the page implies the programme's final performance is known.

4.3 Duration

Durations are shown in months (and years where over 24 months), rounded to the nearest month.

4.4 Schedule variance

Schedule variance = (actual completion, or current expected completion if incomplete) − original planned completion, in months. When the programme is incomplete the figure is labelled "currently expected" and can still grow. When either date is missing no variance is shown.

5. Physical outputs

Outputs are the tangible things constructed: squares, crossings, trees, walkways. Each is stored with a metric_key, a value, a unit and a status (planned, in_progress, delivered).

Outputs are compared only where both programmes publish the same metric in the same unit. Where only one programme publishes a metric it is listed for that programme alone and the other side reads "Not published". No equivalent unit is manufactured: 7 crossings are not converted into square metres, and 5,500 m² of greening is not converted into trees.

Output status is never upgraded by the application. An output is delivered only when the source says it has been delivered.

6. Outcomes and indicators

An indicator is a measured outcome rather than a constructed thing (station boardings, footfall, population density). Each stores baseline, target and actual values with their years and a higher_is_better direction. The application derives one of four states:

These are shown as plain statements beside the numbers. No commentary is added. A programme with no indicators shows "Awaiting post-completion data".

7. Missing data

A missing value is stored as null and rendered as Not published, or Awaiting data for a value expected later. It is never rendered as 0, omitted, or filled in from another field. Missing data is treated as information about the publishing body.

8. Evidence

Every material value links to at least one Source through an EvidenceLink naming the field it supports. Sources keep their original-language title, with an optional English title. The page shows a source affordance beside each figure. Values without evidence are flagged by an audit command and by the integrity tests, and the seed data must pass that audit before it is shown publicly.

Evidence strength is a rule, not a judgement:

9. What is deliberately not done