Sentinel_Cab

Why we’re building this

Every coal hauling operation needs a logsheet. Who drove which truck, when did they start, when did they finish, what were they doing in between — operating, loading at the ROM, dumping at the hopper, queueing, idle for shift change, down for maintenance.

The system most of our sites have used for this is called HALO. It captures all of that activity well. But it has one structural gap: every row in the HALO logsheet has a column called Verified By and a column called Verified At, and across hundreds of rows of real shift data, those columns sit empty. The system was designed for identity verification but never delivered it.

That gap creates real, ongoing problems:

• Disputes about who drove which shift — “that wasn’t me, I didn’t do that”
• Fuel usage that can’t be tied back to a specific operator
• Mechanical damage where nobody can be held accountable
• No reliable basis to coach drivers on performance, because we can’t prove what each individual actually did

There’s a second, parallel problem worth naming explicitly: the current workflow is paper at origin. Drivers write on a paper logsheet during the shift; site admins then spend an estimated 3 to 5 hours every day typing those paper sheets into the reporting system. That’s 3–5 hours of professional time per admin per day spent on mechanical data entry — with no value added and several risks of transcription error along the way. The new system makes the logsheet digital from the moment the driver taps it; the admin’s daily transcription burden collapses to a few minutes of exporting an already-prepared CSV.

Banpu has stopped developing HALO. So we’re building the system that picks up where it left off — same activity vocabulary the operators already know, same logsheet shape the supervisors are trained to read, but with the identity column that was always supposed to be there actually filled in, and without the manual transcription step that consumes 3–5 hours of admin time every day. That’s Sentinel_Cab.

The core idea, in four parts

Four things make Sentinel_Cab different from a simple activity logger. All four need to hold together for the system to deliver on its promise.

What a driver’s shift looks like

The whole flow is designed to take roughly two minutes at shift start, almost nothing during the shift itself, and under a minute at shift end. Below is a typical shift from the driver’s point of view.

1. Climb into the cab and wake the tablet. A numeric keypad appears. The driver types their 4-digit PIN.
2. Front camera fires automatically — take a selfie. Driver holds still for about a second. The photo is captured and uploaded with the shift record. No automated comparison runs yet — the photo sits in the shift record as evidence. Supervisors can manually verify any shift later by opening it in the dashboard and seeing the photo alongside the driver’s enrolled baseline.
3. Take a photo of the dashboard cluster. Type the odometer reading and the fuel gauge percentage into two fields under the photo preview. Single photo captures both gauges because they sit on the same cluster.
4. Walk through five quick check items. Cabin, engine, tyres, vessel, walkaround. Each one a Pass / Fail tap. Anything failed alerts the supervisor.
5. Truck is ready. Start driving. During the shift, tap to log what’s happening — queueing for ROM, loading, transit to hopper, dumping, etc. Each tap is one event with a start and end time. Roughly once every seven shifts, the system asks for a second quick selfie — same as the start-of-shift one, just another photo for the evidence trail.
6. If something unusual happens, the tablet handles it. Truck breaks down mid-shift → tap “end shift, truck breakdown” and the system gives you a one-hour window to start a new shift on a different truck without losing your shift counter. Driver handover mid-shift → the incoming driver does the PIN + selfie flow, the outgoing driver taps out, and the truck’s activity timeline continues uninterrupted.
7. End of shift: tap End Shift, confirm the reason, tap off. Everything you did during the shift is now in the supervisor’s dashboard with your identity stamped on every row.

What a supervisor sees

Supervisors don’t read every row of the logsheet — they couldn’t even if they wanted to, with thousands of activity events per day across the fleet. The dashboard is built around exceptions, not everything: surface the small fraction of activity that actually needs a human to look at it.

The four screens that matter

• Live view. Every truck, every active shift, who’s driving, what they’re doing right now, and how strongly their identity is verified. Glanceable at a glance.
• Exception inbox. The system flags rows that need attention — a truck moving without an active shift, a selfie that wasn’t taken in time, a driver whose RFID card has been used in unusual patterns, an activity logged outside any known operational zone. Supervisor reviews, resolves, moves on.
• Selfie review queue. Selfies the system isn’t confident about — bad lighting, partial face, ambiguous match — land here for a quick human check.
• Logsheet export. Daily or weekly CSV in the same shape the supervisor is used to from the old system, but with the identity columns no longer empty. Drop it into whatever downstream report or KPI rollup is already in use.

The shape of the export deliberately matches the old HALO logsheet column-for-column. Supervisors trained on HALO can read it without retraining, and any existing report that consumed the HALO output keeps working.

What ships first, what comes later

The build is split into three phases. Each one is independently shippable and delivers real value on its own. The split is deliberate — v1 has no machine learning, no extra hardware, no dependencies on other systems being ready. It’s the simplest possible thing that closes the identity-evidence gap.

Each phase makes the next one easier. v1 captures the data v1.5 needs to train and validate against. v1 + v1.5 together prove out the identity layer that justifies the v2 hardware spend. We never have to rebuild what came before; we only add to it.

Where we’re deploying it

Adong (BEK) is the pilot site — 10 trucks for 30 days starting August 2026, then expansion to the full Adong cohort if the pilot is successful.

After Adong stabilises, the same product deploys to the other two Runa concessions, TIS and TCM, in sequence. Same software, same hardware spec, site-specific things configured per location.

Cross-customer expansion — selling Sentinel_Cab to coal-hauling contractors outside Runa — is not part of v1. That’s a separate commercial conversation for later. v1’s job is to be excellent for three Runa sites.

What “the pilot succeeded” would mean

• The tablet stays up and working on every truck through every shift, for 30 consecutive days.
• Every shift has correctly captured driver identity — no silent corruption, no missed taps, no orphan shifts.
• Supervisors actually use the dashboard — not just open it once, but resolve exceptions, review selfies, export logsheets on a routine basis.
• The CSV export looks correct to whoever consumes it downstream.

If those four things hold for 30 days, we expand to the rest of the Adong fleet and start planning the TIS deployment. If any of them fail, we find out why, fix the right thing, and try again before expanding.

Where I need your input

These are the things I’d most like the team’s eyes on before we lock the v1 build. Anything you push back on or add to here will save us pain later.

• Vocabulary The full activity code list.

  The old HALO logsheet uses standardised codes (CD0017 for production, CD3013 for hopper problem, CD2002 for daily inspection, and so on). I have a sample with about fourteen codes in it, but production HALO almost certainly used many more. If you have access to the full list, or remember codes that aren’t in our sample, I want them.

• Operations Loading and dumping locations.

  The HALO sample shows free-text location names against loading and dumping events — “ROM Ulin”, “ROM Meranti”, “HOPPER”. Are these always the same fixed set of locations at each site, or do supervisors actually type them in freely each shift? Determines whether the tablet picks from a list or accepts text.

• Handover Shift change — automatic or manual?

  When one driver hands off to the next mid-shift on the same truck, should the outgoing driver have to manually tap “Shift Change” before tapping out, or should the system detect it automatically from the pattern of taps? Both work, but they create different UX.

• Verification How often should we ask for a random in-shift selfie?

  Mandatory selfie at shift start is locked. On top of that, the plan is to ask for a random second selfie roughly one shift in seven. Too often and operators get annoyed. Too rare and we lose the continuing-presence check. Is “every seventh shift on average” the right rate, or should it be higher / lower at our sites?

• Enrollment Capturing good baseline photos during onboarding.

  When a new driver is added, the supervisor captures 3–5 baseline selfies for that driver — same camera, neutral pose, good light. Those photos sit in the system unused in v1 and become the ground truth for automated matching in v1.5. What would make this enrollment step painful in practice — supervisor time, lighting at the office, drivers in PPE, anything else?

• Reassignment The breakdown window.

  When a truck breaks down mid-shift, we give the driver a one-hour window to start a new shift on a different truck without losing their shift counter. Is sixty minutes realistic given how mine workshops actually swap trucks, or should it be longer / shorter?

• Friction What’s going to annoy drivers most.

  Honest answers welcome. PIN entry is a few seconds. Selfie is a couple of seconds. Dashboard photo + two typed values is the slowest step. Five-item walkaround taps are quick. Total time at shift start is roughly two minutes. If you’ve watched real drivers use anything similar, what was the part they pushed back on most — the typing, the photos, the wait, something else?