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

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. 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 less than 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 tap the RFID card on the reader. The tablet wakes up and recognises the driver. The shift is open.
2. If prompted (roughly one shift in seven), take a quick selfie. Confirms the person who tapped the card is the person actually driving. Most shifts skip this step.
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.
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 taps in, 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

We’re splitting the build into a v1 (ships at the August 2026 pilot) and a v2 (starts after v1 is in production). The split is deliberate — v1 must work standalone and deliver real value on its own, without depending on anything else being ready.

Anything that requires hardware we don’t yet have, integrations we haven’t built, or coordination with another team’s timeline — that’s v2. v1 is what we can build, ship, and operate by ourselves on a known timeline.

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 selfie?

  Current plan is to challenge roughly one shift in seven, randomly. Too often and operators get annoyed. Too rare and we lose the deterrent effect. Is “every seventh shift on average” the right rate, or should it be higher / lower at our sites? Should it adapt to risk signals (e.g. unfamiliar driver-truck combination)?

• 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. RFID tap is fast. Selfie challenge is a few seconds. Dashboard photo + two typed values is the slowest step. Five-item walkaround taps are quick. If you’ve watched real drivers use anything similar, what was the part they pushed back on most?