Keep success and completion separate on a status light

Status Light is a physical indicator that receives meaning from a software integration. A task being finished does not establish that it succeeded. If every completion event turns the display green, failures and cancellations can look reassuring. Model the task's lifecycle separately from its result, then choose a visible convention that reflects the distinction you need at the desk.

What does completed mean in the source?

Read the source's documented event fields and terminal states. Completion may describe the end of processing while another field carries the outcome. Some systems also distinguish skipped work, cancellation or a result still awaiting interpretation. Do not infer those meanings from the event name alone.

Inspect a representative successful and unsuccessful task record before writing the mapping. Note which field actually distinguishes them and whether it can be absent. Keep an unknown value explicit rather than letting a default branch turn an unfamiliar outcome into success.

Which result should green represent?

Define the evidence required for the chosen success signal. It might mean the selected job reports success, but that does not necessarily establish that an entire release is ready or that a human review has happened. Keep the display's promise as narrow as the verified source information.

If the task only generates a draft, distinguish successful generation from approval of its contents. A completed agent response, export or render can still need inspection. A companion text status can name the completed stage so the physical signal does not imply a broader decision.

How should the integration store these facts?

Keep lifecycle, outcome and review state separate when the workflow needs all of them. That makes it possible to represent completed with failure or completed awaiting review without inventing contradictory combined labels. Store the task identity and freshness information alongside those values.

Translate the internal state into the device's confirmed output capabilities only after deciding the meaning. Avoid assuming extra flashing modes or feedback channels. If the hardware cannot express every distinction clearly, prioritise the attention signal and provide details through the source record or a small text view.

What cases should be checked before use?

Test success, failure, cancellation, missing outcome and an unfamiliar result value. Include a task whose processing succeeds but whose output still needs review. Confirm that none of these falls through to a reassuring signal accidentally.

Read the written legend as someone unfamiliar with the implementation would. It should explain what has been established and where to inspect the actual result. The Status Light product description covers the physical indicator; accurate success signals depend on the evidence rules in the software that controls it.