Driving Rules

What this chapter covers

A rule set is the driving policy a mission runs under: how fast the truck may go, when it may drive at night, where it may refuel, where it may not stop, and how its hours of service are shaped. This chapter describes what a rule set holds, how a mission inherits one, why edits take effect immediately on active missions (unlike the frozen acceptance region), and what enforcement raises when a rule is broken. It connects the mission plan to the alerts of Part 6.

The picture

The chain runs most-specific to most-general: the first policy that resolves wins.

What a rule set holds

A rule set is a named driving policy with four groups of settings.

Speed. A maximum speed and a tolerance above it. The tolerance is the grace band before an over-speed becomes an alert. When no maximum is set, speed is not enforced.

Night driving. A night window defined by a start and end hour — defaulting to 22:00–05:00 in the tenant's timezone — and a mode: forbid (no night driving), allow (night driving is fine), or reduced_speed (a recognised night setting). The defaults target the corridor's realities.

Hours of service. The inputs that shape how long a driver may work:

• maximum continuous driving before a break — default 4.5 hours;
• required break length — default 45 minutes;
• maximum daily driving — default 9 hours;
• required daily rest — default 11 hours.

These feed the rest-time modelling in the arrival estimate, described in progression and ETA.

Places. Two lists of waypoints attached to the rule set:

• authorized refueling stations — a whitelist; a fill anywhere else is a violation; and
• prohibited stop locations — a blacklist; a stop that begins inside one of these geofences is a violation.

Both are real references to waypoints, so they stay meaningful as the map evolves.

Inheritance

A mission's policy is resolved once, at creation, walking the chain most-specific to most-general and stopping at the first level that names a rule set:

1. an explicit choice the operator made for this mission — validated to the tenant before it is accepted;
2. otherwise the template the mission was built from;
3. otherwise the client's default;
4. otherwise the corridor's default — honored only when that rule set belongs to the mission's own fleet, since a corridor can be shared across fleets and its default may point at another tenant's policy;
5. otherwise the tenant default — the single fall-back policy every tenant has.

The resolved rule set is stored on the mission. When one of the first four levels names a policy, that exact rule set is pinned to the mission, so re-pointing a client's or corridor's default later does not rewrite a mission already dispatched. When none of them does, the mission records no explicit rule set and the engine reads the tenant default at run time — so an edit to the tenant default's own contents reaches those missions live, without anything being re-resolved.

The creation wizard exposes this as the "Règles de conduite" selector. Its default inherit option names the policy the chain would apply — showing the template's or the client's rule set by name when one is set — and an operator can override it with any named rule set for this mission alone.

Live, not frozen

Here is the deliberate contrast with the acceptance region. A mission carries two kinds of plan, and they are treated as opposites on purpose:

A mission's geometry is frozen at creation because an open deviation references it. A mission's policy is live: rule-set edits take effect immediately on active missions, with no snapshot. If a dispatcher bans a fuel station today, it is banned for every truck already on the road today. Policy is meant to bite the moment it changes; geometry must stay stable so incidents keep their meaning. The two are different because they serve different masters — one is a live instruction, the other is a measurement baseline.

What enforcement raises

Enforcement reads the applicable rule set and its waypoint lists live, and raises alerts through the same pipeline that carries every other vehicle event:

• Speeding — the truck exceeds the maximum plus tolerance.
• Night-driving violation — the truck is moving during the night window under a policy that forbids it.
• Unauthorized refuel — a fuel fill happens at a station outside the rule set's authorized whitelist. Korido already recovers where a fill happened, so an off-whitelist fill is caught — even at a genuine fuel station that simply sits off this mission's list.
• Prohibited stop — a stop begins inside a prohibited-stop waypoint's geofence.

Each of these is a detector emitting an event; how those events reach a person is the subject of Part 6.

Edge cases

• A fuel station banned mid-mission. Because policy is live, a station removed from the whitelist while a truck is en route is enforced from that moment; a fill there afterwards is an off-whitelist violation even though it was permitted at dispatch.
• No maximum speed set. A rule set without a maximum speed simply does not enforce speeding — the field is optional, and its absence means "no limit configured," not "zero."
• Reduced-speed night mode. At the enforcement boundary a night policy resolves to either forbid or allow, so a reduced_speed setting enforces like allow — it records the intent without capping the limit.
• No rule set resolved. If every step of the chain comes up empty, the mission falls back to the tenant default, which always exists — a mission is never left with no policy at all.

Known limitations

• Hours of service shape the estimate, not an alarm. The four enforcement detectors raise speeding, night-driving, unauthorized-refuel, and prohibited-stop alerts. The hours-of-service inputs feed the arrival estimate's rest modelling, but a driver exceeding continuous or daily driving is not itself raised as a violation — hours of service is a planning input today, not an enforced alarm.
• Unauthorized-refuel enforcement is opt-in through the whitelist. The refuel check flags a fill only against a rule set that actually lists authorized stations. A rule set with an empty whitelist does not treat every fill as unauthorized — it simply raises nothing, because "no list configured" reads as "not enforced," not "deny all."

What's ahead

• A surface to author rule sets. Policies are resolved through the chain, selected on the wizard, and applied live — but the rule sets themselves, their speed limits, night window, hours-of-service inputs, and place lists, are provisioned beneath the product rather than edited in it. The next step is an operator-facing surface to create and edit named rule sets and attach them as client, corridor, or template defaults.
• A modelled reduced-speed night mode. The reduced_speed night mode is recognised as a setting; giving it a real lower-limit model — so night driving is capped rather than simply allowed or forbidden — is a planned refinement.

How it connects

• Creating missions — where a mission's driving policy is set from the template, client, or corridor it is built from.
• Progression and ETA — how the hours-of-service inputs shape the rest-time modelling in the arrival estimate.
• Route Guard — the deviation model that runs alongside stop and refuel enforcement.
• Part 6 (fleet intelligence) — how speeding, night-driving, unauthorized-refuel, and prohibited-stop alerts reach owners and dispatchers.