Follow the work.
Define the scope.
Choose a direction by the question your operation needs to answer, then connect it to a concrete technical result.
Four directions.
Different responsibilities.
A working screen needs a meaningful state. A task needs a defined recovery rule. An alert needs an audience. A release needs a decision owner. These relationships shape our engineering focus without turning every project into the same package.
What needs attention?
Working screens that connect state, context, and the next action.
02 / Task orchestrationWhere did the work stop?
Explicit task states, handoffs, and recovery decisions.
03 / Signals & diagnosticsWhat changed, and why?
Evidence that helps a maintainer interpret behavior.
04 / Release & recoveryCan the change be reversed?
Defined release decisions and an explicit recovery path.
Name the point of uncertainty.
If people cannot tell which item needs action, begin with the operational interface. If work stops without an understandable explanation, examine task orchestration. If the system behaves differently but nobody knows where to investigate, consider the signals. If changes are difficult to release or recover, review the release path.
One engagement may involve several directions. A limited task tool could include an operator screen, a background workflow, and a few diagnostic events. The scope should explain which parts belong in the first delivery and which dependencies remain outside it.
Bring the environment into the brief.
Existing platforms, available APIs, identity arrangements, hosting permissions, and maintenance capacity affect the appropriate approach. Confirm those conditions early enough to avoid planning around access or features that are not available.
A proposal should identify the intended users, the representative task, the deliverables, and the way the result will be reviewed. If the available information is not sufficient, a separately agreed discovery task may be the appropriate next step.
What a project agreement should cover