Retired lessons · Lesson 3 of 3

How does Work and the case file track a work item?

Quick answer

Retired lesson, kept for old links. Work was the queue and the record: every live work item grouped into by-Team lanes, with the case file as the detail. The case file is the one page where all four gates resolve, where the runs behind each step open, and where a comment becomes a line in the plan.

This lesson describes Work as it read before the simplification of September 2026, with by-Team lanes, four gates, and Calendar and Email lanes beside it. Work is now home, one row per ticket in three views, the gates are three clicks, and the Calendar and Email lanes are retired. Start with How does Work track a ticket, and what is on the case file?.

What is Work?

The queue and the record in one place. Work shows what your Teams are working now and what they have shipped, grouped into by-Team lanes over live work items.

Read one lane like a standup that already happened, or scan across lanes for the shape of the week. There is no separate inbox of pending approvals: the things that need you are counted in the lane and answered on the item itself.

What is a work item?

The unit of a Worker’s output and the record of it. One item holds the proposal it started as, the approved plan, the runs, the pull request, the review, the test evidence, the gates a person answered, and what the whole thing cost.

Its detail view is the case file, and that is the one page the item ever needs. Everything below happens there.

Which four gates does a person answer?

Four, in order.

  1. Accept the proposal. Bailey pulled it off your backlog with the evidence attached. You say yes, no, or not like that.
  2. Approve the plan. Reeve drafted it and checked it before asking you. You approve it, edit it, or send it back.
  3. Unblock. Only when the work needs something only a person has: a credential, a product call, an answer the record does not hold.
  4. Accept the result. You read the pull request with the review and the test video attached, then merge it or send it back.

The four gates are the same at every rung of the Ladder. What changes as an Engagement is promoted is which of them the Team may answer for itself on reversible work. Accepting the result, and the merge behind it, stays with a person at every rung.

What do the runs behind each step show?

Each step on the case file opens the run that produced it: what the Worker read, what it changed, which Playbook rules applied, which decisions it grounded itself on, and what the run cost. No log diving and no support ticket to find out why something happened.

Do comments on the case file change the plan?

Yes, and that is the point of putting them there. A product manager’s answer at the proposal becomes a line in the plan before a line of code is written. An engineer’s correction on the plan lands in the current item and, if it should outlive the item, comes back as a proposed Playbook rule. Context moves forward with the work instead of dying in a thread.

Who sees which items?

Your Work is composed for you: every record you are permitted to see, and nothing else. Shared Teams are readable across the workspace, restricted and private Teams only by their people. A sensitive lane can exist without leaking into everyone’s view, and the Brief a reader gets obeys the same setting.

Where do Calendar and Email fit?

They are supporting lanes, not the center of anything. Once your Google source is connected, a Calendar lane and an Email lane appear beside Work, and @yagni reads the agenda so a planning session or an incident review starts with the relevant case files already current. Your events stay in Google Calendar and your mail stays in Gmail. Engineering work still lives in Work.

Read enough. Run it.