Sentinel_Cab — Process View

The operational gaps we’re closing

Two distinct gaps in the current logsheet workflow drive this build — one is about identity and evidence, the other is about admin time burden. Both come from the same root cause: the current workflow is paper-based at origin and only becomes digital after a manual transcription step that costs time and loses fidelity.

Gap 1 — Identity and evidence

The current logsheet workflow — inherited from the legacy HALO system — produces a complete record of what happened during each shift (operating, loading, dumping, delays, downtime) with start times, end times, codes, and durations. What it does not produce, despite having two columns reserved for exactly this purpose, is any evidence of who performed each activity. The Verified By and Verified At fields exist in every row but are populated in none of them.

This creates a series of operational problems that supervisors and PJOs/GMs experience daily but cannot easily fix within the existing workflow:

• Shift-attribution disputes. When fuel usage, mechanical damage, or productivity outliers are traced back to a specific shift, the driver named in the logsheet can credibly deny they were the one operating the truck during that shift. No evidence supports either side.
• Handover ambiguity. When two drivers swap on the same truck mid-shift, neither the system nor the supervisor can prove who was responsible for which portion of the timeline. Coaching becomes guesswork.
• Breakdown-reassignment record gaps. When a truck breaks down and a driver moves to a different truck, the connection between the two shift records is informal — reconstructed after the fact from memory, radio chatter, or whoever happened to write it down.
• Pre-existing-fault deniability. When a fault is discovered during operation, the driver can credibly claim the warning was already on when they started. Without a shift-start record, the prior-shift driver bears the assumption.
• Audit and compliance weakness. The logsheet exists but cannot satisfy any audit that asks “prove this person did this work at this time on this asset.” The narrative is there; the evidence is not.

Gap 2 — Admin time burden from paper-to-system transcription

Today’s logsheet workflow is paper-based at origin. Drivers fill out the logsheet by hand during the shift; at the end of the operational day, those paper sheets move to the site admin, who has to manually type every row into the reporting system. Current estimate: 3–5 hours per admin per day are spent on this transcription step alone. That is 3–5 hours of professional time spent moving data from one format to another, with no value added in the process and several risks of fidelity loss along the way:

• Direct labour cost. 3–5 hours daily, across the operational year, per site — a meaningful share of the site admin’s working day spent on a mechanical, non-judgement task.
• Transcription errors. Times, codes, truck IDs, and driver names get mis-keyed; handwriting on the paper logsheet is sometimes ambiguous; the reporting system gets data that does not exactly match what the driver wrote.
• Reporting lag. The reporting system is always at least a day behind reality, because transcription only happens after the shift closes. Supervisors who want to know what happened during the current shift cannot use the reporting system to find out.
• No realistic path to faster reporting. The bottleneck is human typing speed; throwing more admin hours at the problem does not scale, and asking drivers to type the logsheets themselves on a PC at the end of shift creates its own friction.
• Admin attention diverted from higher-value work. Driver records, code maintenance, exception follow-up, site coordination — all the things the admin should be doing instead of typing — get squeezed.

Sentinel_Cab v1 closes both gaps with a single intervention: the logsheet is digital at origin. Drivers tap on the tablet during their shift instead of writing on paper; the data flows directly to the backend; the admin’s 3–5 hour transcription step collapses to a few minutes of exporting an already-prepared CSV that matches the existing reporting system’s expected shape (per SCP-7). The admin’s time is freed up for the higher-value work that Sentinel_Cab also requires (driver enrollment, code-library maintenance, configuration), and the reporting system gains access to within-shift data instead of next-day-only data.

Every shift also produces a PIN entry, a selfie photo of the driver, a timestamped dashboard photo with odometer and fuel readings, a five-item walkaround result, and a continuous activity timeline with geofence-tagged locations — closing the identity / evidence gap at the same time. The system does not interpret this evidence in v1; it captures and stores it, makes it visible to supervisors on demand, and exports it in a CSV shape compatible with the existing reporting pipeline.

Who’s involved and what they own

Sentinel_Cab introduces no new permanent roles. Four existing roles plus the system itself participate in the v1 processes. Each role’s scope of authority is bounded by what they can already do within current site operations — the system does not grant or require new permissions outside of what the role already exercises.

Process catalogue

Seven processes cover the full v1 operational scope. Four are driver-facing and run during shifts; three are supervisor / admin-facing and run on a different cadence. Each process is detailed in the next section.

Each process in detail

Where the control points sit

Every control point in v1 produces immutable evidence at the moment it fires. The full set, listed by where they appear in the day-to-day flow:

• At enrollment (SCP-1): baseline photo set must contain at least 3 acceptable photos; admin identity captured for every action; PIN handoff procedure follows site standard.
• At shift start (SCP-2): PIN entry validated against hashed credential; selfie capture cannot be skipped; dashboard photo + odometer + fuel readings cannot be skipped; walkaround items cannot be skipped; PIN lockout after 5 failed attempts.
• During the shift (SCP-3): activity events tagged with current geofence position; out-of-zone activity flagged for review without blocking work; random in-shift selfie captured roughly 1 shift in 7.
• At shift end (SCP-4): end-reason picked from controlled list; continuation windows enforced server-side; continuation links are immutable once created.
• In supervisor review (SCP-5, SCP-6): every action carries the supervisor’s identity and timestamp; resolutions are immutable; corrections create new events referencing the original.
• In reporting (SCP-7): CSV format locked by default; export operations logged with identity and timestamp; data scope respects role permissions.

For audit purposes, every action that could be relevant in a future dispute — a shift starting, a driver authenticating, a photo captured, an activity logged, an exception resolved, a verification recorded — produces a record that names who did it, when, and against what. None of these records can be deleted or modified once written; the only way to correct an error is to add a new record that supersedes the original, with the supervisor’s reasoning in writing.

What changes for existing roles

The goal is for Sentinel_Cab to feel like a digitisation of existing operational reality, not the imposition of new responsibilities. The realistic deltas for each role:

Drivers

• Replaces the existing manual logsheet entries with tablet taps. Equivalent total interaction time.
• New: a 4-digit PIN to remember and a brief selfie at the start of each shift.
• New: a dashboard photo + odometer / fuel entry at shift start (replaces verbal handover for these readings).
• Same: the walkaround check itself — cabin, engine, tyres, vessel, walkaround — is unchanged in substance; only the recording method differs.
• Same: all operational actions (driving, loading, queueing, etc.) are unchanged. The tablet logs what the driver is doing; it does not direct or restrict it.

Supervisors

• New: exception inbox review (~10–30 minutes per shift, dropping as the team settles in).
• New: PIN unlock and reset (rare, ~once per supervisor per week expected).
• New: manual identity verification on disputed shifts (ad-hoc, rare in normal operation).
• Replaces: paper logsheet review — the digital dashboard surfaces the same information in a more navigable form.
• Replaces: manual identity confirmation — was previously asking the driver or relying on radio chatter; now reviewing stored evidence.

Admin (per site)

• Eliminates: 3–5 hours per day of paper-to-system logsheet transcription. This is the single largest time impact of Sentinel_Cab on any existing role. The admin no longer types driver activity into the reporting system manually; the daily CSV export (SCP-7) takes a few minutes and feeds the same downstream pipeline.
• New: driver enrollment ceremony (SCP-1) for each new driver — ~1–2 hours per driver, but only for new hires, not daily.
• New: activity-code library maintenance for the site — expected to be infrequent after initial setup.
• New: truck assignment management — updates as fleet changes.
• Replaces: any existing driver-record administration that lived in spreadsheets or paper files.
• Net effect: a meaningful reduction in daily admin workload, with the freed-up time available for higher-value coordination and follow-up work.

PJO/GM / Site Manager

• New: weekly review of process-performance metrics (exception rate, verification rate, average shift duration trend).
• New: adjudication on escalated identity disputes.
• New: approval for changes to site-scoped configuration (new activity codes, zone changes, supervisor account changes).
• Same: overall accountability for operational performance is unchanged; the data available to support that accountability is richer.

What I need the BP team to validate

These are the process-level assumptions baked into the v1 design that I want the Business Process team and the PJOs/GMs to push back on before we lock the build. Anything that is wrong here will create operational friction at the pilot.

• Roles Is the role assignment correct?

  Each process is owned by either Driver, Supervisor, Admin, or PJO/GM. Are those the right ownership lines for our sites? Is there a role I’m missing — HSE, dispatcher, foreman — that should be in the loop on any of these processes? Specifically curious about SCP-5 (exception resolution) and SCP-6 (identity verification) — is the supervisor the right owner, or should some categories of exception go directly to PJO/GM?

• Enrollment SCP-1 in practice.

  The estimated 1–2 hours per new driver for enrollment assumes the admin has time and a controlled photo-capture environment. Is that realistic? Should we be enrolling in batches (e.g. all new hires together) rather than one at a time? Who at each site has the bandwidth to be the enrollment admin?

• Handover The 90-minute handover window.

  SCP-4 Variant B gives the truck a 90-minute window for an incoming driver to take over after the outgoing one taps out. Is 90 minutes the right number? Too long and the truck is “in limbo” for too long; too short and a real handover that gets delayed by a few minutes triggers a false exception.

• Breakdown The 60-minute breakdown reassignment window.

  SCP-4 Variant C gives the driver 60 minutes to start a new shift on a different truck after a breakdown. In reality, how long does it usually take between a truck going down and a driver being assigned to a replacement? If it’s typically longer than 60 minutes, the window needs to expand; if it’s usually faster, we can tighten it.

• Exception load SCP-5 review capacity.

  Estimating ~10–30 minutes per shift for exception review. Is the supervisor going to have that time, given everything else they do during a shift? If not, do we need to triage exceptions into “must review during shift” vs “can wait for end-of-shift review”?

• SLA Exception resolution SLA.

  The proposed SLA is p50 ≤ 4 hours, auto-escalate to PJO/GM after 24h unresolved. Is that the right target? Some exceptions are urgent (e.g. truck moving without an active shift suggests theft or unauthorised use); others can wait days (e.g. walkaround Pass that should have been Fail). Should the SLA be per-exception-type rather than universal?

• Reporting Who actually reads the daily CSV.

  SCP-7 assumes the existing reporting pipeline consumes the HALO-shape CSV. Who downstream actually uses it today — KPI rollup, compliance report, payroll, the customer? If we know who the real consumers are, we can confirm the column shape is right and surface any format requirements we don’t know about.

• Admin time The 3–5 hour admin transcription estimate.

  The current estimate is 3–5 hours per admin per day spent typing paper logsheets into the reporting system. Is that the right number at each site, or does it vary significantly between BEK, TIS, and TCM? Is anything bundled into that number that won’t actually be eliminated by Sentinel_Cab (e.g. summary reports, payroll calculations, manual approvals)? Getting this number right matters for the business case and for setting realistic expectations with the admin team about what their day looks like after the pilot.

• Disputes What happens after SCP-6 finds a real dispute.

  Sentinel_Cab’s scope ends when the verification status is recorded. The HR / disciplinary follow-up is outside the system. Is there a clear, existing site process for handling a confirmed identity dispute, or does Sentinel_Cab’s ability to surface these mean we need to define one alongside?

• Process owners Who is the process owner for each of these seven processes at each site?

  For ISO and operational governance, each process needs a named owner who is accountable for its performance. Who are the right people at Adong, TIS, and TCM? Are they the same person across processes, or split by domain (supervisor for driver-facing, admin for setup, PJO/GM for governance)?