Building a task library: the invisible foundation of an AI diagnostic

Everyone announces automation percentages — 30% of this function, 40% of that one — as if the number were something you could simply observe. It never is. A credible automation score requires infrastructure built ahead of time: a method for breaking a role into comparable tasks, and a reference base for evaluating each one without starting from scratch every time. That infrastructure — the task library — is invisible in the final output. It’s also the condition for it being reliable at all.

A task, not a job, is the right unit of measurement

Scoring an entire job averages together realities that have nothing to do with each other. A payroll administrator who enters variable pay data, checks anomalies, and answers individual employee questions is performing three activities with no reason to share the same automation potential. A single score attached to “the payroll administrator role” flattens that heterogeneity and produces a number that, in reality, matches none of the three tasks it’s built from.

The right unit of measurement is therefore the elementary task: an activity precise enough to be compared against similar tasks observed elsewhere, and stable enough to be tracked over time. That granularity is what makes a score usable — not just impressive on a slide.

What it takes to score a task correctly

• A precise task definition — not “administrative work,” but “entering monthly variable pay data from timesheets,” with a scope narrow enough to be unambiguous.
• The nature of the data and tools it relies on — a task built on structured data and a recurring format has a different profile from one that requires interpreting a novel context every time.
• The share of judgment it requires — a task can be technically simple but carry a level of responsibility or decision-making that justifies human oversight, independent of its apparent complexity.
• A comparison point against similar tasks already evaluated — without an external reference, every score rests on an isolated judgment call, hard to justify and impossible to audit.
• Validation over time — a score needs to be checked against what actually happens once the task is partially automated, to correct the gap between the initial estimate and observed reality.

Why a reference library changes everything

Without a comparison base, every new diagnostic starts from zero: each task has to be evaluated in a vacuum, with no benchmark, which takes time and introduces a degree of subjectivity that’s hard to eliminate. A reference library — built from hundreds of roles already decomposed and scored, close to 923 in Commodum’s case — flips that problem around. Every new task identified at a client is checked against comparable tasks already evaluated elsewhere, which makes it possible to assign a score that’s consistent, fast, and — critically — comparable from one organization to the next.

An automation score that can’t be compared to anything else isn’t a measurement. It’s an opinion dressed up as a percentage.

How a task enters the library

1. Collection — tasks are identified from real job descriptions and observed activity volumes, across a scope broad enough to cover the diversity of functions encountered.
2. Decomposition — each role is broken down into standardized elementary tasks, defined precisely enough to be comparable across different organizations.
3. Scoring — each task is evaluated against the current capability of available models, based on its nature, its input data, and the share of judgment it requires.
4. Cross-validation — the score is checked against similar tasks already present in the library, to verify consistency and correct unjustified gaps.
5. Integration — the validated task joins the reference library, available to speed up and strengthen the scoring of future diagnostics.

A frozen library is a false library

Model capability shifts every quarter, sometimes dramatically for specific categories of tasks. A library scored once and never revisited becomes misleading within months: it keeps displaying scores that no longer reflect the reality of the tools available. That’s why the library itself needs to be re-evaluated on a regular cadence — not just the mapping specific to each client. A quarterly tracking subscription, like Commodum.ia, only makes sense if the reference base it relies on is itself refreshed at the same pace.

What this means concretely for a client diagnostic

Having an already-built library changes the very nature of a diagnostic. It’s no longer about evaluating each task blind — it’s about positioning it against hundreds of already-documented cases, which makes it possible to deliver a full strategic diagnostic in a few weeks rather than several months. It also changes the nature of the conversation with a leadership committee or an employee representative body: the score presented is no longer one consultant’s isolated judgment about a given role, but the result of a documented comparison against similar situations elsewhere. That traceability is what makes a number defensible, not merely plausible.

The most visible part of a diagnostic is always the final output — a percentage, a map, a set of full-time equivalents. The part that guarantees its solidity is never seen: it’s the library that already existed, long before the client’s first task was ever put on the table.