Markdown edition

# Map your own work and choose a first AI task to test

> Make a dated map of the tasks you own, their outputs, checks, rights and human approvals. Choose one AI task to test later, or record why none is ready.

By BIG CHANGE Editorial

Published: 2026-10-20T12:07:38.357Z
Updated: 2026-10-20T12:07:38.357Z
Canonical: https://bigchange.ai/blog/map-work-choose-first-ai-task-guide

![Conceptual charcoal illustration of blank task cards in a wall-mounted wooden rack, beside one empty orange-edged slot.](https://bigchange.ai/api/media/file/blank-task-rack-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Before you choose an AI tool, write down the work you actually control. A task may produce an answer that is easy to check yet still involve private data, an irreversible action or a judgment that belongs to a person. This guide helps you make a dated decision map across your own tasks. Its finished result is one proposed first test, or a documented decision that none is ready. You do not need to run AI to complete it.

The starting idea comes from [Andrej Karpathy’s November 2025 essay on verifiability](https://karpathy.bearblog.dev/verifiability/). He argues that an environment is more open to AI optimization when attempts can be reset, repeated efficiently and given a reliable reward signal. Those are questions to investigate, not a workplace approval rule. The task record below is our own worksheet. It adds the people, permissions and consequences that an owner must establish in a real process. [NIST’s voluntary AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) also calls for context, oversight and measurement when organizations consider AI systems; it does not endorse this worksheet or certify any task.

## What you need

You need access to real records of work you own or are allowed to assess: a task log, calendar, procedure, intake queue or the people responsible for the work. You also need a private place to keep the map and evidence links, a named process owner, and another person authorized to challenge the decision. State which team or process and which dates the inventory covers. Do not put confidential source material into an AI service to make this map.

Allow for the time it takes to find records and review them. The map itself needs no AI account, paid API or software purchase. A later test may require separate permission, tool charges, staff review time and an error budget.

## 1. Inventory the work as it is done

Set the inventory window and scope before listing tasks. Record the source of each row so a second reader can find it. For every recurring task, name the trigger, real input, current worker, required output, recipient and existing approval. Ask the responsible person to confirm what the records omit. Mark an unverified detail **unknown**.

Split a workflow when its output, permission or consequence changes. A single broad label can hide a handoff that requires different authority. Keep the number of rows faithful to the work; there is no target count. Note excluded teams or periods so a reviewer can spot a missing task without mistaking it for a poor candidate.

**Check:** Could the reviewer follow the evidence link, identify the task owner and say what must be delivered to whom? If the inventory is thin, return to the owner’s records before ranking anything.

## 2. Describe the check before the tool

For each output, ask what a person other than its producer would inspect. Name the authoritative source, the precise pass rule and any required judgment. How would the reviewer catch an omission or an answer that looks plausible but is wrong? Would checking take almost as much work as doing the task? Record who could perform the check and how much review effort is known or still unknown.

Label the checker **existing**, **proposed** or **unknown**. “Existing” means there is a check in the present work process, with evidence of how it is used. “Proposed” means you have written a possible rule but have not shown that it catches relevant errors. Neither label proves an AI output will pass it. A task with no source of truth or workable pass rule needs preparation before it can be a first test candidate.

Now ask three separate questions adapted from [Karpathy’s essay](https://karpathy.bearblog.dev/verifiability/): Can a failed attempt be reset without lasting harm? Could enough **authorized** attempts be made within a sensible time and cost? Could each attempt receive a dependable check? Write yes, no or unknown with local evidence for each. Karpathy uses these properties to discuss AI optimization; your answers do not determine whether workplace use is allowed.

## 3. Record authority and failure costs

Checkability is only one part of the decision. Record who controls the input data, whether the proposed AI use and any disclosure are permitted, and which people may be affected. Specify what a future tool could read, what it could write, and who alone can approve an action. Name any downstream step that cannot readily be undone. Put the likely cost of a false pass alongside the cost of human checking and rework; use **unknown** where you cannot support an estimate.

Write down context the output checker may miss: unwritten rules, exceptions, changing source material or a decision that requires accountable human judgment. A prompt telling a tool to ask permission is not itself a permission or access control. [NIST’s MAP guidance](https://airc.nist.gov/airmf-resources/playbook/map/) asks organizations to examine use context, affected people, data and oversight; its [MEASURE guidance](https://airc.nist.gov/airmf-resources/playbook/measure/) addresses test methods and their limits. Both are voluntary guidance, not a pass stamp for your row.

**Check:** If rights, disclosure, the person who may approve an action or a credible recovery path is unclear, keep that uncertainty in the record. A tidy checker cannot resolve it.

## 4. Classify each row and choose at most one first candidate

Use these **editorial worksheet categories**, with a reason and evidence link for each row:

- **Candidate for a bounded test:** output, check, reset path and authority for a separately approved test can be specified. This is a candidate for investigation, not approval to automate.
- **Prepare the check:** the task is described, but its pass rule, source of truth or checker still needs definition or validation.
- **Human assistance only:** limited drafting or analysis might help, while a named person keeps the consequential judgment and approval. Any actual use still needs permission.
- **Hold:** rights, context, failure consequence, recovery or other necessary evidence remains unresolved.

Do not force a numerical score out of unknowns. Compare only rows that could qualify for a bounded test. Record why one comes first, including its review burden and the harm a false pass could cause. Choosing **none yet** is a complete decision if every row has an unresolved prerequisite. Name the person and evidence needed to revisit it.

## 5. Write a proposed acceptance plan, then obtain a map review

For the first candidate, define the future test without conducting it. Specify the allowed sample and input boundary, the present work route used as a reference, the intended output, an exact pass/fail rule, the checker and human reviewer. Set a proposed limit on attempts, time, tool charges and review effort. State when to stop, how to return to the current process, who could authorize a later test, and what results would be recorded: passes, misses, failures, retries, review time and full costs. Leave authorization and observed results blank until they exist. If the chosen output can trigger an external action, hold that action behind its named human approver.

Have the process owner and a second authorized reviewer inspect the complete inventory. They should challenge missing work, source accuracy, checker feasibility, rights and the candidate or none-yet rationale. Record each person’s actual decision and date, including disagreement and the evidence that would settle it. Their acceptance of the map does not authorize a product trial. If the task, data, rights, check or consequences change, date a new row decision and retain the earlier record.

If a tool trial is later approved, [our separate guide to choosing or rejecting an AI tool for one small-business task](https://bigchange.ai/blog/choose-ai-tool-small-business-task-guide) begins from that selected task. This map stops before product selection and testing.

## Blank decision-map worksheet

Copy the fields into a private document or table. Add one task row for each real task; leave unknown facts visible. Do not fill the blank fields with imagined work.

**Inventory header**

- Process and scope: \_\_\_\_
- Included dates / excluded work: \_\_\_\_
- Process owner / map decision owner: \_\_\_\_
- Evidence location and access rules: \_\_\_\_
- Map date and version: \_\_\_\_

**Repeat for each task row**

- Task ID / task owner / evidence link and date: \_\_\_\_
- Actual trigger, input and authoritative source: \_\_\_\_
- Current worker, method and approval: \_\_\_\_
- Required output and recipient: \_\_\_\_
- Pass rule, exceptions and source used to check it: \_\_\_\_
- Independent checker and status (existing / proposed / unknown): \_\_\_\_
- What the check could miss / time to check: \_\_\_\_
- Failed-attempt reset or reversal / authorized repeat attempts and costs: \_\_\_\_
- False-pass consequence / downstream action / human-only judgment: \_\_\_\_
- Data rights, privacy and disclosure permission: \_\_\_\_
- Allowed reads and writes / human approver and stop authority: \_\_\_\_
- Category, reason, missing evidence and next owner/action: \_\_\_\_
- Decision date / event that requires review: \_\_\_\_

**First-candidate decision and proposed test**

- Candidate task ID, or “none yet,” and why: \_\_\_\_
- Why this row precedes the next eligible row: \_\_\_\_
- Authorized sample/input and proposed tool/action boundary: \_\_\_\_
- Current-route reference, output and exact pass/fail rule: \_\_\_\_
- Checker, reviewer, exceptions and false-pass check: \_\_\_\_
- Proposed attempt, time, charge and review limits: \_\_\_\_
- Stop, reset and return-to-current-process rule: \_\_\_\_
- Later trial authorizer / authorization decision and date: \_\_\_\_
- Actual attempts, results and costs (leave blank until observed): \_\_\_\_
- Process owner decision/date: \_\_\_\_
- Second reviewer decision/date, objections and resolution: \_\_\_\_

## The big change

A checkable output makes a task easier to evaluate, but it does not make the surrounding work suitable for unsupervised AI. The useful first decision is a traceable map of the work you control: what must be delivered, how errors would be found, whether failed attempts can be contained, and who has the right to approve a test. The answer can be one bounded candidate or none yet. This procedure proposes that decision record; BIG CHANGE has not tested it in an organization or measured any time, quality or cost benefit.

## Sources & further reading

- [Andrej Karpathy, “Verifiability” (November 17, 2025)](https://karpathy.bearblog.dev/verifiability/) — the argument about resettable, efficient and rewardable environments. It does not provide this workplace worksheet or approve automation of a task.
- [NIST AI Risk Management Framework 1.0 Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) — the voluntary framework’s context, oversight, measurement and decision framing; its functions are not an ordered checklist.
- [NIST AI RMF Playbook: MAP](https://airc.nist.gov/airmf-resources/playbook/map/) — voluntary prompts on use context, people, data, impacts and human roles.
- [NIST AI RMF Playbook: MEASURE](https://airc.nist.gov/airmf-resources/playbook/measure/) — voluntary guidance on test methods, limits, independent assessment and ongoing review.

## Sources

- [Andrej Karpathy, Verifiability](https://karpathy.bearblog.dev/verifiability/) — First-party essay arguing that resettable, efficient and rewardable environments favor AI optimization. It does not supply this workplace worksheet or establish task permission or suitability.
- [NIST AI Risk Management Framework 1.0 Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) — Voluntary govern/map/measure/manage framing for context, oversight and measurement. Its actions are not an ordered checklist, and it does not certify this method.
- [NIST AI RMF Playbook: MAP](https://airc.nist.gov/airmf-resources/playbook/map/) — Voluntary context, impacts, data and human-role suggestions. Used to inform original worksheet questions, not as approval for a real task.
- [NIST AI RMF Playbook: MEASURE](https://airc.nist.gov/airmf-resources/playbook/measure/) — Voluntary test-method, limitation and oversight guidance. No proposed checker in this article was validated.
- [BIG CHANGE, How to choose or reject an AI tool for one small-business task](https://bigchange.ai/blog/choose-ai-tool-small-business-task-guide) — Contextual next step after a task is selected. This article does not repeat its product screening or trial procedure.