Skip to content
AxleGuard
Demo

Operations

Keep the driver, clock and evidence together.

AxleGuard records duty events, remaining clocks, carrier-proposed corrections, driver decisions, certifications, diagnostics and transfer evidence. The workflow is implemented, but the product is not yet an FMCSA-registered ELD and does not present itself as one.

Daily views
4
log, changes, diagnostics, readiness
Driver decision
Required
accept or reject a proposed change
Current status
Development-gated
not an FMCSA-registered ELD

In the product

The screen where this work happens.

Open AxleGuard
The HOS record with driver clocks, daily duty graph and the registration boundary visible at the top of the screen.

What changes

Three outcomes that matter in the operation.

Each outcome connects what the software does to the decision a planner, loader or driver can actually make.

01

The plan and the legal clock stop disagreeing in private

The same workspace shows drive available, the duty window, break timing and the eight-day cycle for the selected driver and home-terminal date.

Why this is different

A trip plan can fit the miles and still fail the clock. Putting the record beside the work makes that conflict visible before it becomes a roadside conversation.

02

A carrier can propose a correction without rewriting history

Carrier staff submit a change request. The affected driver accepts or rejects it, and both the request and decision remain in the record.

Why this is different

Editing the original event hides who changed it. A proposal-and-decision workflow preserves the driver’s control and the sequence of evidence.

03

Readiness is a gate, not a badge

Registration, self-test, diagnostics, malfunctions, output-file evidence and physical testing are tracked as separate readiness records.

Why this is different

A polished duty graph is not an ELD registration. The current API keeps telematic and local roadside transfer locked until registration evidence is recorded; the other readiness checks remain visible but are not yet enforcement gates.

How it works

From input to answer.

The logic is visible. There is no “AI decided” step between the load and the verdict.

Important boundary

This is a development HOS and ELD record workflow, not an FMCSA-registered ELD. The current API gates telematic/local transfer on recorded registration status. Self-test, output-file validation and physical vehicle testing are tracked, but the code does not yet enforce all three as transfer prerequisites.

  1. 01

    Select the driver and date

    The record is tied to the driver’s home-terminal day and profile.

  2. 02

    Build the duty record

    Events feed the clocks, graph, break calculation and cycle total.

  3. 03

    Preserve every correction

    Original events, proposed changes and driver decisions remain distinguishable.

  4. 04

    Check the readiness record

    Registration controls telematic/local transfer today. Self-test, file validation and physical testing remain separate evidence that must be reviewed before production use.

Where to test it

Hard cases worth checking.

  • A carrier correction the driver rejects.
  • A diagnostic event that is cleared but not erased.
  • An eight-day export that includes the change history.
  • A transfer attempt while registration evidence is incomplete.