The situation
The authority carries three obligations that never pause. Its people must hold current certification, so training has to be scheduled, attended, graded and recorded. The sites it oversees must be assessed on a cycle, and what an assessment finds has to be followed until it is closed. Its shifts must stay covered every day, across several offices.
All three draw on one finite pool of people. Users span the whole organisation, roles differ from office to office, and some of the people in the system do not work there at all.
The hard part: one workforce, three calendars
Training, site assessments and the roster all consume the same people, and each arrives with its own idea of who is free. Training knows who is sitting in which class. Assessments know who is assigned to which visit. The roster knows who is on which shift. None of those views is wrong. Each one is incomplete.
The naive design gives every module its own bookings and lets it check only those. It passes every demo, because a demo exercises one module at a time. In production it will put somebody on a site visit while they are rostered on a shift and sitting in a classroom, and every module involved will report, correctly by its own lights, that nothing clashed. The clash exists only in the union of the three calendars, and in that design nothing holds the union.
Training makes it harder, because people are not the only constrained resource. An instructor teaches one class at a time and a classroom holds one class at a time. So a single training booking can fail on three separate axes: a participant who is rostered on, an instructor who is already teaching, or a room that is already taken.
Leave and absence belong in the same question. A person on leave is not free, however empty their shift pattern looks that week, and a system that books them anyway moves the clash to the morning of the class, where a person has to deal with it. Leave and absence are recorded in the platform beside the roster, not in a spreadsheet the scheduler cannot see.
The rule we held to is that an impossible booking is refused before it exists. The alternative, accept everything and run a clash report afterwards, looks gentler and is worse: by the time the report runs, the booking notifications have gone out, people have planned around them, and somebody has to unpick a decision the system was in a position to refuse. A training booking that collides with the same people’s shifts, or double-books an instructor or a classroom, is not created.
A check at booking time answers today’s question. The harder one arrives later, when a shift moves and every booking that relied on that person being free has to be looked at again. That is the case that decides the design, because a module holding only its own calendar cannot even find the bookings that depended on somebody else’s.
So availability is treated as a fact about a person, not about a module. A training booking is checked against the roster and against both of its resources before it is written, and the answer is the same whichever screen the booking starts from.
The second hard part: checklists are not forms
Each site is divided into assessment points, each with its own checklist. A checklist is a tree, not a list. Sections hold items, and an item can hold further items beneath it. The inputs are mixed: free text, a choice from a list, checkboxes, dates and times, and files, including photographs taken as evidence.
A form builder will not do, because a completed checklist is two things at once. It is the instrument that collects the data, and it is the record an assessor may later be asked to defend. A form builder is good at the first and indifferent to the second.
Rendering means walking a tree whose shape the checklist decides, so the screen cannot be laid out in advance. Validation follows the same tree, item by item, because a file is checked differently from a date and both differently from a choice. Persistence keeps one structured answer per item per assessment, stored as data rather than as a rendered page, so the assessment report can consolidate it and the answers can be read back by query rather than by eye.
File evidence is the awkward part. A photograph attached to an item three levels down belongs to that item, in that assessment. Stored against the assessment in general, it loses the question it was answering, and a photograph without its question proves very little.
Around the checklist sit the findings. Each is open or closed and tagged with a compliance classification, and an open finding can have a follow-up visit scheduled against it. Time logs record when each assessment started and ended. The assessment report brings all of it together, and an audit schedules a series of these events across a month.
Integrity by design
In an organisation whose records can be challenged, the system has to answer two questions about every record: what happened, and who could have made it happen. We treated those as one design position rather than a handful of features.
Grades are the clearest case. Once a trainer saves a grade, it is locked and the trainer cannot change it. Only the training head can amend a grade, and the amendment is logged. A certificate is only as trustworthy as the grade behind it, and a grade the person who awarded it can quietly revise is worth less than one they cannot.
Permissions follow the same logic. Access is role-based, and a user can share their own permissions with somebody else. That delegation is logged too, so the record shows who acted under whose authority. Changes to a person’s roles, changes to their details, and the activation or deactivation of their account each leave a log that can be viewed, beside access logs and error logs. Accounts carry forced password changes, email verification and two-factor authentication.
What we built
Three modules on one platform, with the same people and the same audit trail underneath all of them.
- Training and certification
- Courses, trainers and classrooms as managed resources. Scheduling with notifications on booking, attendance, grading, certificate generation, generated timetables and a course calendar inside the system. A participant who fails is rebooked through the same scheduling engine, so a resit is checked like any other booking.
- Quality control and site assessments
- Event types, categories and an event calendar held as configuration. People with the right role scheduled to carry out assessments and tests, recursive checklists with file evidence, findings with follow-ups, time logs, consolidated assessment reports, and audits that schedule a month of events.
- Shifts and rostering
- Shift types, people assigned to shift groups, leave and absence. Rosters are generated as PDF and emailed to supervisors.
Around the three: reporting, dashboards that differ by role, global system notifications, a help centre for raising issues, documentation inside the system, and compliance settings held as configuration.
Running it
The platform runs on the authority’s own infrastructure, not on ours, and we run the DevOps. We deploy to machines we do not own, inside an environment we do not control, and keep the system in production under a support agreement.
That matters more than it sounds. Plenty of studios can ship to their own cloud account. Working inside a locked-down environment, on the client’s terms, is a different discipline, and it is the one an organisation whose data cannot leave the building needs.
What this means if you are buying
This is the kind of problem to bring us when one or more of these is true of your organisation.
- Your people do more than one job.
- And the calendars for those jobs do not talk to each other, so the clash only shows up on the day.
- Your field data has structure.
- Nested questions, mixed inputs and evidence attached to a specific answer, which a form builder flattens.
- Your records have to survive being questioned.
- By an auditor, a regulator, or your own leadership, which means the system has to show who could have changed what, and not only what changed.