# worklists.app — the frontline app, under your name

Your floor already records that a button was pressed. An auditor, a customer and a chargeback panel
do not accept that.

worklists.app is the frontline app of the visibility family. You white-label it and publish it on
your own developer account, so the screen a picker holds on Monday carries *your* name. Nothing
upstream is named on it.

A task closes with an attested capture — a real *who*, at a real place, inside the window — rather
than a checkbox. The record of work done is the same object as the evidence it happened.

The same task goes to a person or to an agent, and the app does not change shape.

## What a deployment is

1. **Your name on the screen.** The app is white-labeled and published on your developer account. Nothing upstream is named on it — no "powered by", no family footer, no upstream link in any shipped instance.
2. **A task closes with an attested capture, not a checkbox.** A real who (the badge), at a real place (the reader), inside the window (the clock). The record of work done is the same object as the evidence it happened, and an auditor, a customer or a chargeback panel accepts it.
3. **The close path requires no reading.** The confirm is the scan. Success is haptic and a shape change and a sound — never color alone, never color plus text. Read in a freezer at 05:00 and in a yard at noon.
4. **The same task goes to a person or to an agent.** An approval is a task. The supervisor who attests a count and the agent that drafted it append to the same record, and the app does not change shape.
5. **One deployment, one brand, one regime, one tenant.** The unit is a deployment, never a seat. Adding a person, a station, a site or a device changes nothing; adding a brand or a regime is a second deployment.
6. **Two regimes, non-fungible, legible on the device.** An employer's deployment is mandated; an organization's deployment for its own members is worker-held, and that record belongs to the worker — it counts toward no employer's metric and is visible to no employer.

## The second operator

A union, a trade school, an apprenticeship program, a trade association — an organization the
worker already believes — runs its own instance. That deployment's record belongs to the worker,
counts toward no employer's metric, and is visible to no employer. The two identity regimes are
deliberately non-fungible, and which one you are in is legible on the device.

## What you do not get, and why that is the product

1. **No per-person surface.** Object → performer is the product: trace a bag of lettuce back to the hands that moved it, always. Performer → objects is refused on an employer's instance, by a rule with a number. A scope with no cited authority does not get the metric.
2. **No rate, ever.** No scoreboard, no ranking, no streak, no badge, no level, no target. Dressing a rate up as a game is still a rate, and this app never computes one.
3. **No roster.** The app holds no commercial per-person roster. Per-seat pricing would require one, and it would re-paywall the thing the verbs give away: you always can record what you did.
4. **No swipe-only affordance on the critical path.** Swipe-to-complete is precisely the pattern WCAG 2.2's Dragging Movements criterion exists to refuse, and it is the first pattern a frontline app reaches for. Not here.

## What ships today

Shipped:
- The compile-time regime binding: a deployment manifest (*.deployment.json, 2 in the tree) binds one operator, one tenant and one regime into the build, and discretionary is refused at compile time.
- 3 build gates in the app's own tree — regime-binding-gate, views-gate, white-label-gate — each run in the estate's install-free gate chain.
- The six-View, twelve-Role registry with measured per-face token budgets; the white-label gate fails a build that carries a hard-coded product name.
- The app ships through the operator's own developer account; over-the-air updates are disabled by design, so what is in the hand is what was signed.
- This door: the page, its markdown and JSON twins by content negotiation, the blog, the dated ledger, llms.txt, the sitemap, and /product.md — the product document served byte-identically.
- POST /waitlist — the access list, stored in this door's own D1 database, the row exactly what the form says it is.
- Request telemetry to the estate's shared store, disclosed in full at /what-we-log in three faces.

Open:
- A screen. The app's root component renders nothing yet — phases 1 and 2 of the surface spec (the regime binding and the registry) are in the tree, and the first View is not (P0-A1; dot-do/vis#337–#347). Read from apps/worklists.app/src/App.tsx during this build.
- The free evaluation deployment against the demo tenant, self-serve, no card (P0-A2; dot-do/vis#424).
- The price per production deployment. The model is ruled — one price per deployment, annual, unlimited performers — and the number is $TBD; nothing publishes until it is a number we are willing to change (P0-A3; dot-do/vis#422).
- The store listing under an operator's account, end to end, proven once (P0-A4).
- Signup notification on the access list; today the row is written and nobody is paged (P0-A5).

Dated ledger: https://worklists.app/what-ships-today/ · Get started: https://worklists.app/get-access/ · Blog: https://worklists.app/blog/ · Product document: https://worklists.app/product.md

The developer door is [worklists.dev](https://worklists.dev).

Operated by Visibility Cloud, Inc.