CleanCore · Traceability
Prove the cleaning was done — and who did it
Every clean, verification, exclusion and defect is written once, in the same transaction as the act itself, so the record cannot be edited into a different past.
The problem this solves
A cleaning contract is not judged on the cleaning. It is judged on what you can show at 06:00, when someone asks whether a particular bus, a particular washroom or a particular platform was done last night, and by whom.
Most systems answer that from live rows — the current state of a record, which a later edit quietly rewrites. Ask them what the record said last month and there is no such thing as last month. CleanCore keeps an append-only ledger instead, so the history you show a client in March is the history that existed in February.
The names are captured at the time and snapshotted, so a person leaving, changing role or being renamed never changes what the history says about the night they worked.
Worked example
06:05. The depot manager asks whether bus 2214 was cleaned overnight.
- 1
Open the bus
Its record opens on the clean history — every event against that vehicle, newest first, with the mean interval between cleans and whether it is overdue against its own expected cadence.
- 2
Read the three actors
Cleaned by, verified by, inspected by: three named people, each captured when they acted rather than looked up now.
- 3
Open the photographs
Evidence hangs off the event, not off a form, and the count shown is a count of the documents that exist rather than a number the phone claimed.
- 4
Check the presence
The zone was verified against a real checkpoint scan of that checkpoint, inside the round window, whose own validation passed. A scan id invented by a phone is refused.
The answer takes about fifteen seconds, and every part of it can be defended afterwards.
Capabilities
What traceability gives you
All 7 of these are in the product today. Each one names what it is built on.
Append-only clean history
LiveEvery clean, verification, exclusion and defect written once, in the same transaction as the act itself, so the record cannot be edited into a different past.
Who cleaned it, by name
LiveCleaned by, verified by, inspected by — each a named person captured at the time, snapshotted so a later rename never changes what the history says.
Photographic evidence
LivePhotos attach to the event, not to a form: EXIF stripped, virus-scanned where enabled, and counted from the documents that exist rather than from a number the device claims.
Proof of presence, not proof of tapping
LiveA zone is verified only against a real checkpoint scan of that checkpoint, inside the round window, whose own validation passed. A fabricated scan id is refused.
History per bus, per site, per area
LiveOne timeline for any subject, with the mean interval between cleans and whether it is overdue against its own expected cadence.
Scope of works, run as a round
LiveA site scope holds its areas in sequence and each area its tasks; a round opens a checklist row per task and a verification per area, and ends with the areas it could not close written out as exceptions and the completion percent they produce.
Periodic and deep-clean cadence
LiveQuarterly carpet, annual windows, anything on an interval: each task carries its interval in days and its next due date, and the worker advances the date and raises the notification when it falls due rather than waiting for somebody to open a screen.
What backs these claims
Each capability names the decision record, module, route or table it is built on. Ask us for any of them in an evaluation and we will walk you through the code.
- Append-only clean history
- ADR 0052 · src/server/imss-clean-history.ts · imss_cleaning_events
- Who cleaned it, by name
- src/server/imss-clean-history.ts resolveActorSnapshot · OpsBusRecord.tsx
- Photographic evidence
- src/server/imss-clean-evidence.ts · ADR 0023
- Proof of presence, not proof of tapping
- src/server/imss-cleaning-round.ts requireZoneScan
- History per bus, per site, per area
- GET /api/imss/clean-history · OpsCleaningHistory.tsx · client-portal/bus
- Scope of works, run as a round
- src/server/imss-cleaning-round.ts evaluateRound · imss_cleaning_scope_areas imss_cleaning_zone_verifications · patrol/cleaning-rounds · OpsCleaningServices.tsx
- Periodic and deep-clean cadence
- src/server/imss-jobs/periodic-cleaning.ts sweepPeriodicCleaning · imss_periodic_cleaning_tasks · v3 cleaning_periodic
Where this sits
Back to
CleanCore — every capability in one place
The whole module: what is live, what is committed, what is only on the roadmap.
Read next
Cleaning KPIs and abatement, computed rather than compiled
The KPI is worked out on the server from the inspections and non-conformances that exist, and the abatement arithmetic is shown to the customer in full.
Twenty minutes on a real contract.
Real data, four logins, nothing typed on the day — including the parts we have not built, which we will point out ourselves.