Skip to content

Tasks and the Workbench

Step 4 of how it works is you review and publish. This is where that happens. Work is tracked as goals, projects, and tasks; what the work produces lands as deliverables; and the Workbench is where you open any of them — a document, an image, a video, a page, a data file — in one viewer with comments, a rating, and a decision.

flowchart TB
  G["Goal<br/>a 90-day target tied to an outcome"] --> P["Project<br/>a multi-task initiative serving it"]
  P --> T["Task<br/>one unit of delivery, with versions and reviews"]
  T --> D["Deliverable<br/>an output someone should review, use, or publish"]
  D --> A["Artifact version<br/>the actual file, one explicit state"]

The hierarchy is loose by design: a task need not sit in a project, a project need not serve a goal. But the further down the chain a piece of work sits, the harder it is to justify when the accountability view asks what does this serve? — and that question is asked.

A task is the unit of delivery. It carries its brand, its status, the skill chosen for it and why, its versions (each a state of the work with a note), and its reviews. A task can involve several runs and produce several deliverables. Chat messages reference tasks; they never become the place a task lives.

A deliverable is an artifact marked as a result — as opposed to the by-products of getting there (drafts, intermediates, working files). Marking is explicit, so the review surface shows what matters and not everything the agent touched.

One surface opens any artifact type. Behind it, a dispatcher picks a renderer by file type — rich text for prose, a sandboxed frame for pages, a viewer with zoom for images, a player with timecodes for video, a waveform with transcript for audio, a tree for structured data, a table for delimited files — so you never leave the Workbench to see what an agent made.

Three modes, chosen by the link you followed:

Mode What you do
Read See the artifact and its comments. The default when you arrive from a chat card.
Edit Change it. Saving commits a new version; the old one stays.
Review Read plus a sidebar: a rating (1–5), a decision — approve, redirect, reject — and a note. Saving appends a review to the task.

A lineage panel shows what produced the artifact: the task, the run, the skill and its version, and for media the generation receipt. If something is wrong, you can see whether to fix the input, the skill, or the brand rule.

Comments are anchored to a specific passage, region, timecode, or line — on a specific version. “Warmer palette on v2” stays attached to v2 when v3 arrives; v3 does not erase the note. Approval is on a version too. This is what makes approve the thing I actually looked at unambiguous, and it is why the improvement contract can compare versions with evidence.

Ratings ride the artifact and roll up to the skill that produced it, never the task as a whole — a task that ran nine skills and scored “3” teaches nothing.

Approving a version does not publish it. Publishing is a separate, authorised step through a connection that records the external identifier of what went out. See Artifacts & publishing.

Deadlines, appointments, and publishing plans appear together in a calendar. An entry refers to the task, post, or automation it schedules; it never duplicates them, so there is exactly one place the truth of a task lives.

live Tasks with versions and reviews, deliverables, the Workbench with its renderers and three modes, comments, ratings, and the lineage panel are live. Task folders with stable identity (rename without breaking links) are reported live with final link checks pending. direction Goals and projects are lighter-weight records today than tasks; the accountability views are maturing.

Sources: docs/architecture/work.md, input/WilsonOS_Overview.html §02 (Work & deliverables) · Last verified 2026-09-15