Continual

Appearance

Check Lifecycle ​

Checks move through a lifecycle from draft configuration to daily execution, review, and eventual archival.

In the portal, the Checks area is split into three tabs — Activity, Definitions, and Proposed Changes — which map to the stages below.

Create ​

Managers, Admins, and Owners can create checks from Operations -> Checks -> Definitions.

Each check belongs to one machine and includes:

  • Type: Centreline or CIL.
  • Trigger: periodic, at shift start, on format change, or manual (started on the machine in the mobile app).
  • Grace period.
  • Target configuration, for centreline checks.
  • Evidence requirement and reference media.
  • Sequence order on the machine.

Execute ​

When a check becomes due, operators complete it in the mobile app. Each occurrence is stored as a check instance. Scheduled checks create occurrences automatically; manually triggered checks create an occurrence only after a mobile user triggers them on the machine or asset.

When a Line or Group is shut down, Continual clears its upcoming pending check instances and pauses new scheduled instances until it is reactivated. Work that is already due and historical results remain available.

Operators can:

  • Submit passing or failing results.
  • Enter numeric, text, selection, pass/fail, or photo responses.
  • Add notes and evidence.
  • Skip a check when it cannot be completed, either leaving it due to return to later or recording it as skipped.

When a Centreline reading is outside its target, the Operator records what happened next:

  • Corrected (corrected): they restored the Centreline immediately. The failed reading remains in deviation analytics, but it does not create new corrective work.
  • Left as is (left_as_is): the Centreline still needs attention. Continual raises or updates the deviation action and captures why it was left.
  • Target disputed (target_disputed): they believe the target is wrong and propose a replacement. The reading becomes evidence on the fail-linked proposal instead of creating duplicate corrective work.

Older app versions may submit a failing reading without a disposition. Continual keeps the legacy behavior for those readings and reports them separately from the three explicit outcomes.

Review Activity ​

Use Operations -> Checks -> Activity to review due, completed, missed, and skipped check instances.

Use this view for daily supervision:

  • Find checks that are currently due.
  • Investigate missed or skipped checks.
  • Confirm whether late work was still completed.
  • Filter by factory, line, machine, status, and date range.

Update ​

Use Operations -> Checks -> Definitions to edit an existing check.

Common updates include:

  • Changing the schedule or grace period.
  • Updating target values.
  • Adding or replacing reference media.
  • Changing evidence requirements.
  • Reordering the machine sequence.

Continual preserves history so previous results remain tied to the definition that existed when they were submitted.

Proposed Changes ​

Operators can propose changes from the mobile app without directly editing live configuration. Managers, Admins, and Owners review proposals from Operations -> Checks -> Proposed Changes.

Proposals are useful when operators notice:

  • A target no longer matches reality.
  • A description is unclear.
  • Reference media is missing or stale.
  • A new check should be added.
  • The sequence order does not match the floor route.

Approved proposals apply the change and create a new version. Reviewers can adjust a proposal before approving it. Rejected proposals remain in history with reviewer notes. When rejecting a fail-linked proposal, reviewers are prompted to raise a deviation action and can opt out when no follow-up work is needed.

When an Operator disputes a centreline target after a failed reading, the proposal is marked Fail-linked. Reviewers can filter the queue to these proposals and expand one to see each linked reading, the target in force at the time, Operator notes, photo evidence, and the total number of linked failures. Additional failures linked while review is pending appear in the same evidence panel.

Reviewing a fail-linked target proposal has a third outcome: Accept temporarily. This is for a proposed target that looks right but is worth proving before it becomes the standard. Choose a trial window of 1 to 14 days and confirm. The window starts at your organisation's default, which is 14 days unless an Admin or Owner changes it under Configure -> Organization. The new target takes effect immediately, so readings taken during the trial are judged against it, and the original target is restored automatically after expiry unless someone keeps the trial value first. Accepting temporarily also raises a review action where a Manager, Admin, or Owner records whether the target was kept or reverted — so the queue links straight to it once the trial starts.

Managers, Admins, and Owners can also complete these decisions through the AI Assistant after it shows the proposal evidence or trial history. Approve, reject, accept temporarily, keep, and revert are separate approval-card actions. Rejection requires an explicit deviation-action choice and review note, temporary acceptance takes a window of 1 to 14 days (the organisation default if none is given) and requires a review note, and keep/revert requires a resolution note. The assistant does not apply anything until the card is approved, and stale or already-decided items return a conflict instead of being overwritten.

From the failed-check sheet, an Operator enters only the replacement target for the format used by that reading. If a proposal is already pending, the sheet shows its pending target and links the new reading as further evidence; the Operator can edit the note attached to their reading when they disagree. Managers, Admins, and Owners see that their target change applies immediately rather than entering the review queue.

Archive ​

Archive checks that should no longer create new work. Do this instead of deleting when the check has historical results.

Archived checks:

  • Stop creating new check instances.
  • Remain visible in historical reporting.
  • Preserve past results and actions.

Create a replacement check when the task has changed enough that comparing future results to past results would be misleading.

Check Timeline ​

The Timeline tab in a check detail view puts readings, target-change proposals, definition versions, temporary target trials, expiry and final verdicts into one newest-first history. Load older events from the bottom as needed. Events from the same proposal or trial are labelled together, and temporary trial events link to the review action where the manager records the verdict.

Expand a version event to inspect its snapshot changes. Managers, Admins, and Owners can also roll the check back from an older permitted version event.

Use the timeline to follow a deviation from its initial reading through a proposed target, a temporary trial and the final decision, or when investigating sudden metric changes, operator confusion, or a new pattern of failed results after a check was updated.