Independent Research & Analysis · For Academic Purpose

AI WorkShift Australia

This document explains how AI WorkShift Australia was built on research and analysis of publicly available government data. It is organised into seven parts: the first two map out the application itself — its features and the lifecycle through which it was developed. The middle parts open up the research engine: how each occupation was scored for its exposure to artificial intelligence, where the underlying data came from, and how the scoring scale was kept consistent. The final parts explain why the approach is methodologically defensible, how the work is kept up to date, and how the website itself is designed and orchestrated behind the scenes.

Part 1 — Application Feature Tree

A feature tree is a map of an application's capabilities, branching from the whole application down to its individual features. It helps anyone — an engineer, a stakeholder, or a curious user — see at a glance what the application can do and how its parts relate.

The AI WorkShift Australia dashboard organises into four main branches: the Data Layer that supplies information, the Visualisation that turns numbers into a picture, the Interaction tools that let users explore, and the Transparency features that keep the research traceable.

1.1 Reading the Tree

The Data Layer is the foundation. When the page opens, it first tries to pull the latest figures from a connected Google Sheet; if that is unavailable, it quietly falls back to a built-in copy of the data so the dashboard never appears broken or empty.

The Visualisation branch is what the user actually sees. It takes each occupation and places it on a chart according to its AI risk and salary, sizes it according to how many people work in it, and colours it according to its industry. Four pieces of information become visible in a single glance.

The Interaction branch hands control to the user. Filters for state and sector, a search box, hover tooltips, and click-to-open detail cards let a person move from the big picture down to a single occupation that matters to them personally.

The Transparency branch is what separates a credible research tool from a black box. Every score carries a short written explanation, the data sources are named and linked, and the scoring method itself is available on hover. Nothing about how a number was reached is hidden from the user.

Part 2 — Software Development Lifecycle

This project followed an iterative lifecycle, illustrated below.

2.1 The Seven Phases

• Requirements — the goal was an accessible, Australia-focused map of AI disruption risk.
• Data and Research — official statistics were gathered from the ABS and JSA, and the original AI scoring framework was designed and applied.
• Design — a clean visual system was developed: the colours, typography, layout, and the way users would interact with the chart.
• Build — the dashboard was coded in HTML, CSS, and JavaScript, with the D3.js library powering the interactive chart.
• Test and Validate — the scores were checked for consistency, the filters and tooltips were tested, and the data was verified against its sources.
• Deploy — the finished dashboard was prepared for publication on a static web host, making it publicly accessible.
• Maintain — because data and AI both change over time, the project returns each year to refresh figures and revisit scores, then cycles through testing and deployment again.

Part 3 — The Scoring Methodology

This is the analytical core of the project.

3.1 The Six-Factor Framework

Each occupation is assessed against six questions. Three tend to raise an occupation's exposure to AI, and three tend to lower it. The balance of answers determines where the occupation lands on a scale from 0 to 10.

The framework deliberately blends two perspectives. The first three factors ask what AI is good at — working with digital outputs, processing data and text, and tasks where displacement is already visible in the real world. The remaining three ask what protects human work — the need for physical presence, the importance of human trust and relationships, and legal requirements that a qualified person perform the role. This balance prevents the scores from simply tracking how "technical" a job sounds, and instead grounds them in the genuine barriers and vulnerabilities of each occupation.

3.2 The Conceptual Foundation

The framework is not invented in a vacuum. It draws on a well-established line of academic thinking about automation and work. The pioneering study by Frey and Osborne (2013) estimated the susceptibility of hundreds of occupations to computerisation and, although its headline figures were later debated, it established the idea of scoring occupations for automation risk. Arntz, Gregory, and Zierahn (2016) refined this thinking by arguing that risk should be assessed at the level of individual tasks rather than whole job titles — a principle directly reflected in this framework's focus on what an occupation actually involves day to day. Acemoglu and Restrepo (2019) added the crucial insight that technology both displaces and complements human labour, which is why this framework weighs protective factors alongside exposing ones rather than assuming AI simply replaces people.

3.3 Worked Examples

Example A — Bricklayer (Score: 1). A bricklayer produces a physical structure, must be present on a building site, relies on manual dexterity adapting to unique conditions, and works under safety regulation. There is no meaningful real-world displacement of bricklayers by AI. Five of the six factors push the score firmly downward, producing a score of 1 — minimal exposure.

Example B — Data Scientist (Score: 9). A data scientist produces entirely digital outputs, can work fully remotely, performs work that is fundamentally about data and patterns, faces no regulatory barrier requiring a human, and operates in a field where AI tools are already absorbing routine analytical tasks. Almost every factor pushes the score upward, producing a score of 9 — very high exposure.

Part 4 — How the Data Was Collected and Calculated

Four of the five numbers attached to each occupation come straight from official Australian government sources.

4.1 The Data Sources

Variable	Government Source	How It Was Obtained
Occupation and tasks	ABS — ANZSCO classification	Downloaded the official occupation list and task descriptions
Median annual salary	ABS — Employee Earnings	Took the median weekly figure and multiplied by 52
Employment count	ABS — Labour Force Survey	Recorded the number employed, expressed in thousands
5-year growth	JSA — Employment Projections	Recorded the projected percentage change over five years
Skills shortage	JSA — Skills Priority List	Cross-checked which roles are in national shortage
AI exposure score	Independent (Atiar Khan)	Applied the six-factor framework to each occupation

4.2 A Worked Calculation

Take the example of a software developer. The ABS Employee Earnings release reports a median weekly wage; multiplying that weekly figure by 52 produces an annual salary of roughly $125,000, which becomes the occupation's vertical position on the chart. The ABS Labour Force Survey indicates approximately 180,000 people work in the role, which sets the size of its bubble. Jobs and Skills Australia projects around 15 percent growth over five years, which appears in the occupation's detail card. Finally, the six-factor framework yields an AI exposure score of 8, which sets its horizontal position. Four official numbers and one researched judgement combine into a single point on the map.

4.3 Why These Sources

The Australian Bureau of Statistics and Jobs and Skills Australia were chosen because they are the authoritative, publicly accessible, and regularly updated sources for Australian labour market data. Using official statistics rather than commercial estimates means the salary, employment, and growth figures can be independently verified by anyone, and that the dashboard rests on the same evidence base used by policymakers and economists.

Part 5 — Calibration Anchors

A scoring scale is only meaningful if it is applied consistently. Without reference points, one occupation might be scored a 6 on a generous day and a 4 on a strict one. To prevent this kind of drift, a set of calibration anchors was established before the bulk of scoring began. These are occupations whose level of AI exposure is either well established or logically clear, and they act as fixed signposts along the scale.

5.1 The Anchor Points

Score Band	Risk Level	Anchor Occupations
0–2	Minimal	Bricklayer, Café / Service Worker, Aged Care Worker, Early Childhood Educator
3–4	Low	Registered Nurse, FIFO Operator, General Practitioner, Primary School Teacher
5–6	Moderate	Pharmacist, Civil Engineer, HR Manager, Environmental Scientist
7–8	High	Accountant, Solicitor, Graphic Designer, Investment Analyst
9–10	Very High	Data Scientist, Paralegal — core tasks already substantially AI-native

Part 6 — Why This Method Is Defensible

Any independent scoring system invites a fair question: why should anyone trust these numbers? The honest answer is that the scores are estimates, not certainties — but they are estimates produced through a method designed to be transparent, grounded, and resistant to bias.

• Transparency — every score is accompanied by a written, plain-language rationale, so users can judge the reasoning for themselves rather than taking a number on faith.
• Grounding in real tasks — scores are based on the official ANZSCO description of what each occupation actually does, not on prestige or job title alone.
• Balanced factors — by weighing protective factors (physical, relational, regulatory) against exposing ones, the method avoids the common error of assuming any cognitively demanding job is automatically safe or unsafe.

It is equally important to be clear about what the method does not claim. It measures exposure — the susceptibility of an occupation's tasks to AI — not a proven prediction that specific jobs will disappear. Distinguishing exposure from outcome is a well-recognised necessity in this literature, because actual employment change is shaped by economics, regulation, and human choices as much as by technical capability (Arntz et al., 2016; Acemoglu and Restrepo, 2019).

6.1 Acknowledged Limitations

• The scores reflect the capabilities of AI as at 2024–25 and will need revision as the technology advances.
• The 72 occupations are a purposive selection for coverage and clarity, not a random statistical sample of the entire workforce.

6.2 Maintaining and Updating the Research

Because the subject matter changes, the dashboard is built to be refreshed rather than frozen. A practical annual cycle keeps it current:

• Each May/June, when the ABS releases updated Employee Earnings, refresh the salary figures.
• Periodically check the ABS Labour Force Survey and update employment counts where they have shifted materially.
• Each October/November, when Jobs and Skills Australia updates its projections, refresh the growth figures.
• At least once a year, review the AI exposure scores against recent developments and adjust any that the evidence no longer supports.
• Update the data — either directly in the connected Google Sheet, which the dashboard reads automatically, or in the built-in dataset — and republish.

Part 7 — Backend & Orchestration

7.1 Technical Information

• Structure (HTML): defines the layout, including the chart container, filter controls, tooltip, and detail card components.
• Presentation (CSS): manages visual styling such as colour schemes, spacing, typography, and transition effects for interactive state changes.
• Application Logic (JavaScript with D3.js): handles data ingestion, transformation, and rendering. It computes bubble positions and radii, binds data to SVG elements, and manages event-driven interactions including click, hover, and dynamic filtering.
• Data Integration and Fallback Handling: implements a fault-tolerant data loading mechanism — the application attempts to retrieve live data, and falls back to a built-in dataset if needed.

When a user applies a filter — for example, selecting Victoria — the application does not reload or redraw the entire chart. Instead, it efficiently fades out the bubbles that do not match and disables them from interaction, while recalculating the summary statistics at the top of the page.

7.2 Hosting

The application is implemented as a single static asset, enabling deployment across standard static hosting platforms such as Netlify, GitHub Pages, and Cloudflare Pages.

References