In many organisations, automation, AI adoption, process improvement, workforce planning, and learning operate as separate programmes. Each has its own data, vocabulary, prioritisation process, and dashboard. The result is predictable: duplicated analysis, inconsistent claims about impact, and limited visibility of what technology change means for people.

The answer is not one giant central system. It is a shared substrate: a governed catalogue of activities that connects how work is performed with the initiatives changing it.

At the base is the activity model: canonical activities, role mappings, time weights, skills, work context, and the evidence supporting each mapping. Above it sit assessments of automation potential, augmentation potential, risk, centrality, and expected change. On top of that sit the interventions: workflow automation, copilots, knowledge tools, redesigned operating procedures, learning pathways, and role changes.

This architecture gives each function what it needs.

Process and automation teams can trace a workflow step back to the activities and roles it affects. They can see whether a proposed automation removes a genuinely high-volume, low-judgment activity or merely shifts work into an exception queue.

Technology teams can identify where assistive AI should be embedded, what systems and data it requires, and what controls are appropriate.

HR and workforce planning teams can see which activities are changing across roles, where capacity may be freed, which skills require investment, and which populations need clear communication.

Executives gain a coherent portfolio view. Rather than seeing disconnected lists of AI pilots and automation projects, they can ask: Which activities are we changing? Through what intervention? For which roles? What value, risk, and skill implications follow?

The activity substrate also prevents a subtle but important error: double counting. A role should not receive separate productivity claims from an automation project, a copilot deployment, and a process-redesign initiative without understanding whether all three affect the same underlying activity. Mapping interventions to activities makes overlap visible.

Governance is essential. The model needs defined ownership, version control, source traceability, and a clear distinction between observed evidence, expert judgement, and modelled assumptions. It should be designed to improve as pilots generate real data.

This is not an argument to turn HR into a process-engineering function or to make technology teams wait for a perfect taxonomy. It is an argument for a shared language that lets each discipline act faster and with fewer contradictions.

Activities are where work, technology, capability, and value meet. A common activity substrate makes that intersection usable.

**Next article:** The final question is operational: how do leaders turn this model into a credible, augmentation-first Future of Work programme?