For quality and food-safety leads

A failed check should create work, not a note nobody reads.

Procedures are published in versions, run step by step on a phone, and every failure creates linked corrective work so the fix can be traced.

What we can state plainly

Each line here is something the running system does today, not an ambition.

  • Procedures move through draft, published and retired versions.
  • A completed run keeps a snapshot of the version used, so history stays accurate.
  • Failed steps require a note and can require a photo before completion.
  • Failed inspections generate linked corrective work automatically.

How it works in practice

  1. 1

    Publish

    Build the procedure with sections, steps and evidence rules, then publish it.

  2. 2

    Run

    Branch staff complete it on a phone, with a typed signature where required.

  3. 3

    Escalate

    Failures create corrective work linked back to the step that failed.

  4. 4

    Report

    Completion rates, failed steps and repeat failures are reported per branch.

What you get

  • Versioned procedures

    Edit safely: published runs keep the version they were completed on.

  • Nested steps

    Sections and sub-steps for longer opening and closing routines.

  • Evidence

    Photos and notes stored privately, released only to authorised viewers.

  • Scheduled checks

    Recurring inspections with due dates and overdue visibility.

The screens behind this page

Every entry names a real screen in the application and its state today.

  • /checklistsAvailable today

    Opening, closing, temperature and sanitation procedures

    Available today: published procedures with evidence and corrective actions.

    Data shown: Sample opening and temperature checks

  • /inspectionsAvailable today

    Scheduled inspections with linked corrective work

    Available today: failed inspections create linked corrective work.

    Data shown: Sample scheduled and overdue inspections

  • /queueAvailable today

    Shared queue with priority, owner and response clock

    Available today: one queue with owners and response clocks.

    Data shown: Sample work queue

What's included

What you get on day one, and what we connect to your own systems during onboarding.

Included

  • Versioned procedures, runs, evidence and corrective work
  • Scheduled and overdue inspections

Connected during setup

  • Temperature probes and sensors are not read automatically; readings are entered by staff

Common questions

Do you read temperatures from sensors?
No. Readings are entered by staff today. Sensor feeds are not built and we do not claim them.
Can we change a procedure without breaking past records?
Yes. Editing creates a new version; completed runs keep the version they used.

How access and records are handled

Each organisation's records are separated in the database, and people only see the branches they are assigned to. Status changes, approvals, rejections and verifications are recorded with who did them and when. We do not claim any external certification or audit at this stage; if you need a formal security review, ask us and we will tell you exactly what exists today.

Walk this part of the system yourself.

The demonstration workspace is loaded with clearly labelled sample branches and records, so you can test this workflow end to end before deciding anything.