PID

Purpose of this document

This Project Initiation Document (PID) defines the Post Automation Utopia programme: what it is for, what it will deliver, how it will be governed and controlled, and who is responsible for what. It gives the Programme Board the basis for authorising the programme and, at each phase gate, for deciding whether to continue.

The PID follows the PRINCE2 structure, tailored for a programme that runs for decades and is delivered by many institutions (see Tailoring of PRINCE2). It is a draft. Phase 0 will complete and baseline it.

Project definition

Background

Automation and AI are taking on a growing share of tasks. The IMF estimates that almost 40 per cent of global employment is exposed to AI, and about 60 per cent in advanced economies (IMF, 2024). The programme assumes that automation will in time be able to perform substantially all paid tasks, at a pace no one can predict.

Left unmanaged, that change would remove the wage as most people's source of income while the returns go to the owners of automated capital. The world starts from a weak position: 3.8 billion people have no social protection (ILO, 2024), about 3.4 billion lack adequate housing (UN-Habitat, 2026) and seven of the nine planetary boundaries have been crossed (Stockholm Resilience Centre, no date). The Draft plan sets out the evidence and lists its sources.

Objectives

By the time the programme closes, in every adopting country:

Performance targets for the programme as a whole:

Desired outcomes

People no longer depend on employment for a decent life, and are free to choose how to spend their time. Automated production is safe and its returns are widely shared. Living standards in low-income countries reach the same floors as elsewhere. Ecosystems and the species in them are recovering.

Scope and exclusions

In scope:

• Economic security: an income floor, the automation dividend, tax reform and transition finance.
• Homes for everyone and universal basic services.
• Governance of automation and AI, including measurement, safety and accountability.
• Purpose, learning and participation.
• Planetary stewardship, including the representation of non-human users by proxies.
• Fairness between countries.
• Rights, law and legitimacy, including an international transition compact.
• Programme governance, assurance, engagement and document control.

Out of scope:

• Developing or operating automation technology. Industry does this, and the programme sets the conditions.
• Prescribing how people live or what they consume (UR-054).
• Preserving particular occupations as paid employment (UR-055).
• Military uses of automation and AI, which belong to international security processes.
• Decisions that belong to sovereign states. Countries choose whether and how to adopt the framework.

Constraints and assumptions

Constraints:

• Adoption is voluntary. The programme cannot direct governments.
• Human rights law and existing treaty commitments apply throughout.
• Planetary boundaries limit how every pillar is delivered.
• No sponsor or funding is confirmed (issue I-01).
• Delivery relies on institutions with their own mandates and timetables.

The RAIDD records 10 assumptions. The ones the programme depends on most are:

• Automation will in time be able to perform substantially all paid tasks, though the pace is uncertain (A-01).
• Productivity gains from automation are large enough to fund adequate floors once a share is captured (A-02).
• Enough states will join a coalition to make a compact viable (A-03).
• Human proxies can represent non-human users credibly enough for decisions to rest on their advice (A-05).
• Timelines and effort at v0.1 are indicative and relative. Nothing has been costed (A-09).

Tolerances

The Programme Director manages within these tolerances. A forecast breach goes to the Programme Board as an exception.

Users and other interested parties

The User Requirements Document defines thirteen user groups and their requirements. In summary:

Interfaces

• The Sustainable Development Goals and whatever follows them after 2030.
• The Kunming-Montreal Global Biodiversity Framework and the Paris Agreement.
• UN work on AI governance under the Pact for the Future and the Global Digital Compact.
• ILO standards on social protection and just transition.
• National social protection, housing, health and education systems.
• Existing basic income, guaranteed income and Housing First programmes, whose evidence the programme will use.

Project approach

The programme will:

• Work in phases, each authorised by the Programme Board at a gate.
• Pilot before scaling, with independent evaluation of every pilot.
• Set a common framework and leave delivery to national and local institutions.
• Build on existing institutions and commitments in preference to creating new organisations. This is proposed and is to be confirmed (decision D-10).
• Publish its evidence, data and decisions.
• Move phase dates in response to the pace of automation measured by the observatory.
• Treat the requirements of non-human users as constraints on design, with proxies to speak for them.

Business case

Reasons

If machines can do all paid work, wages stop being a workable way to distribute income, and the returns from production go to whoever owns the machines. No country has systems designed for that, and existing commitments on poverty, housing and nature are already behind. A planned transition can share the gains, protect people while work changes, and use the same period to restore the living world. An unplanned one leaves each of these to chance.

Options considered

Expected benefits

Expected dis-benefits

• Disruption to pension and benefit systems while they are migrated.
• Lower returns or higher taxes for owners of automated capital.
• Loss of the status and identity that people draw from their occupations.
• New administrative work for governments, especially where delivery systems are weak.
• Pressure on land from new housing.

Timescale

Five phases from January 2027, with closure indicatively in 2057. See Project plan.

Costs

The programme is not costed at v0.1. The Plan sizes effort relatively as Small, Medium, Large or Very large. Phase 0 needs a small programme team, commissioned research and a worldwide consultation. The cost of Phases 1 to 4 falls mostly on delivery institutions. It will be estimated in the financing strategy (P0-10) and the Phase 1 business case.

Investment appraisal

Deferred until Phase 0 has quantified the costs and benefits.

Major risks

The RAIDD holds 16 risks. The highest rated are: political mandate is not won or is lost; automation moves at a different pace from the scenarios; ownership of automated capital concentrates; inequality between countries widens; automation pushes ecological limits further; automated systems are unsafe or unaccountable.

Project management team structure

The table maps PRINCE2 roles to the programme's roles. The same role names are used in the Plan, the RAIDD and the RACI.

Role descriptions

The RACI shows responsibilities action by action. The roles are:

Quality management approach

The Benefits and Assurance Lead is accountable for quality. Every deliverable is checked against these criteria before the Programme Board accepts it:

• It rests on cited evidence.
• It traces to requirements: from the User Requirements Document, through the Solution Requirements Document, to the Plan.
• Its effects on equality and on future generations have been assessed.
• Its ecological effects have been assessed with advice from the relevant proxy panel.
• It is written in plain language and is available in accessible formats.
• The roles shown as consulted in the RACI have reviewed it.

Quality is checked by peer review, by independent evaluation of pilots, by proxy panel review and by independent assurance at each phase gate. The PMO Lead keeps the quality records, and the Control register lists the approved version of every document.

Change control approach

• Baselines. Documents are drafts while their version starts with 0. A version starting with 1 or higher is a baseline approved by the role named as approver in the Control register.
• Raising a change. Anyone may raise an issue or a request for change. The PMO Lead logs it in the RAIDD.
• Assessing it. The Design Authority Lead assesses the effect on requirements, plan, benefits and risks.
• Deciding. The Programme Director decides changes within tolerance. The Design Authority Lead decides changes to requirements and design within tolerance. Anything beyond tolerance goes to the Programme Board.
• Recording. The PMO Lead updates the affected documents and the Control register. Requirement IDs are never reused.

Risk management approach

Any role may identify a risk. Each risk is scored for likelihood and impact from 1 to 5, and the two are multiplied. A score of 15 or more is Red, 8 to 14 is Amber, and lower scores are Green. Each risk has one owner and a response: avoid, reduce, transfer, share, accept or prepare a contingency.

• The Programme Director is accountable for risk management, and the PMO Lead maintains the RAIDD.
• The RAIDD is reviewed monthly in Phase 0, quarterly afterwards, and at every phase gate.
• The Programme Board reviews every Red risk.
• Data from the automation observatory is used as an early warning. If measured displacement runs ahead of the scenarios, the Programme Board reviews the timing of the phases.

Communication management approach

Communication is open by default, runs in both directions, and uses people's own languages and accessible formats.

Benefits management approach

The Benefits and Assurance Lead owns the benefits map. Phase 0 will write a profile for each of the eight benefits, with a baseline, a measure, an owner and a target for each phase. Benefits are reviewed at every phase gate. Most are realised after the pilots, and many continue after closure, so the permanent stewardship institutions take over the tracking in Phase 4.

Sustainability approach

The requirements of non-human users in the User Requirements Document are treated as constraints on how every pillar is delivered. The programme sets a planetary footprint budget for automation infrastructure, takes advice from the proxy panels before any decision with an ecological impact, and applies the sustainability tolerance above. The Planetary Stewardship Lead reports against the budget at every phase gate.

Project plan

The Plan lists every step with timing, effort, owner and dependencies. The phases are:

Key milestones, with indicative dates:

Project controls

• Phase gates. The Programme Board authorises each phase after an end-phase report and an independent assurance review.
• Highlight reports. From the Programme Director to the Programme Board, monthly in Phase 0 and quarterly afterwards.
• Checkpoint reports. From each workstream lead to the Programme Director, monthly.
• Exception reports. Raised by the Programme Director as soon as a tolerance is forecast to be exceeded.
• Logs and registers. The RAIDD for risks, assumptions, issues, decisions and dependencies. The Control register for documents. A quality register and a lessons log kept by the PMO Lead.
• Reviews. Independent assurance at each gate, and a mid-programme review in 2040.

Tailoring of PRINCE2

• The project is a programme of many projects. Its phases act as management stages, and each workstream project inside a phase would have its own lighter PID.
• Phase 0 combines initiation with the first delivery stage, because finishing the plan is the first deliverable.
• The user side of the Programme Board includes proxies for non-human users and a voice for future generations.
• The business case uses relative sizing until Phase 1.
• A single RAIDD replaces the separate risk register, issue register and daily log, and adds decisions and dependencies.
• Sustainability is a seventh performance target, as in the seventh edition of PRINCE2.
• Sovereign institutions deliver most of the later phases. The programme sets standards and coordinates, so accountability for those steps sits with types of institution in the RACI.

Related documents

The programme documents are listed below. The Control register holds the current version and link for each.