Delivery

Delivery is the stage when an approved initiative is being built. Its Slices tab shows the build as it goes, so you can see what’s built and what’s waiting.

The page is the report

Most people who care about an initiative don’t build it. Someone in sales told a customer that all its depots could switch to single sign-on in one go. They want to know where that stands without asking an engineer, and so does the product manager who approved it. Meanwhile the coding agents doing the work need answers from those people, and shouldn’t wait for a meeting to get them.

Nobody writes a progress report. The page follows the work. Coding agents claim and close tasks and ask questions. People make their own calls, like blocking a slice with a reason, or calling one done once its demo works.

The build, in numbers and lanes

When someone who edits the approved initiative starts delivery, everyone who opens it sees the build. Its numbers show how much is built and how long slices have been blocked. Each slice is a lane on one timeline, with its tasks.

1234Full size

An initiative at ACME, the company in the docs' pictures, as the product manager who approved it sees it. None of its eleven tasks is closed yet.

1. Completion. How much of the requirements is built, out of 100.
2. Time blocked. How long slices have been blocked, in all. None, here.
3. Each slice as a lane up to now, with its tasks at the end.
4. Requirements. Each requirement, how much is done, and if it’s shown working.

Requirements shows how much of each requirement is built, out of 100. Shown working is something else. A requirement is shown working once every slice serving it has been called done, which a person does when its demo works. One says how much is built. The other says someone has seen it work.

Blocked by, and blocks

Blockers shows which tasks can’t start yet, and which unfinished tasks are holding work up, here or in other initiatives you can see. You read it as a list, or as a map.

1234Full size

The button in the portal waits for two tasks in the sign-in service, each built by a different engineer's Codex.

1. List or Map.
2. A slice, with its tasks inside.
3. A task holding work up, with who is building it and with which coding agent.
4. The task it holds up, blocked by two.

Waiting on a person

To reply and to do lists work waiting for someone. A question from the build to answer. A slice whose tasks are all closed, waiting for someone to check its demo. A change request to decide. Each row says what stays undone meanwhile. A question names the task being built without the answer. A change request names the option work carries on with.

We keep these apart from the blockers. In one list, nobody could tell if anything was blocked at all.

A coding agent asks when only the initiative’s people can decide something. An engineer’s Claude Code, building the rule that closes passwords after a depot switches, asked whether the 14 days count from the depot’s switch or from each person’s first sign-in. The question waits on the initiative’s owner, who answers it or hands it to someone who knows. Once answered, it moves to Settled, and the agent reads the answer the next time it reads the slice’s work.

Around it

The questions and change requests that wait on you also show in your Decisions. Coding agents work through Emargen’s connection: see Building slices. When every slice is done, the owner marks the initiative Done.

Next

How to

• Follow delivery
• Answer a question from the build
• Decide a change request

Page by page

• Slicespage by page