Platform Integrity

1. Why Trust Is the Whole Problem

The Generational Reset asks people to change their minds about large, complicated, contested questions. That only works if they trust the source. Trust in this project has two parts that are often run together and need to be treated separately.

Trust in the content. Does the project represent what it claims to? Are the arguments fair? Are the weaknesses written down? Is the evidence real and checkable? The Gaps Register, the Sources Register and the public log of editorial decisions deal with this.

Trust in the platform. Are the signals the platform shows real? Is the number of registered supporters a real count of real people? Are the challenges and discussion posts sincere engagement or coordinated manipulation? Can the platform be gamed to create a false impression of public opinion or of intellectual dispute?

This document deals with the second question. It is a separate document, rather than a note in the product specification, because platform trust isn't only a technical concern. It is a political one.

2. What Is Live Now, and What Is Planned

This document describes both the platform as it runs today and the fuller design it is being built towards. To avoid any confusion between the two:

Live now - Registration, with a verified email address (one-time code), a verified UK mobile number (one-time code by text), a UK postcode and a first name shown publicly. - Backing individual proposals, open to registered users. Counts are shown on each proposal. - A discussion thread on each pillar, open to registered users. Posts are public and carry the poster's first name. - Challenge a Claim, open to registered users. Every challenge is logged automatically, on receipt, in the Update Register, and reviewed by a named person. - A public record of every editorial change, with the reason for it, in the Update Register.

Planned, not yet built - Identity checks through Yoti (Tier 3) before a challenge enters formal review. - An AI assessment of each challenge, as an aid to the human reviewer. - A route for promoting a discussion post into a formal challenge. - Automatic scanning of links posted in discussions. - Automated alerts for patterns of coordinated behaviour. - Possibly publishing the platform's source code (Section 9). - An annual transparency report (Section 9).

Sections 3 to 8 describe the full design and say where each part stands.

3. The Specific Threat: Coordinated Inauthentic Behaviour

Researchers use the term "coordinated inauthentic behaviour". In practice it means one actor using many identities, coordinated to give a false impression of public opinion or of intellectual challenge. The Oxford Internet Institute has recorded organised online propaganda operations in dozens of countries, including the United Kingdom, aimed at elections, referendums and public debate. It isn't a theoretical concern.

On the Generational Reset, the threat takes two forms.

Manipulating the counts. A political actor who disagrees with a pillar creates hundreds of fake registrations. The supporter counts, meant to show real public backing, become a propaganda tool: inflated by opponents to make the project look astroturfed, or boosted by supporters to manufacture momentum that doesn't exist. Either way, the count stops being a signal and becomes a liability.

Flooding the challenges. The same actor submits dozens of near-identical challenges against one pillar, not because new evidence threatens the argument, but to exhaust the reviewers, create the look of controversy or manufacture a false precedent. If the register showed 47 open challenges against the Housing pillar, a casual reader might decide the argument was in serious doubt, whether or not any single challenge had merit.

Both tactics are cheap compared with the damage they can do if the platform isn't designed against them. Email addresses are free. Creating many identities has to be made costly.

4. Our Approach: Layered Verification

Different actions need different levels of verification. The higher the stakes, the higher the bar. That is deliberate: it adds only as much friction as each action needs, instead of putting the heaviest burden on everyone who wants to take part.

Tier 1: Registration (live)

To register, back proposals, join discussions or submit a challenge, you need:

• a verified email address (a one-time code sent by email);
• a verified UK mobile number (a one-time code sent by text: one number, one registration);
• a UK postcode (only the postcode district is ever shown);
• your first name, shown publicly, and your surname, held privately (see Section 5).

A verified phone and a verified email, attached to a name that will be shown publicly, create real friction. Making many fake registrations means getting hold of many real SIM cards, which is much harder than creating email addresses. It doesn't make fraud impossible for a well-resourced actor. It makes fraud costly, and visible in proportion to its scale.

Tier 2: Discussion (live, using Tier 1)

Posting in a pillar's discussion thread uses the same verification as Tier 1, and your first name is attached to the post. Discussion is open-ended. It isn't a route into the formal challenge process; formal challenges go through Challenge a Claim.

Tier 3: Verified identity for formal challenges (planned)

At present, submitting a challenge needs Tier 1 registration, and every challenge is reviewed by a named person. The planned design adds an identity check through Yoti before a challenge enters formal review. Yoti checks identity against a government-issued document (a passport or UK driving licence): one person, one verified identity.

That would be the highest bar on the platform, because an accepted challenge leads to a permanent, attributed change to a published argument, and the person behind it should be real and verifiable.

5. First Name and Location: The Design We Chose

We show your first name and location publicly. Your surname is held on record but not shown.

We reached this after weighing two arguments. The case for a full public name is that it maximises accountability and makes a fabricated registration slightly harder. "John Ashworth from Manchester" is a slightly stronger signal than "John from Manchester".

The case against showing surnames is stronger.

The deciding point is that the protection against fraud doesn't depend on showing surnames. It depends on the verified phone number and email address (and, once built, the Tier 3 identity check). Hiding surnames doesn't make it easier to create multiple accounts; the verification is the same. What changes is that a real barrier to taking part is removed without weakening the platform.

"Sarah from Birmingham" gives the public accountability the count needs: real people, spread across the country, willing to put their name to it. Asking people to expose their full surname as well is harder to justify under UK GDPR's data minimisation principle, which says to show publicly only what the purpose requires. First name and location meet that purpose.

It also matches normal practice for public participation in Britain. Consultations, letters pages and MPs' correspondence routinely use first name and town as the accepted form of named public participation. Asking for more would be unusual.

6. What We Collect, Why, and How It Is Stored

Data collected at registration

Postcode lookup on the Me page

The Your Area section of the Me page asks for a postcode. It isn't sent to us or stored on our servers. Your browser sends it directly to postcodes.io, a free, open-source postcode service run by Ideal Postcodes, which returns the council area and the 2021 census neighbourhood used to find your main hospital trust. The postcode is then saved only in your browser, so the section remembers it next time, and the Clear button removes it. It isn't linked to any account, and you don't need one to use it.

Planned: data at Tier 3 (Yoti)

When it is built, Yoti will return a cryptographic confirmation that identity has been verified against a government-issued document. We would receive a unique verification token and the confirmed name. We wouldn't receive, store or process the document itself; the document scan and biometric check would happen entirely within Yoti's systems.

Keeping and deleting data

Registration data is held while the platform runs or until you ask for it to be deleted. You can ask for deletion at any time. Deletion removes you from all counts immediately. Posts and challenges you submitted are anonymised rather than deleted: their content may be part of the public record of how a document changed, but your name is removed.

Storage and security

Data is held in the European Economic Area (Supabase's EU West region, in Ireland) and processed in line with UK GDPR. The database is encrypted at rest as standard. Row-level security rules mean data is never exposed directly to the browser: queries return only what is appropriate for the person asking and their sign-in status. Surname, email address and mobile number are additionally encrypted at the column level.

We use Supabase for the database. Its security practices, certifications and data processing agreements are publicly available. We name it here so the choice can be scrutinised.

What we don't do

We don't sell data to anyone. We don't share registration data with any political party, campaign, think tank or company. We don't use it for advertising, profiling or any purpose beyond the platform functions described here. Individual records are never made public; only totals and geographic breakdowns are shown.

7. What the Counts Show, and What They Don't

The counts show the number of verified registrations backing each proposal. A breakdown by region and, where numbers are large enough to protect anonymity, by constituency is planned but not yet built.

What the counts show: how many real, verified people have decided an argument is worth publicly standing behind, under their own name.

What they don't show: how many people in Britain agree with the Generational Reset. Registrants choose themselves. People who find the site and decide to register aren't a representative sample of the British public, and we don't claim they are.

What they also don't show: support for the project as a whole when someone backs one proposal, or support for every proposal when someone registers. Backing is counted proposal by proposal.

8. How the Argument Process Is Protected

The challenge process has its own defences against manipulation, separate from identity checks. Identity verification protects the signals; the editorial process protects the arguments. Both are needed, and neither is enough alone.

Structured challenges (live). A challenge can't be submitted as free text alone. The Challenge a Claim form asks which pillar the claim is on, what the claim is, what kind of problem it is (contradicting evidence, missing context, or newer evidence), the evidence behind the challenge with its sources, and what the page should say instead. Producing large numbers of credible-looking challenges through that form takes real effort.

Human editorial review (live). No challenge changes a document without a named person's decision and a published reason. Nothing can bypass this step. No automated process has write access to published pages, and every change to any argument in the project has a person's name attached to it.

A public log (live). Every challenge appears in the Update Register on receipt, whether or not it holds up. A pattern of challenges against the same section in a short space of time is visible to anyone reading it.

AI assessment (planned). In the planned design, each challenge would be assessed by an AI model before it reaches the reviewer: checking the evidence cited against the pillar's argument, rating the challenge as strong, moderate or weak, and checking it against earlier submissions. The rating would advise, not decide; weak challenges wouldn't be rejected automatically, because the reviewer may disagree.

Precedent and pattern checks (planned). The planned design would flag a challenge that repeats one already reviewed and rejected, resubmitted from a different account with no new evidence. It would also flag patterns consistent with coordinated behaviour, such as many registrations from the same network in a short time, or accounts that register and immediately submit a challenge. These flags wouldn't trigger automatic action. They would be passed to the reviewer to investigate.

9. How to Check This

This document makes claims about how the platform is built and what it does with data. You should be able to check them.

Source code (not public). The platform's code is held in a private repository. We intend to publish it once it is in a stable state, but we haven't set a date and won't promise one. Until then, this page is the public account of how the platform works, and we will answer specific questions about it put through Challenge a Claim. If the code is published, this section will say so.

Editorial decision log (live). The Update Register is public. Every challenge, and every decision on it with its reason, is visible to all readers. If decisions follow a pattern at odds with the stated editorial standards, that pattern is visible.

Update log (live). Every change to every document records what changed, what prompted the review and who made the decision. Where each argument change came from is public.

This document itself. If you think the platform isn't doing what this document says (that verification is weaker than described, that data is handled differently, or that the editorial process has a gap), the right response is a challenge through the normal route, setting out the specific discrepancy and the evidence for it. Challenges about the platform's own integrity are held to the same standard of evidence as challenges about its arguments.

10. Towards Government-Verified Identity

The strongest possible identity check for a civic platform like this would be the UK government's own digital identity system. We want to be clear about our intention, and about the current limits.

What we don't mean: Government Gateway, the older login system for HMRC services. It is being replaced and isn't open to outside services.

What we do mean: GOV.UK One Login, the government's new digital identity scheme, which is replacing Government Gateway across government services. Users verify their identity once, against a passport, driving licence or other records, and can then use that verified identity across connected services.

At the time of writing, GOV.UK One Login is limited to government services; private and civic platforms can't connect to it, and no timetable for that has been confirmed.

When it does become available, we intend to offer it as the Tier 3 identity check, replacing Yoti or alongside it. That would be the strongest available sign that a person submitting a challenge is a real, uniquely verified UK resident, checked against government records rather than by a commercial service.

We are recording this intention publicly so we can be held to it. If GOV.UK One Login opens to civic platforms, we will use it. If it doesn't, we will say so.

11. What This Costs

We set out the cost of running the platform because the commitment to take no corporate funding is central to the project's credibility. Readers should be able to judge whether the costs create any dependency or pressure that could affect its independence.

SMS verification is the main variable cost, rising directly with the number of new registrations. Everything else is negligible or fixed at a low level. The total cost of running the platform is well within what the project can cover without any commercial dependency.

We don't take advertising or corporate sponsorship; the project covers these costs. If that ever changes, and we accept outside funding of any kind, it will be disclosed in this document straight away.