# Make an AI capacity pilot produce a reviewable receipt

> Source: <https://dev.to/wagglet/make-an-ai-capacity-pilot-produce-a-reviewable-receipt-251j>
> Published: 2026-10-16 23:34:09+00:00

Disclosure: AI drafted this tutorial for Wagglet's marketing work. All task names and monetary values below are synthetic examples, not measured savings.

A capacity pilot needs more than a list of merged patches. It needs a way to connect one bounded task, one acceptance decision, and two different measurements: human capacity recovered and actual spending avoided.

Here is a small implementation you can adapt. The example task updates a compatibility table from an existing test matrix. It deliberately excludes production deployment and dependency upgrades. To **delegate AI task without sharing account** credentials, pass the brief and authorized repository access; the runner uses their own provider identity and tools.

```
id: compatibility-table-01
requester: product-owner
runner: authorized-maintainer
reviewer: release-engineer
input: fixtures/runtime-matrix.json
output: docs/runtime-compatibility.md
scope:
  include: [document the supplied fixture, identify missing entries]
  exclude: [upgrade packages, change CI, deploy, modify credentials]
acceptance:
  - every fixture row is represented exactly once
  - unknown support is labelled unknown
  - reviewer reproduces the generator output
stop_if:
  - repository access is missing
  - fixture contradicts the requested claim
  - acceptance requires a production change
```

The requester prepares this contract. The maintainer executes it with their own authorized tools. The release engineer decides whether the submitted evidence satisfies acceptance. Assign these roles before running the model so that a generated summary cannot silently become its own approval.

Save the next file as `pilot.json`. The baseline is a pre-task estimate for equivalent scope. The human-hours fields are disjoint attention categories, not elapsed model runtime.

```
[
  {
    "id": "compatibility-table-01",
    "accepted": true,
    "baselineHours": 3,
    "briefHours": 0.4,
    "executionHours": 1,
    "reviewHours": 0.5,
    "reworkHours": 0.2,
    "cancelledPurchase": 0,
    "incrementalTools": 0,
    "incrementalPaidLabor": 0
  }
]
```

Use `accepted: false` until the reviewer records a decision. If execution stops for missing access, retain the brief and coordination time. Deleting failed attempts makes the pilot appear cheaper than it was.

Save this as `pilot.mjs` and run `node pilot.mjs pilot.json` using Node.js. It rejects missing, negative, and nonnumeric cost inputs so an incomplete receipt does not quietly become zero.

``` js
import { readFile } from 'node:fs/promises';
const rows = JSON.parse(await readFile(process.argv[2], 'utf8'));
const fields = ['baselineHours', 'briefHours', 'executionHours',
  'reviewHours', 'reworkHours', 'cancelledPurchase',
  'incrementalTools', 'incrementalPaidLabor'];
let recoveredHours = 0, avoidedSpend = 0;
for (const row of rows) {
  if (typeof row.accepted !== 'boolean') throw Error('acceptance missing');
  for (const key of fields) {
    if (!Number.isFinite(row[key]) || row[key] < 0) {
      throw Error(`${row.id}: invalid ${key}`);
    }
  }
  const attention = row.briefHours + row.executionHours +
    row.reviewHours + row.reworkHours;
  recoveredHours += (row.accepted ? row.baselineHours : 0) - attention;
  avoidedSpend += (row.accepted ? row.cancelledPurchase : 0) -
    row.incrementalTools - row.incrementalPaidLabor;
}
console.log(JSON.stringify({
  accepted: rows.filter(r => r.accepted).length,
  recoveredHours: +recoveredHours.toFixed(3),
  avoidedSpend: +avoidedSpend.toFixed(2)
}, null, 2));
```

For the supplied illustration, the arithmetic gives one accepted task, 0.9 recovered hours, and zero avoided spend. That is an example calculation, not evidence that the workflow saved a company money. An existing salary or subscription does not disappear because a task completes faster.

Suppose the runner notices that the fixture has no Safari result. They should submit an explicit unknown entry and the missing-input observation. They should not invent browser coverage or broaden the task to install a new test environment without authorization.

The reviewer checks the fixture-to-document mapping and records the missing coverage. If the acceptance requirement demanded actual Safari support, the task is not accepted yet. Its consumed attention still belongs in the ledger. If the requirement was faithful documentation of the supplied matrix, a clearly labelled unknown may satisfy the task.

That distinction is why the contract comes first. A tidy article generated from incomplete evidence can still be an incorrect deliverable.

Group receipts by scope and rejection reason. Report accepted output, net recovered attention, net avoided spend, and work awaiting review separately. Avoid converting hours to cash unless a real spending decision changed and the budget owner can identify it.

The [Wagglet capacity handoff article](https://wagglet.com/blog/use-unused-claude-code-codex-capacity) describes the broader coordination opportunity. The receipt above gives a developer a smaller unit to implement and inspect. Start with one task class, retain negative outcomes, and expand only when the review cost remains visible.