# An approval is a task

> worklists.app — 2026-08-20
> Written for VC-6 — the food-processor / co-manufacturer plant org — the plant operations lead whose approval trail lives in email, a whiteboard, and a supervisor's memory.

One thesis: **an approval is a task.** When a receiver counts thirty-eight cases against a PO for
forty and a supervisor has to accept the short receipt, that sign-off is not a different kind of
thing from the count. It is addressed to a role, it sits in that role's worklist, and it closes with
the same evidence shape — an attested act by a real *who*, inside the window — as everything else on
the floor.

## Where approvals live today

Ask where the record of last month's short-receipt approvals is, and the answer in most plants is
three places. Some are in the WMS as an override flag with a login. Some are in email — the
receiver's lead asked, the supervisor replied "ok." Some are in a supervisor's memory, because it
was 06:20 and the truck was blocking the dock.

When the customer's quality team asks who accepted the short lot of lettuce on the fourteenth, and
under what authority, you reconstruct it. The flag says an override happened. The email says
somebody said ok. Neither says who was standing there, or whether the person who said ok had the
authority to say it for that lot.

## One queue, one shape

On this app there is one kind of work. A receiving count is a task. An inspection is a task. And
a request for a supervisor's sign-off is a task. They sit in the same worklist, rendered the same
way — ref, what to do, where, state — and the supervisor's pending approval is one row in their own
list next to whatever else they hold.

It arrives there by escalation. The receiver's count closed short; the task that needs authority is
escalated to a **role** — *shift-lead*, *QA* — never to a named person. Who fills that role right
now is resolved on the server at the moment of the request. The receiver does not pick a person,
because picking a person would mean showing a list of people, and this app shows no one a list of
people.

The supervisor opens their list and sees the request: asking what, for which task, of which role.
They settle it the way they settle anything — with an attested act. The approval is not a tap that
sets a flag. It is an event on the same spine the count landed on, with the supervisor's attested
identity, the place, and the time, and the approval task closes with the hash of that event.

## What the record then says

Read the short lot's lineage afterward. It shows: dispatched from the customer's PO; counted at
dock 3 at 06:14 by an attested receiver, thirty-eight cases, event hash; escalated to *shift-lead*
at 06:15; approved at 06:22 by the attested person who held *shift-lead* at that moment, event
hash. Two acts, two people, two hashes, one record, in order.

Nobody reconstructed anything. The quality team's question — who accepted it, under what authority
— is answered by the trace, and the trace is made of the same material as the count it approves.

## What this app does not do with approvals

It holds no authority. Whether the person who filled *shift-lead* was entitled to accept a short
lot of a covered food is a question for the identity rail's ceremony, which the escalation compiles
to. This app never grants, never revokes, and has no screen on which anyone authors a permission.
No surface in this family is allowed to be an authority-authoring screen, and a frontline app is
the last place one should appear.

It also never lets a supervisor edit what the receiver recorded. If the receiver raised a block on
the way to the short count — *pallet arrived short-loaded* — that block is the receiver's, and the
supervisor never sees it. Not grayed out; absent. The approval closes the task. It does not rewrite
the path to it.

## An agent can ask, too

The same shape holds when the requester is not a person. An agent reconciling the ASN against the
count can escalate the discrepancy to *QA*, a human approves, and the agent receives the settle and
continues. The approval task looks identical in the supervisor's list whether a receiver or a
process raised it, because it is the same task.

Get started with an evaluation deployment and run one short receipt through it, end to end,
including the sign-off. Then ask the trace who approved it. It knows.

---
Get started: https://worklists.app/get-access/ · All posts: https://worklists.app/blog/ · Machine face: https://worklists.app/llms.txt · Product document: https://worklists.app/product.md