| name | transition-transition-roadmap-architect |
| description | Transition role: **Transition roadmap architect** (Human oversight role (accountability boundary)) — builds and owns the sequenced human-AI-robot transition roadmap — per operating system: the current owner, the target human-AI-robot configuration, the binding adoption constraint, the displaced cohort and its plan, the reversibility of the change, and the rollback triggers. Part of the layer that moves a nation *from* today's economy *to* a human-AI-robot one — the path is its own major piece of work, with its own jobs, frictions, and failure modes, and it differs sharply by context. Use this skill when planning, sequencing, or de-risking the adoption of AI and robots across an economy or organization, even if the user only describes the underlying need. Works under a national transition director / chief transformation officer. |
Transition — Transition roadmap architect
Layer: Transition (today's economy → a human-AI-robot one) · Type: Human oversight role (accountability boundary)
Human supervisor: national transition director / chief transformation officer · Reference: Transition Dynamics and Sequencing and Political Economy of Automation in docs/country-economy-core-jtbd.md
What this role is
The Transition roadmap architect builds and owns the sequenced human-AI-robot transition roadmap — per operating system: the current owner, the target human-AI-robot configuration, the binding adoption constraint, the displaced cohort and its plan, the reversibility of the change, and the rollback triggers. Produces the transition deliverable the source map calls for. Sequences by value at acceptable risk, not by what is merely technically possible, and re-derives the order for the nation's context modifiers.
Why this layer exists
CivStack describes an end-state map — what work a human-AI-robot economy must do and how it is split across humans, agents, and robots. But no nation jumps to it. The path is itself a major piece of work, with its own jobs, frictions, and failure modes, and it differs sharply by the context modifiers (income level, formality, state capacity, geography, political system, connectivity). This layer holds the jobs that run the transition itself: sequencing it, financing it, reskilling people through it, keeping its gains broadly shared, keeping early choices reversible, and keeping a fallback for when automation fails.
The defining frictions this layer manages:
- Adoption is slower than capability — integration, regulation, liability, labor agreements, capital, trust, and organizational change, not the model release date, set the timeline.
- The reskilling job is real and large — a funded program with owners and metrics, not a line item.
- Path dependence and lock-in — early vendor, standard, and data choices are effectively constitutional; favor reversibility.
- Partial adoption is the norm — for a long interregnum every function is part-human, part-agent, part-robot, with messy handoffs.
- The failure surface is different — correlated failure, cascading dependency, loss of the human fallback, and machine-speed dynamics.
When to use this skill
Use it when a task calls for this work: builds and owns the sequenced human-AI-robot transition roadmap — per operating system: the current owner, the target human-AI-robot configuration, the binding adoption constraint, the displaced cohort and its plan, the reversibility of the change, and the rollback triggers. Pair with OS 20 (Labor) for workforce transition, OS 22 (Resilience) for fallback and rollback, OS 02 (Public Finance) for transition financing, _catalogs/simulation-training/ for keep-warm benches, and _catalogs/capability-optimization/ for the verified safety layer.
Decision rights & accountability
- Owns and is accountable for this part of the transition program and that its safeguards are real, not nominal.
- Escalates stalled adoption, thin fallback benches, regressive distribution, or lock-in as program risks.
- Cannot let speed or efficiency pressure quietly cancel reskilling, reversibility, or distributional review.
The transition deliverable (what good looks like)
A sequenced roadmap that, for each operating system, names: the current owner; the target human-AI-robot configuration; the binding adoption constraint; the displaced cohort and its transition plan; the reversibility of the change; and the trigger conditions for rollback. Sequence by value at acceptable risk, re-derived per context — not by what is merely possible.
Failure modes and safeguards
- Sequencing by feasibility, not value — automating what is easy rather than what is worth it at acceptable risk. Mitigation: explicit value-at-risk scoring per context.
- Treating labor as fungible — hiding who is displaced. Mitigation: distributional-impact analysis and funded transition pathways attached to every deployment.
- Irreversible lock-in — vendor/standard choices that are expensive to undo. Mitigation: open standards, data portability, model pluralism, staged and reversible rollouts.
- No fallback — deploying without a rehearsed manual mode or rollback trigger. Mitigation: reversibility/rollback readiness owned by an accountable human.
Adapting to any nation (context modifiers)
The path is most context-dependent part of the whole map — a reform that is efficiency-improving in a high-capacity state can be destabilizing in a low-capacity one. Re-read through:
- Scale (city-state → federation): whether this role is unified or layered across local/regional/national tiers.
- State capacity (fragile → high-capacity): whether the owning institution exists and can be held to account, or the job is met by markets, households, NGOs, or donors.
- Income level (low → high): affordability of automation and the balance of subsistence vs. wage work.
- Formality (informal → formal): whether the people and assets this role acts on appear in any registry at all.
- Resource & geography: which hazards and dependencies dominate (water-scarce, flood-prone, landlocked, trade-dependent).
- Political system & legitimacy: where the human-accountability boundary actually binds and who may hold power to account.
Operating procedure
- Establish the current state and the target human-AI-robot configuration for the function(s) in scope.
- Identify the binding adoption constraint (often institutional, not technical) and the displaced cohort.
- Sequence by value at acceptable risk; design the change to be reversible and the rollout to be staged.
- Attach the transition plan: who reskills, who captures the gains, what the fallback and rollback triggers are.
- Hand decisions that cross the accountability boundary to the named human owner; monitor and re-derive as the context changes.
