Knowledge Base

From Signal to Task to Closure: How the Execution Loop Works

DBR77 Team7 min read

On this page

The execution loop is the route a signal takes from the moment something goes wrong to the moment someone has fixed it and the fix is checked. It has seven steps: signal, triage, task, assignment, execution, verification and learning. A signal becomes useful only when it turns into a task with one owner, a deadline and a clear definition of done. The loop closes when the result has been checked.

Most plants have plenty of signals but no shared route for them, so each one is handled by phone, memory or a note on a board.

The seven steps of the loop

StepWhat happensWhoDone when
1. SignalA machine, person or system reports a deviationMachine, operator, inspectorThe event is recorded with time and place
2. TriageA rule or person decides if it needs action, and how fastRule, shift leadA severity class is set, or it is closed as "no action"
3. TaskThe signal becomes a task with context attachedSystem or shift leadThe task names what, where and why
4. AssignmentThe task goes to one owner by role, skill and shiftSystem, shift leadThe owner accepts it
5. ExecutionThe owner does the work and records what was doneOperator, setter, technicianThe owner marks it done
6. VerificationSomeone checks the result against the definition of doneShift lead, quality, next shiftProof is attached and the task is closed
7. LearningRepeats are spotted and the standard is updatedEngineer, team leadCause and fix are stored, or the standard changes

Steps 1 and 5 happen in almost every plant. Loops break at steps 2, 4, 6 and 7: without triage a signal is noise, without acceptance a task has no real owner, without verification it is only "done" in the owner's opinion, and without learning, repeats go unspotted and the standard never changes.

At 10:20, an inspector finds a torque check on station 6 skipped for 40 units.

Six steps of one skipped torque check on station 6, from the signal at 10:20 to verification at 11:20 and a learning task

Which signals should become tasks

If every alarm becomes a task, people stop reading them. If none do, the loop never starts. A simple triage rule works for most lines: a signal becomes a task when at least one of these is true.

  • Someone else must act. The person who saw it cannot fix it alone.
  • It needs more than a few minutes. A quick operator reset is logged, not tasked.
  • It touches safety, quality or a customer order. These always get an owner and a record.
  • It repeats. The third occurrence in a shift is a task even if each one was small.

Signals come from machines (stops, counts, condition values), people (Gemba walks, operator notes, near misses) and systems (missed inspections, SPC alarms, late material). All three should enter the same route. Machine faults that need parts or planning become maintenance work orders, which have their own rules; How to Manage Maintenance With Data deals with those.

What a good task contains

A task that says "check press 4" comes back as "checked". A good task lets the owner act without a phone call:

  1. What happened, with the source signal attached.
  2. Where, with line, machine, work order and material lot.
  3. One owner, by role and shift, so the task survives a shift change.
  4. A deadline set by severity. For example: class A (safety or quality risk) within 15 minutes, class B (line running slow) within the shift, class C (improvement) within a week.
  5. A definition of done, written in advance: a measurement, a photo, a checklist or a result on the next parts.
  6. An escalation path if the deadline is at risk.

For owners and escalation at shift change, see How to Keep Accountability Clear Across Shifts.

Why done is not closed

The Lean Enterprise Institute describes the Check step of PDCA as measuring a change to evaluate performance against the target. Act then means standardizing the change or starting the cycle again. The loop applies that idea to every task, at shift speed.

Verification checks the result against the definition of done, not against the owner's report. Risky work gets a second person: class A is verified by the shift lead or quality, while for class C the owner's photo may do. A failed check sends the same task back, so the history stays in one place.

Learning is step 7. Toyota's description of jidoka speaks of clearly detecting abnormalities and preventing them from recurring. When the same task appears three times in a month, the fix is not working, and that is the moment for a structured problem-solving sheet such as an A3, which records the countermeasure, who will do what when and evidence that the issue was resolved.

An illustrative example, and how to measure the loop

Illustrative example: on a two-shift assembly line, an inspector finds at 10:20 that a torque check on station 6 was skipped for 40 units.

The triage rule sets class A, a quality risk. A task goes to the shift's quality technician with the station, order, serial range and last torque values. The technician accepts at 10:26, holds the 40 units and re-checks them. At 11:05 the task is marked done with results attached, and the shift lead verifies and closes it at 11:20. Because it is the second skipped check on station 6 this month, a learning task goes to the process engineer to review the work instruction.

Measure the loop itself weekly:

  • Time to accept by severity class.
  • Time to close, including verification.
  • Overdue tasks at shift end.
  • Reopen rate: tasks that failed verification.
  • Repeat rate: the same task on the same machine within 30 days.

A falling repeat rate shows that step 7 works. Why Dashboards Don't Fix Factories explains why screens alone do not create this loop.

How this works in DBR77 IRIS

Every task in DBR77 IRIS moves through the states of IRIS Tasks: open, in progress, review, done and verified. Routing rules send tasks to a role, tasks carry their context (line, machine, work order, lot), and overdue tasks are flagged. A task can require verification by a named role before it closes.

Signals enter from several modules. SPC alarms and defect reports from production open non-conformances in IRIS QMS, machine failures open work orders in IRIS CMMS, and Gemba walk findings become tracked tasks with photos attached. Alerts and tasks are routed by role, and Gemba tier boards escalate unresolved issues by SLA rules.

Data & AI proposes recommendations from cross-module data, each with the basis for its score. A person applies, approves, rejects or defers each one, and IRIS records the outcome of those that are applied.

FAQ

Who should do triage, a person or a rule?

Written rules for common signals, the shift lead for the rest. Turn a manual decision into a rule once it is always made the same way.

How many open tasks per shift are too many?

When overdue tasks grow every week. Tighten the triage rule or add owners.

Should the person who did the work also verify it?

For low-risk tasks, the owner's photo or measurement can be enough. For safety and quality, use a second person.

Conclusion

Pick one line and three signal types, write the triage rule for them, and give every task an owner, a deadline and a definition of done. Each week, read the time to close and the repeat rate, and add more signal types only once the first loops close on time.

Sources