From intent to issues
When you give the CEO an objective, it decomposes the work into issues: discrete units the org can assign, work, and close. An issue carries an owner, a status, and a history of what was done. This is how a one-line brief becomes accountable work rather than a vague request.
Reading status
At any moment you can see what is open, what is in progress, what is blocked, and what is done. You read this the way a board reads a company: by exception. When something is blocked or taking longer than expected, you open it and follow the thread.
You do not assign or close issues by hand. The CEO routes them to the right agent, and the work updates the issue as it goes. Your job is to watch for the exceptions and to weigh in when an issue carries a decision that is yours to make.
Every issue links to the audit trail, so you can trace any outcome back through the chain of decisions and handoffs that produced it.
Blocked issues are signals
A blocked issue is not a failure of the colony; it is the colony telling you something it cannot resolve on its own. Usually a block means the work hit an approval gate, ran into a missing integration, or reached a decision that is yours to make. The block is the system respecting your authority rather than guessing.
When you see a block, open it and read why. If it is waiting on an approval, approve or reject it. If it is missing a tool, wire the integration or tell the CEO to route around it. If it is a decision, make it in one line. Blocks clear fast once you treat them as the short list of things that actually need you.
How issues relate to routines
A routine is just a scheduled producer of issues. The morning brief routine, for example, opens and closes its own issue every weekday. This is why routines respect every control: the issues they create flow through the same gates, budgets, and audit trail as any issue you start by hand.
This article is part of the launch docs set; boundaries and depth are still being reviewed with engineering and will keep sharpening.
