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.
The spine
Section titled “The spine”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.
The Workbench
Section titled “The Workbench”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.
Feedback lands on a version
Section titled “Feedback lands on a version”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.
From review to published
Section titled “From review to published”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.
Calendar
Section titled “Calendar”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.
Related
Sources: docs/architecture/work.md, input/WilsonOS_Overview.html §02 (Work & deliverables) · Last verified 2026-09-15