Owner
The person who answers for compliance
Everything, including the limits themselves
Security and access
Who can change a limit, and who cannot.
An axle limit is a legal position, so the question is not only whether the number is right. It is who is allowed to move it, whether anyone can move it quietly, and what you can prove about it two years from now.
- Four roles
- Every change recorded before and after
- No override on an over-limit load
Four roles
Four kinds of person touch a load, and they need four different amounts of authority.
This is not an organisation chart. It is the shortest list that lets a yard work without anyone holding more authority than their job actually needs.
Dispatcher
The person who builds and sends loads
Plan, solve, route and dispatch — but not rewrite a rule
Driver
The person with the load
See their own loads and report what happened to them
Viewer
Safety, insurance, a customer, an auditor
Read, and nothing else, no matter how they ask
| Can they | Owner | Dispatcher | Driver | Viewer |
|---|---|---|---|---|
| Open a load and read its verdict | Yes | Yes | own only | Yes |
| Build a load and move freight on the deck | Yes | Yes | No | No |
| Add or correct a tractor or a trailer | Yes | Yes | No | No |
| Change an axle limit or a jurisdiction rule | Yes | No | No | No |
| Dispatch a load | Yes | Yes | No | No |
| Change a load's status from the yard | Yes | Yes | own only | No |
| Create a read-only link for someone outside | Yes | Yes | No | No |
| Invite a person, or change what they can do | Yes | No | No | No |
| Read the record of who changed what | Yes | Yes | No | Yes |
| Delete a load | Yes | No | No | No |
"Own only" means the loads that person is actually carrying, and nothing else on the board.
The same table, counted up
Of the 10 actions above, how many each role may take
actions- Owner10 actions
Including the limits themselves, which is why a yard usually has one
- Dispatcher7 actions
Everything except rewriting a rule, inviting a person or deleting a load
- Driver2 actions
Both of them limited to the loads that driver is actually carrying
- Viewer2 actions
Read a load, read the record of changes, and nothing else
Counted from the rows in the table rather than written separately, so the two cannot disagree. Every one of these is checked again when the change is attempted, which is the difference between a screen that looks safe and a system that is.
A driver's login cannot change an axle limit, however it asks. Hiding the button is presentation, not permission.
Where the rule is enforced
Hiding a control is not the same as refusing a change.
This is the difference between a screen that looks safe and a system that is. Every rule on this page is checked again at the moment a change is attempted.
The button is not the control
Hiding a control from someone is presentation, not permission. Every rule is checked again when a change is attempted. A request outside that person's role is refused, even if they find another way to send it.
An over-limit load cannot be dispatched
This is not a warning banner someone can dismiss. A load that fails on an axle group is refused when somebody tries to send it, and the attempt is recorded with the name of the person who made it. The way past it is to fix the load or get a permit.
Status moves in one direction only
A load goes through a defined lifecycle, and a jump that does not belong in that lifecycle is refused. That is what keeps the history readable two years later, when somebody needs to know what state the load was actually in.
There is no override
We are asked for one on most calls. An override that exists is used by somebody under pressure at the end of a bad shift, and then it becomes the only thing anyone remembers about the system. Fix the load, or take the permit route.
Signing in
One person, one account, on a screen four people share.
A yard terminal is used by whoever is standing at it. That is the situation the sign-in behaviour is designed around, not an office desk with one person at it all day.
Everyone has their own account
No shared logins, because a change made by a shared login is a change nobody made. The name on the audit record has to belong to a person.
A session ends on its own
Sessions expire rather than lasting until somebody remembers to sign out. On a shared yard screen, walking away is not the same as handing over your authority.
Signing out ends it everywhere
The session stops being usable, not just on the screen in front of you. A device left behind at a terminal cannot keep acting as you.
Signing in is recorded
Along with every change made afterwards. Not to watch people, but because a record that starts halfway through a shift does not settle anything.
The record
Every change, with what it looked like before.
Most systems record that something changed. The useful question in a dispute is what it changed from, and who was holding the pen. That is what gets written here, on every single change.
- Who made the change, by name, not by a shared login
- What they changed, down to the individual record
- What the record looked like before they touched it
- What it looked like afterwards
- The moment it happened, in the time zone the load belongs to
- A way back to the record itself, in whatever state it is in now
Refused attempts are recorded too. A dispatch that was stopped because the load was over is part of the story of that load, and it is the part that proves the control was working.
axleguard.app/audit
Showing somebody one load
A customer should not need an account to see that their load left legal.
Read-only links exist so that proof can leave the building without authority leaving with it. They are the narrowest thing we could build that still answers the question.
- A single load, not an account and not a list
- Read-only, with no way to change a status, a limit or a position
- Expires, and can be withdrawn the moment it stops being useful
- Every link that is created is recorded, with who created it
Your records
What is held, what is not, where it lives and how it leaves.
Four plain answers. If any of them is wrong for your policy, that is an Enterprise conversation rather than something to discover later.
What is held
Your equipment, your loads, your routes, your rule sets, the people on the account and the record of changes to all of it. Nothing about a driver beyond what is needed to plan and dispatch a load.
What is not held
No payment details, at any point, on the site or in the product. Nothing is sold, nothing is shared with a third party for advertising, and demonstration accounts are not populated from anybody else's freight.
Where it lives
On the Pilot and Fleet plans, on infrastructure we run. On Enterprise, wherever your policy says it has to live, including your own building, with retention set to your schedule rather than ours.
How it leaves
Ask, and your records come back to you in a form you can read and keep, and the copies here are removed. A deleted load's audit trail survives the load, because a compliance record that vanishes with the thing it describes is not a compliance record.
Deployment controls
Roles, refusals and the audit trail are part of every workspace. Single sign-on, data residency and multi-organisation separation are configured under an Enterprise scope during rollout.
What gets asked
Six questions from the person who signs off on this.
A compliance record that vanishes along with the load it describes is not a compliance record.
01Can a driver change a limit if they really want to?
No. A driver's account cannot change a limit through the screen, and it cannot change one by asking the system directly either, because the rule is checked where the change happens rather than where the button is. The attempt is refused and recorded.
02Who can override an over-limit load?
Nobody dispatches one. The load has to become legal, either by moving the freight or by going down the permit pathway. That is deliberate: an override that exists gets used at four in the afternoon by somebody under pressure, and then it is the only thing anyone remembers about the system.
03What does the audit trail actually give us in a dispute?
The state of the load before a change, the state after it, who made it and when. A dispute two years later stops being a disagreement about recollections and becomes a question of reading a record.
04Can a customer see one load without an account?
Yes, through a read-only link for that single load. They cannot see anything else, they cannot change anything, the link expires, and it can be withdrawn. Creating one is recorded like any other change.
05Can we review access and data handling before rollout?
Yes. Start with the access model, audit trail, refusal behaviour, retention and export path on this page. Enterprise requirements such as single sign-on, certification evidence and data residency are written into the implementation scope before the rollout is approved.
06How are additional carrier environments handled?
Each rollout records where the data lives, who administers it, how long it is retained and how it is exported. No second carrier is added to an existing workspace by default; any shared infrastructure has to be agreed explicitly in the implementation scope.
Next step
Bring your compliance manager to the call.
They will want to try to change a limit from an account that should not be able to. That is a good use of ten minutes, and we would rather they did it in front of us.