The Redesigned Role Specification

COMPEL Specialization — AITE-WCT: AI Workforce Transformation Expert Article 25 of 35

A redesigned role specification is the operative artefact of role redesign. It is the document HR uses to post, hire, onboard, and evaluate; the document the manager uses to set expectations and coach; the document the incumbent uses to know what is expected; and in many jurisdictions, the document the works council (Article 27) reviews and consults on. Its quality determines whether the redesign lands or whether the organisation carries forward ambiguity that resurfaces as performance disputes, union escalations, or quiet attrition.

Most role specifications fail at one of two extremes. At one end, they are generic documents repurposed with AI references sprinkled in, producing a role that reads plausibly but does not describe the work. At the other end, they are over-specified — listing every tool, every metric, every scenario — producing a role that is brittle, that requires reissue every time a tool changes, and that overconstrains the person doing the work. The disciplined specification sits between: specific enough to be actionable, general enough to survive the normal evolution of the work.

This article teaches the structure of a specification that has worked across multiple AI-role redesigns the expert community has reviewed. It is the direct output of Article 24’s task decomposition and the direct input to Articles 27 (works-council engagement), 28 (manager enablement), and 29 (performance evaluation).

The structural sections

A redesigned role specification has ten sections. Each is necessary; none overlaps another.

Section 1 — Role title and identity

The title is the first signal. A redesigned role carries a new title, or the prior title with visible modification, to mark the change. A title that changes signals to everyone — incumbent, manager, colleagues, external stakeholders — that something meaningful has shifted. A title unchanged signals the opposite and undermines the Bridges-phase commitment work (Article 21).

Role identity is the one-paragraph statement of what this person does, why it matters, and how the work connects to the organisation’s purpose. It is the artefact the incumbent quotes when someone asks “what do you do” and the artefact that anchors the role against drift.

Section 2 — Core responsibilities

Five to seven core responsibilities, each expressed as an outcome the person is accountable for. Not tasks (the tasks feed into Section 5) — responsibilities describe the level at which the person is accountable. “Ensure commercial underwriting decisions meet quality and timeliness standards” is a responsibility; “draft underwriting memos” is a task.

The discipline at this section is to describe responsibility rather than activity. A specification full of activities reads as a process manual; one that describes responsibilities reads as a role. The manager and the incumbent jointly own the responsibilities; the tasks that implement them evolve.

Section 3 — AI touchpoints

This is the section most redesigned roles either omit or handle badly. AI touchpoints are specific: which AI systems the role uses, for which tasks, with what decision authority. The section names the touchpoints rather than describing a generic “AI-augmented way of working.”

The format is a short table: system name (or capability category if the system is not yet selected), the tasks it is used for, the decision authority the incumbent has over the AI output (draft / review / approve / override), the review cadence for the AI’s quality, and the escalation path when the AI produces anomalous or low-confidence output.

The specificity matters because ambiguity about AI authority is the most common source of role conflict. An underwriter who is unclear whether they can override an AI-generated recommendation, and under what conditions, will either override too freely (undermining the AI) or too rarely (undermining their own professional judgment). The specification must resolve this at design time, not leave it to emergent practice.

Section 4 — Skills and capabilities

The skills the role requires, structured as must-have, strong-preference, and developable. Skills include both the technical and the interpersonal; the AI touchpoints in Section 3 generate specific skill requirements that are named here.

The section also references the role’s required literacy level (from the role-to-level map, Article 16) and any sector-specific certifications the role requires.

The discipline: the skills section describes the role, not the ideal candidate. A specification that lists every possible desirable skill produces a role that nobody satisfies and that — in jurisdictions with equal-opportunity requirements — may show disparate impact against groups who decline to apply to impossible-looking jobs.

Section 5 — Task composition

The task-level view from Article 24’s decomposition, at summary level. The summary shows the rough time allocation across major task clusters and the AI exposure / augmentation / human-centricity classification of each cluster.

The section is not a comprehensive task list. It is the task-composition summary that makes the role visible at a glance. Detailed task lists — if required — are linked appendices.

Section 6 — Performance expectations

The outcomes the role is accountable for delivering, with evidence types. Not metrics (metrics can change with system changes); outcomes (which are more stable). “Underwriting decision turnaround is within service-level agreement”; evidence type: system-reported turnaround data and sample quality review.

The discipline: performance expectations are what the role delivers, not what the incumbent does. Expectations expressed as activities produce performance-theatre; expectations expressed as outcomes produce work.

The section also describes the AI-output-versus-human-contribution attribution approach that Article 29 develops in detail. A specification that does not address attribution hands the problem to each manager-incumbent pair to solve privately, producing inconsistent practice and disputes.

Section 7 — Reporting, collaboration, and authority

Who the role reports to, who reports to the role, who the role collaborates with regularly, what decisions the role is authorised to make, what decisions are escalated, and the typical cadences. An AI-augmented role often has different authority than its predecessor — the incumbent may be approving AI-generated decisions that a prior role drafted manually; the locus of approval has shifted.

The specification makes the shift explicit. Ambiguity here is expensive.

Section 8 — Growth and career path

How the role develops over time; what the next roles are; what learning and experience the incumbent builds. AI-augmented roles that read as “terminal” positions — no visible growth, no next role — attract early attrition and low engagement.

The section names two or three realistic next roles and the development experience the current role provides. Where the current role is a genuine terminal position, the section says so honestly and compensates (e.g., via visibility, mentorship authority, or professional-community leadership) rather than pretending to a career path that does not exist.

Section 9 — Transition plan (for redesigned roles only)

For a role created by redesign of a prior role, the specification includes a transition plan section. The plan names: the incumbent’s prior role; what continues, what ends, what is new; the timeline of the transition (typically 60–180 days); the training and support provided; the decision point at which the transition is complete.

The transition plan is a Bridges-shaped artefact (Article 21): it names the ending, the neutral zone, and the new beginning. For new hires into an already-redesigned role, Section 9 is omitted.

Section 10 — Governance and review

Who owns the specification; when it is reviewed; what triggers an out-of-cycle review; how changes are approved and communicated. An AI-touching role’s specification is a living document — tool changes, policy changes, AI-system changes will update Sections 3, 5, and 6 over time. The governance section ensures the updates happen in the right forum with the right approvers.

The standing review cadence is typically annual, with out-of-cycle triggers for: a material AI-system change, a regulatory change affecting the role, an incident implicating the role, a works-council consultation conclusion that requires revision.

Quality test — the three-reader rule

A specification is ready when three readers can use it for their separate purposes without consulting the author.

• The HR practitioner reads Sections 1, 2, 4, 6, 7, and 10 and can hire, level, and evaluate the role.
• The hiring manager reads Sections 1, 2, 3, 4, 5, 6, 7, 8, and 9 and can recruit, onboard, and coach the role.
• The incumbent (or candidate) reads the whole document and can describe their role back accurately in their own words.

If any of the three readers needs a private conversation with the author to understand their section, the specification is incomplete for that reader’s purpose. The author’s job is to close each gap until the three-reader rule passes.

The works-council readability requirement

In jurisdictions with works-council consultation requirements (Article 27), the specification must additionally be readable by non-specialist council members. The readability requirement is tested by having a council member (or a proxy: a colleague unfamiliar with the role) read the document and produce a plain-language summary. Summaries that match the author’s intent indicate readability; summaries that wander indicate that the document requires translation.

Common readability failures: jargon in Section 3 (AI capability terminology that council members do not share); over-technical performance metrics in Section 6; abstract language in Section 9 about transition that does not name the concrete support the incumbent will receive. Each is correctable; the iteration cost pays back in consultation efficiency and reduced dispute surface.

The versioning discipline

A redesigned role specification that lasts through the AI-system changes and policy evolution of a three-year transition will have multiple versions. Version 1.0 is issued at redesign; 1.1 incorporates early corrections from the first cohort’s experience; 2.0 reflects the first major AI-system change; 3.0 reflects regulatory or organisational change.

Every version is dated, changed-bys, and approved. The approval body is usually the Head of Function × HR × (where applicable) the works council. Incumbents are notified of material changes and, where appropriate, re-briefed. A specification that is updated silently without incumbent notification produces confusion and undermines trust.

Two real-world anchors

Published enterprise role-redesign cases

Multiple public sources — reputable press, company disclosures, and industry-association publications — document recent AI-era role redesigns with structural elements corresponding to the ten sections above. The pattern is not universal: some published cases emphasise the tool and neglect the authority chain (Section 3); others describe the activities in depth and miss the performance expectations (Section 6); others handle the work well but omit the transition plan (Section 9). The expert reviewing the public record can see, across the cases, that the specifications that travel well — land with their populations, withstand works-council scrutiny, survive into the sustainment phase — share the structural completeness described here. (Citations: reputable press reporting on financial-services, professional-services, and healthcare AI role redesigns 2023–2025, referenced through the AI Incident Database’s governance-outcomes tagged entries and through sector publications.)

UK Civil Service role-profile standards

The UK Civil Service Success Profiles framework, introduced in 2018 and documented at gov.uk, provides a mature public-sector role-profile standard that AI-era redesigns can reference. The framework’s structure — behaviours, strengths, experience, ability, technical skills — maps usefully onto the sections above, and the public-availability of examples provides a reference point for the expert’s own specification work. Source: https://www.gov.uk/government/publications/success-profiles.

The lesson: role-profile discipline is not a new invention; public-sector HR has practised it at scale, and the AI-redesign adaptation builds on an established base. Experts who think role-profile work is a blank sheet underestimate the available reference material and often reinvent structures that already exist in more robust form.

Learning outcomes — confirm

A learner completing this article should be able to:

• Name the ten structural sections of a complete redesigned role specification.
• Distinguish responsibility from activity in Section 2, and outcome from metric in Section 6.
• Structure Section 3 (AI touchpoints) with system, tasks, decision authority, review cadence, and escalation path.
• Apply the three-reader test to a draft specification.
• Adapt a specification for works-council readability.
• Govern specification versioning across a multi-year role evolution.

Cross-references

• EATF-Level-1/M1.6-Art08-Workforce-Redesign-and-Human-AI-Collaboration.md — Core Stream workforce-redesign anchor.
• Article 4 of this credential — role exposure (input to Section 5).
• Article 5 of this credential — skills adjacency (input to Section 4).
• Article 21 of this credential — Bridges transitions (shapes Section 9).
• Article 24 of this credential — task decomposition (produces Section 5’s summary).
• Article 27 of this credential — works-council engagement (tests readability).
• Article 28 of this credential — manager enablement (consumes the specification).
• Article 29 of this credential — performance evaluation (operationalises Section 6).

Diagrams

• StageGateFlow — ten-section specification sequence with input artefacts per section.
• HubSpokeDiagram — role specification at hub; HR, hiring manager, incumbent, works council as spokes with readability requirements per spoke.

Quality rubric — self-assessment