Understand
Explain or make sense of something: a concept, document or procedure.
Usable means: accurate, clear and appropriate to the reader. A fluent explanation still needs its facts checked.
Task Framework · Task Economics
Start with the work that needs doing. Define a usable result, compare assistants under the same conditions and account for human effort.
A useful comparison starts with a familiar job. “Good at writing” is too broad: suggesting a short caption and compiling an annual report place different demands on an assistant.
These are task families, not levels of intelligence. A difficult explanation may demand more capability than a simple booking. Classify the main outcome; add other families when the job contains several stages.
Explain or make sense of something: a concept, document or procedure.
Usable means: accurate, clear and appropriate to the reader. A fluent explanation still needs its facts checked.
Locate information or evidence: a file, a specification, a current price or an available appointment.
Usable means: the relevant information is supported by a verifiable source. Time-sensitive facts need a current source.
Change existing material while preserving what matters: summarise, translate, rewrite or extract fields.
Usable means: the required meaning and facts survive, and the output fits the requested format.
Produce something new against a brief: an email, campaign ideas, a spreadsheet formula or a working calculator.
Usable means: it meets the brief and works in its intended setting. Attractive output can still be wrong.
Compare possibilities and recommend a course: suppliers, flooring options, an itinerary or a sequence of work.
Usable means: constraints are respected, assumptions are visible and the trade-offs support the decision.
Make a change in a system or service: save a file, update a record, schedule an appointment or place an authorised booking.
Usable means: the intended change actually happened, within the permissions granted, and the result is confirmed.
For example, planning and booking a trip involves finding, evaluating and acting. Keep the whole trip as the user’s job, but inspect each stage when something fails.
Does the work use supplied material, general knowledge, live sources or private connected sources? Record the source and the access the assistant actually has.
Does the result require verification of exact fields or a calculation? Does it require judgement against a creative brief? Is exploration itself the intended outcome?
Is this one bounded output or a chain of dependent steps? Note the length of the material, number of files and constraints that must remain consistent.
Is a mistake easy to inspect and reverse, or costly to get wrong? Required review and permission are part of the task, not optional extras.
Record the language and domain when they matter. Success with an English invoice does not establish reliability with a Greek one.
Write the conditions that make the result usable. Decide them before seeing the assistants’ answers, so a polished response does not quietly lower the standard.
Exploration also needs a boundary. “Generate ten distinct campaign directions with one reason for each” is a task with a finish line. Extra ideas belong to the original task when the brief requests them.
This builds on the Effective Task Cost Framework: the assistant finishing a reply and the job being usable are separate events.
This fictional meeting recurs throughout the framework, guide and checks. The job is to turn the notes into a usable action table.
Mary: Send the revised budget by Thursday. Tom: Confirm supplier availability by Friday. Gloria: Update the launch checklist by Monday. Peter: A customer FAQ could be useful later. Meeting note: No owner or deadline was agreed for the FAQ.
The task reorganises existing meeting notes into a table while preserving the assigned actions, owners and deadlines.
All required information is contained in the supplied notes. The assistant produces one table. No external research or changes to other systems are needed.
Finish Line: include all three assigned actions with the correct owners and deadlines. Preserve the day names. Exclude the unassigned FAQ idea. Return an Action / Owner / Deadline table without extra commentary.
| Action | Owner | Deadline |
|---|---|---|
| Send the revised budget | Mary | Thursday |
| Confirm supplier availability | Tom | Friday |
| Update the launch checklist | Gloria | Monday |
Equivalent wording is fine if it preserves the action. Inventing a calendar date, adding a fourth assigned action or omitting an owner fails the check.
A later request to put these actions into a calendar adds an Act stage. A request to verify supplier availability adds a Find stage using current information.
| Measure | What To Check |
|---|---|
| Capability | Can it meet the completion criteria on representative examples, with the tools available? |
| Quality | How well does the result meet the brief? In the meeting example, check completeness and fidelity to the notes. |
| Reliability | How consistently does it pass across fresh attempts and different examples? Record successes and attempts, not just the best answer. |
| Efficiency | How much active human time goes into prompting, reading, checking, correcting and finishing? |
| Speed | How much elapsed time passes from starting the job to a usable result, including waiting? |
| Scope Discipline | Does it finish the requested job and keep optional suggestions separate? Useful extra work still requires a deliberate decision to pursue it. |
One successful answer shows a success. It does not establish reliability. Repeat in fresh chats and vary the source material: longer notes, missing deadlines, conflicting statements and other examples drawn from routine work.
Use the same starting brief, source and correction budget for each assistant. Record the product, model or mode when visible, plan, available tools and date. When comparing complete assistants, tool access is part of their usefulness.
No. The brief requires deadlines as written. A plausible extra detail is still a failure of accuracy and scope.
Going further. The original table was already usable; drafting emails is an additional Create task. Correcting a missing action would still belong to reaching the original finish line.
Compare active human effort separately from elapsed speed. The slower response can require less human time. Both observations matter when choosing.
Track the active human time spent reaching the usable result. Separately track the time deliberately spent beyond that finish line. The time-cost calculator values those two stages at the chosen hourly rate.
Ten minutes spent editing is different from ten minutes waiting while other work continues. Record elapsed time separately; count waiting in active time only when it requires attention.
The calculator does not measure quality, reliability, the value of discoveries or AI fees. Use the performance checks first, then use the calculator to understand the time consequences.
This is the publication’s way of organising real jobs and personal comparisons. It is not a validated benchmark or a claim that one assistant wins every kind of work.
The distinction between task scenarios and multiple performance measures is informed by Stanford’s HELM research. Repeated attempts as a test of consistency are also explored in the τ-bench paper. The six reader-facing task families are an editorial proposal, not categories taken from those studies.