# The record of work is the evidence it happened

> worklists.app — 2026-08-20
> Written for VC-6 — the food-processor / co-manufacturer plant org — the plant operations VP under a customer mandate with a date on it, who has to emit events for someone else's program and prove the work behind them.

One thesis: **the record of work done is the same object as the evidence it happened.** On this
app a task does not close and then get documented. It closes *by* being documented — with an
attested capture that says who, where, and when, inside the window — and there is no second record
to reconcile against the first because there is only one.

## Two records, and the gap between them

A plant under a customer's traceability mandate runs two records without noticing. One is the
work record: the MES or WMS task list, with its statuses and its logins. The other is the event
record: the traceability events you emit for the customer's program, the ones with the lot, the
time, the location.

They are produced by different systems from different inputs, and they disagree at the edges. A
task closed at 06:14; the event says 06:31. A task closed by login `line3`; the event has no *who*
at all, because the standard has no required field for it. When the customer's auditor asks you to
show that a specific event was produced by a specific act of work, you are holding two documents
and a story about how they relate.

## One motion

On this app the whole critical path is one motion, and the person performs only the first step:

1. **Scan.** The operator points the camera at the mark on a case of lettuce. No reading required.
2. **Attest.** The identity rail binds the act to the person holding the device.
3. **Emit.** The event lands on the spine and comes back with a hash.
4. **Complete.** The task closes with that hash.

The event that satisfies your customer's program and the act that closes your task are the same
event. The *who* the standard never required is present, attested, on the event itself. The time
is the capture time, not the tap time. The place is the read point. There is no second record.

## Inside the window

A task is dispatched with a window — this receiving, at this dock, before this time. The evidence
that closes it carries its own timestamp from the capture, and the close is evaluated against the
window. An event inside the window closes the task. A window that passes with no event becomes a
state the record enters, written by a clock on the server, not by a person, so that *this window
was missed* is a fact on the ledger and not a color on somebody's dashboard.

That is what *a real who, at a real place, inside the window* means, and all three are read from the
evidence rather than from the task system's opinion of itself.

## What the operator sees, and what a face cannot lie about

The task screen renders the evidence plainly: what capture will close this; what has been
presented; and the attestation grade once it lands. Before the scan, *presented* is absent, marked
as not yet captured. While the emit is in flight it is marked unconfirmed. Only when the hash is
acknowledged is it present.

Those three states are kept apart on purpose. A face that promoted an in-flight hash to *present*
would be telling the operator their task is closed when it is not, and an app that collapsed
*absent*, *unconfirmed* and *withheld* into one blank would be lying about the record in three
different ways. Every value on the screen carries where it came from and whether it is observed,
computed or inferred, and a model-inferred value — an OCR'd lot number, say — is marked as such at
the same weight in every face, because an inferred lot on a recall record is not a fact.

## The scan emits first

The capture goes to the spine before the app decides anything about tasks. Then the app matches it
against the worklist it already holds. Exactly one match closes the task. Two matches stop and show
both. No match leaves the event standing — **a scan that closed no task is not an error.** Your
operator's record of what they did does not depend on a dispatcher having predicted it, and a dead
network does not stop a camera; the worklist is held on the device and the capture waits.

## What the auditor gets

One lineage per task: the customer PO it was dispatched from, the attested operator, the dock, the
capture time, the event hash, and the event itself one hop away on the spine with the lot and the
case. If the count was corrected later, the correction is an event naming the one it corrects, in
order. Nothing overwritten, nothing reconciled by hand.

The work door behind this app, [worklists.dev](https://worklists.dev), makes the rule explicit:
`complete` takes an event hash, not a boolean, and refuses anything cheaper. Get started with an
evaluation deployment, close one task, and hand the trace to whoever audits you. It is the thing
they were going to ask for.

---
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