Platform Integrity

1. Why Trust Is the Whole Problem

The Generational Reset is asking people to change their minds about large, complex, contested questions. That is only possible if they trust the source. Trust in this project has two distinct components that are often conflated and need to be treated separately.

Source trust — does the project represent what it claims to represent? Are the arguments honest? Are the weaknesses documented? Is the evidence real and verifiable? This is addressed through the Gaps Register, the Sources Register, and the public editorial decision log.

Platform trust — are the signals the platform shows genuine? Is the number of backers a real count of real people? Are the challenges in the forum honest intellectual engagements or coordinated manipulation? Can the platform be gamed to create a false impression of public sentiment or intellectual controversy?

This document addresses the second question. The reason it exists as a standalone document — rather than a footnote in the product specification — is that platform trust is not a technical concern. It is a political one.

2. The Specific Threat: Coordinated Inauthentic Behaviour

The research literature uses the term coordinated inauthentic behaviour. In practice it means one actor, many identities, coordinated to create a false impression of public sentiment or intellectual challenge. The Oxford Internet Institute has documented organised computational propaganda operations running in scores of countries — including the United Kingdom — targeting elections, referendums, and public discourse. This is not a theoretical concern.

On the Generational Reset, this threat takes two concrete forms.

Counter manipulation. A political actor that disagrees with a specific pillar argument creates hundreds of fake registrations. The momentum counter, which is meant to show genuine public backing, becomes a propaganda tool — inflated by opponents to make the Reset look astroturfed, or artificially boosted by supporters to manufacture the appearance of momentum that does not exist. In either case, the counter stops being a signal and starts being a liability.

Challenge flooding. The same actor submits dozens of structurally similar challenges against a specific pillar — not because the argument is genuinely threatened by new evidence, but to exhaust the editorial team, create the visual impression of controversy, or manufacture a false precedent. If the editorial queue shows 47 open challenges against the Housing pillar, a casual reader might conclude the argument is in serious dispute, regardless of whether any individual challenge has merit.

Both tactics are low-cost relative to their disruptive potential if the platform is not designed against them. Email addresses are free. The cost of creating many identities must be made real.

3. Our Approach: Layered Verification

We use different verification requirements for different actions. The higher the stakes of the action, the higher the bar. This is deliberate: it creates the minimum friction necessary at each level rather than imposing the maximum burden on everyone who wants to engage.

Tier 1 — Registering Support (Momentum Counter)

To register as a backer and appear in the public counter, you need:

• A verified email address (email OTP confirmation)
• A verified UK mobile number (SMS one-time code — one number, one registration)
• A UK postcode (required for geographic mapping; only the district is publicly displayed)
• Your first name and location displayed publicly (your surname is verified and held privately — see Section 4)

The combination of verified phone and verified email, attached to a name that will be publicly visible, creates meaningful friction. Creating many fake registrations at this level requires acquiring multiple real SIM cards. This is significantly harder than creating multiple email addresses. It does not make fraud impossible for a sufficiently resourced actor. It makes fraud costly and visible in proportion to its scale.

Tier 2 — Forum Participation

Submitting a post to a pillar discussion thread uses the same verification as Tier 1. Your real name is attached to the post. The structured submission format — cite the specific claim you are challenging, cite the specific evidence with a verifiable source, state the proposed correction — is itself a quality filter. Generating volume of structurally coherent, evidence-backed submissions at scale requires effort that grows with quantity.

Tier 3 — Formal Challenge Submission

Promoting a discussion post to the formal challenge queue — where it enters AI assessment and editorial review, and where an accepted outcome could change a published document — requires verified identity via Yoti. Yoti checks your identity against a government-issued document (passport or UK driving licence). One person. One verified identity.

This is the highest-stakes action available on the platform and it warrants the highest bar. A challenge that passes this gate and is accepted by the editorial team will result in a permanent, attributed change to a published argument. The person behind it needs to be real and verifiable.

4. First Name and Location: The Decided Design

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

This is a deliberate design decision reached after weighing two competing arguments. The case for requiring a full public name: it maximises accountability and makes a fabricated-looking registration marginally harder to produce. A counter showing "John Ashworth from Manchester" is a slightly stronger signal than "John from Manchester."

The case against requiring full public surname display is stronger.

The decisive point is that the anti-fraud mechanism does not rely on the surname being publicly displayed — it relies on the verified phone number, email address, and at Tier 3, Yoti identity verification. Hiding the surname from public view does not make it easier to create multiple accounts. The verification is unchanged. What changes is that a real barrier to participation is removed without weakening platform integrity.

"Sarah from Birmingham" achieves the social accountability signal the counter requires. These are real, geographically distributed, named people willing to stand behind this publicly. That is what matters. Requiring the additional exposure of a full surname is harder to justify under UK GDPR's data minimisation principle — you should display publicly only what is necessary for the stated purpose, and first name plus location meets that purpose.

This design also matches the standard for legitimate civic engagement in Britain. Petitions, public consultations, and MPs' correspondence routinely use first name and town as the accepted form of named public participation. Requiring more is the outlier.

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

Data collected at Tier 1 registration

Additional data at Tier 3 (Yoti verification)

Yoti returns a cryptographic assertion that identity verification has been completed against a government-issued document. We receive a unique verification token and the confirmed name. We do not receive, store, or process the underlying document. The document scan and biometric check happen entirely within Yoti's infrastructure. We are relying on their verification, not building our own.

Retention and deletion

Registration data is held while the platform is active or until you request deletion. You have the right to request deletion of your record at any time. Deletion removes you from the public counter and all aggregate counts immediately. Forum posts attributed to you are anonymised rather than deleted — the intellectual content of a challenge may be part of the public record of how a document changed, but your name is removed from it.

Storage and security

All data is held within the European Economic Area and processed in accordance with UK GDPR. The database uses encryption at rest as standard. Row-level security policies mean no data is ever exposed directly to the browser — all queries pass through server-side functions that return only the data appropriate for the requesting user's role and authentication state. Sensitive fields — email address and mobile number — are additionally encrypted at the column level within the database.

We use Supabase as our database infrastructure. Their security practices, certifications, and data processing agreements are publicly documented. We are not obscuring our infrastructure choices. We are naming them here so they can be scrutinised.

What we do not do

We do not sell data to any third party. We do not share registration data with any political party, campaign organisation, think tank, or commercial entity. We do not use registration data for advertising, profiling, or any purpose other than the platform functions described in this document. Individual records are never shared publicly. Only aggregate counts and geographic distributions are displayed.

6. What the Counter Shows and What It Does Not

The momentum counter displays the number of verified registrations. It is broken down by region and, where numbers are sufficient for anonymity, by constituency.

What the counter does show: How many real, verified people have decided this argument is worth standing behind publicly, in their own name.

What the counter does not show: How many people in Britain agree with the Generational Reset. Registrants are self-selected. People who find the site and choose to register are not a representative sample of the British public. We do not claim they are.

What the counter does not show: How many people support any specific policy proposal. Registering as a backer means supporting the project's approach — evidence-based, non-partisan, genuinely reform-oriented — not endorsing every proposal in every pillar.

7. How the Argument Pipeline Is Protected

The forum and challenge pipeline has its own defences against manipulation that operate independently of identity verification. Identity verification protects the signals. The editorial pipeline protects the arguments. Both are necessary. Neither is sufficient alone.

Structured submission forms. A challenge cannot be submitted as free prose. The form requires: the specific claim being challenged (identified by pillar and section), the specific evidence cited (source, publication date, and URL), and a precise statement of the proposed correction. Generating volume through this form with any claim to credibility requires genuine effort.

AI assessment. Every challenge that enters the formal pipeline is assessed by the AI layer before it reaches the editorial team. The assessment evaluates the evidence cited, checks it against the pillar argument, rates the challenge as strong, moderate, or weak, and checks precedent against prior submissions. The rating is not a gate — weak challenges are not automatically rejected, because the editorial team may disagree with the assessment. But a pattern of weak challenges, all targeting the same section, arriving in a short time window, is itself visible and informative.

Human editorial review. No challenge changes a document without a named human decision and a published reason. This gate cannot be bypassed. The AI does not have write access to pillar documents. No automated process does. Every change to any argument in the project has a human name attached to it.

Precedent tracking. The AI checks every new challenge against the history of previous submissions. A challenge that has already been assessed and rejected, resubmitted by a different account with the same argument and no new evidence, is flagged explicitly.

Anomaly detection. The platform monitors for patterns consistent with coordinated behaviour: multiple registrations from the same network in a short time window, multiple challenges against the same section in quick succession, accounts that register and immediately submit a challenge. These patterns do not trigger automatic action. They are surfaced to the editorial team as signals for investigation.

8. How to Scrutinise This

We have made a set of claims in this document about how the platform is built and what it does with data. You should be able to verify them.

Source code. The platform's source code is published on GitHub. The database schema, server-side functions, and AI assessment pipeline are publicly available. Anyone who wants to confirm that the platform does what this document says it does can read the code.

Editorial decision log. The log is public and updated in real time. Every challenge decision — accepted, rejected, or referred, with the named reason — is visible to all readers. If decisions show a pattern inconsistent with the stated editorial standards, that pattern is visible.

Update log. Every change to every document records what changed, which challenge prompted the review, and the name of the person who made the editorial decision. The provenance of every argument update is public.

This document itself. If you believe the platform is not doing what this document says — that the verification system is weaker than described, that data is being handled differently, that the editorial pipeline has a gap — the appropriate response is to log a challenge through the standard mechanism, citing the specific discrepancy and the evidence for it. The same evidentiary standard applies to challenges about the platform's own integrity as to challenges about its published arguments.

9. The Road to Government-Verified Identity

The strongest possible form of identity verification for a civic platform like this would be integration with the UK government's own digital identity infrastructure. We want to be explicit about our intent here, and honest about the current limitations.

What we are not referring to: Government Gateway — the login system used to access HMRC services — is a legacy authentication platform. It is being wound down and is not available for integration by external services.

What we are referring to: GOV.UK One Login is the UK government's new digital identity scheme, being rolled out to replace Government Gateway across all government services. Users verify their identity once — against a passport, driving licence, or HMRC records — and can then use that verified identity across integrated services. It is designed as a public infrastructure layer, not a private product.

At the time of writing, GOV.UK One Login is restricted to government services. Integration with private or civic platforms is not yet available. The programme has signalled intent to expand, but no timeline has been confirmed for non-government access.

Our intention, when integration becomes available, is to offer GOV.UK One Login as the identity verification method at Tier 3, either replacing or sitting alongside Yoti. This would represent the strongest available signal that a challenge submitter is a real, uniquely verified UK resident — verified against government records, not a commercial identity service.

We are logging this intent publicly so it can be held to account. When GOV.UK One Login becomes available to civic platforms, we will integrate it. If it does not become available, we will say so and explain why.

10. What This Costs

We are transparent about the cost of running this platform, because the no-corporate-funding commitment is load-bearing for the project's credibility. Readers should be able to assess whether the cost structure creates any dependency or pressure that could influence the platform's independence.

SMS verification is the primary variable cost — it scales directly with the number of new registrations. All other costs are either negligible or fixed at a low level. The total infrastructure cost to operate this platform is well within the range that can be sustained by the project without any commercial dependency.

We do not accept advertising. We do not accept corporate sponsorship. These costs are absorbed by the project. If that changes — if we ever accept external funding of any kind — it will be disclosed in this document immediately.