Appearance
Safety Buffer Parameters
Document ID: PLCY-BUF-001
Version: 1.2
Effective Date: January 21, 2026
Last Review: January 21, 2026
Owner: Hop And Haul Team
CONFIDENTIAL
This document is CONFIDENTIAL and for internal use only. Do not distribute outside the organization.
1. Purpose
This document defines the safety buffer parameters that govern when and how Hop And Haul may contact drivers. The core principle: never create the dangerous situation.
A driver in the middle lane of a busy highway, 0.5 miles from an exit they'd need to take, should never receive a squawk that requires mental processing or physical action.
All parameters are company-tunable to match fleet safety policies.
2. The Problem We're Solving
2.1 The Dangerous Scenario
Driver: 65 mph, middle lane, I-95
Exit needed for pickup: 0.4 miles ahead
Agent: "Hop And Haul. Transport nearby. Hold or pass?"
Driver: [Now must decide AND lane change AND exit]This is unacceptable.
2.2 What We Must Know Before Contact
| Data Point | Source | Why It Matters |
|---|---|---|
| Current speed | Samsara GPS | High speed = longer buffers |
| Current position | Samsara GPS | Proximity to maneuvers |
| Projected route | Samsara | Upcoming exits, turns |
| Traffic density | Samsara/external | Congestion = harder maneuvers |
| Time to next maneuver | Calculated | Don't interrupt before critical actions |
| Lane position | Samsara (if available) | Middle lane = harder exit |
3. Buffer Types
3.1 Buffer Taxonomy
┌─────────────────────────────────────────────────────────────────────┐
│ OFFER LIFECYCLE │
└─────────────────────────────────────────────────────────────────────┘
[MATCH IDENTIFIED]
│
▼
┌──────────────┐
│ PRE-CONTACT │ ← Can we safely contact this driver right now?
│ BUFFER │ (speed, maneuvers, traffic)
└──────┬───────┘
│ SAFE TO CONTACT
▼
[SQUAWK DELIVERED]
│
▼
┌──────────────┐
│ DECISION │ ← How long until they need to respond?
│ BUFFER │ (before offer expires or needs action)
└──────┬───────┘
│ DRIVER HOLDS/ACCEPTS
▼
┌──────────────┐
│ ACCEPTANCE │ ← How long between "yes" and needing to act?
│ TO ACTION │ (route change, lane change, exit)
│ BUFFER │
└──────┬───────┘
│
▼
┌──────────────┐
│ PICKUP │ ← Safe approach, stop, passenger board
│ BUFFER │
└──────┬───────┘
│
▼
┌──────────────┐
│ DROP-OFF │ ← Safe stop, passenger exit, re-merge
│ BUFFER │
└──────────────┘4. Pre-Contact Buffer (Gate Check)
4.1 Purpose
Before ANY contact (squawk, banner, notification), verify the driver is in a safe state to receive information.
4.1a Call Initiation Timing Requirement (per PLCY-COM-001)
POLICY REQUIREMENT
Per PLCY-COM-001 Section 3.2, ride opportunities shall only be presented when the routing algorithm confirms:
- At least 15 minutes of buffer time before pickup
- At least 15 minutes of buffer time before drop-off
This ensures drivers have adequate time to make decisions without time pressure and execute maneuvers safely.
4.2 Gate Conditions
| Condition | Check | Default Threshold | Tunable |
|---|---|---|---|
| Speed gate | Current velocity | If >70 mph, no contact | Yes |
| Maneuver proximity | Time to next turn/exit on route | Must be >3 min away | Yes |
| Recent maneuver | Time since last turn/exit | Must be >1 min since | Yes |
| Traffic density | Samsara/external traffic score | No contact in "heavy" | Yes |
| Highway merge zone | Within X miles of on-ramp | No contact in merge zone | Yes |
| Construction zone | Geofenced areas | No contact | Yes |
| Weather severity | External weather API | No contact in severe | Yes |
4.3 Pre-Contact Decision Flow
MATCH IDENTIFIED
│
▼
┌─────────────────────────────────────┐
│ QUERY SAMSARA: │
│ • Current speed │
│ • Position on route │
│ • Next maneuver + distance │
│ • Traffic conditions │
└──────────────┬──────────────────────┘
│
┌───────┴───────┐
▼ ▼
GATE PASS GATE FAIL
│ │
▼ ▼
CONTACT DEFER
DRIVER (re-check in 2 min)4.4 Default Pre-Contact Parameters
yaml
pre_contact_buffer:
speed_max_mph: 70
time_to_next_maneuver_min_seconds: 180 # 3 minutes
time_since_last_maneuver_min_seconds: 60 # 1 minute
traffic_density_block: ["heavy", "severe"]
merge_zone_buffer_miles: 1.0
construction_zone_block: true
weather_block: ["severe", "hazardous"]
re_check_interval_seconds: 1205. Decision Buffer
5.1 Purpose
After squawk delivery, give the driver adequate time to process and respond without pressure.
5.2 Parameters
| Parameter | Description | Default | Tunable |
|---|---|---|---|
| Response window | Time before offer auto-expires | 30 seconds | Yes |
| Silence = queue | If no response, don't expire—queue for stopped | true | Yes |
| No countdown | Never communicate "X seconds remaining" | Enforced | No |
5.3 Key Behavior
SQUAWK: "Hop And Haul. Transport nearby. Hold or pass?"
[0-5 sec] Driver processing
[5-30 sec] Waiting for response
IF response received → process
IF silence at 30 sec → queue for STOPPED state, no re-prompt5.4 Default Decision Parameters
yaml
decision_buffer:
response_window_seconds: 30
silence_behavior: "queue_for_stopped"
countdown_announcement: false # NEVER
re_prompt_allowed: false6. Acceptance-to-Action Buffer
6.1 Purpose
After driver accepts, ensure they have adequate time and distance before needing to change lanes, exit, or alter course.
6.2 The Calculation
Required buffer = f(speed, lane_changes_needed, traffic, maneuver_type)| Factor | Impact |
|---|---|
| Current speed | Higher speed = longer buffer |
| Lane changes needed | Each lane change adds time |
| Traffic density | Heavy traffic = longer buffer |
| Maneuver type | Exit vs. turn vs. lane change |
6.3 Minimum Buffers by Speed
| Speed | Min Distance to First Maneuver | Min Time to First Maneuver |
|---|---|---|
| <30 mph | 0.25 miles | 30 seconds |
| 30-50 mph | 0.5 miles | 45 seconds |
| 50-65 mph | 1.0 mile | 60 seconds |
| >65 mph | 2.0 miles | 90 seconds |
6.4 Lane Change Penalty
For each lane change required:
| Traffic Density | Time Added per Lane |
|---|---|
| Light | +10 seconds |
| Moderate | +20 seconds |
| Heavy | +45 seconds |
6.5 Offer Eligibility Check
Before presenting offer, calculate:
pickup_exit_distance = distance to exit for pickup
current_speed = from Samsara
lanes_to_cross = estimated from current lane to exit lane
traffic = from Samsara
required_buffer = base_buffer(speed) + lane_penalty(lanes_to_cross, traffic)
IF pickup_exit_distance < required_buffer:
→ DO NOT OFFER (driver would be forced into unsafe maneuver)
→ Try next candidate6.6 Default Acceptance-to-Action Parameters
yaml
acceptance_to_action_buffer:
base_buffer_by_speed:
under_30_mph:
min_distance_miles: 0.25
min_time_seconds: 30
30_to_50_mph:
min_distance_miles: 0.5
min_time_seconds: 45
50_to_65_mph:
min_distance_miles: 1.0
min_time_seconds: 60
over_65_mph:
min_distance_miles: 2.0
min_time_seconds: 90
lane_change_penalty_seconds:
light_traffic: 10
moderate_traffic: 20
heavy_traffic: 45
enforce_buffer: true # If false, offer anyway with warning7. Pickup Buffer
7.1 Purpose
Ensure safe approach, stop, passenger boarding, and departure from pickup location.
7.2 Components
| Component | Description | Default | Tunable |
|---|---|---|---|
| Approach buffer | Time to safely decelerate and position | 60 seconds | Yes |
| Dwell time | Minimum time at pickup for safe boarding | 120 seconds | Yes |
| Departure buffer | Time to safely accelerate and merge | 60 seconds | Yes |
| Pickup zone type | Adjustments for truck stop vs. roadside | See table | Yes |
7.3 Pickup Zone Adjustments
| Zone Type | Approach Buffer | Dwell Time | Departure Buffer |
|---|---|---|---|
| Truck stop | 60 sec | 90 sec | 60 sec |
| Rest area | 60 sec | 90 sec | 60 sec |
| Designated pickup | 45 sec | 60 sec | 45 sec |
| Roadside (shoulder) | 90 sec | 180 sec | 120 sec |
| Urban street | 60 sec | 120 sec | 90 sec |
7.4 Default Pickup Parameters
yaml
pickup_buffer:
approach_buffer_seconds: 60
dwell_time_seconds: 120
departure_buffer_seconds: 60
zone_adjustments:
truck_stop:
approach: 60
dwell: 90
departure: 60
rest_area:
approach: 60
dwell: 90
departure: 60
designated_pickup:
approach: 45
dwell: 60
departure: 45
roadside_shoulder:
approach: 90
dwell: 180
departure: 120
urban_street:
approach: 60
dwell: 120
departure: 908. Drop-Off Buffer
8.1 Purpose
Ensure safe stop, passenger exit, and driver's return to route.
8.2 Components
| Component | Description | Default | Tunable |
|---|---|---|---|
| Approach buffer | Time to safely position for drop-off | 60 seconds | Yes |
| Dwell time | Minimum time for safe passenger exit | 90 seconds | Yes |
| Re-merge buffer | Time to safely return to traffic flow | 90 seconds | Yes |
8.3 Default Drop-Off Parameters
yaml
dropoff_buffer:
approach_buffer_seconds: 60
dwell_time_seconds: 90
remerge_buffer_seconds: 90
zone_adjustments:
# Same structure as pickup9. Total Route Time Impact Calculation
9.1 Why This Matters
When presenting offers, the "adds X minutes" must include ALL buffers, not just drive time.
9.2 Calculation
total_impact =
drive_time_to_pickup +
pickup_approach_buffer +
pickup_dwell_time +
pickup_departure_buffer +
drive_time_with_passenger +
dropoff_approach_buffer +
dropoff_dwell_time +
dropoff_remerge_buffer +
return_to_original_route_time9.3 What Driver Hears
"Adds about 25 minutes."This 25 minutes INCLUDES all buffers. We do not tell driver "drive time is 15 min but we add 10 min for safety"—we just give the total.
10. Hours of Service (HOS) & ELD Compliance
10.1 Purpose
Hop And Haul transport matches must never cause a driver to exceed FMCSA Hours of Service regulations. The platform queries ELD data before any match offer and rejects matches that would violate HOS rules.
10.2 FMCSA HOS Rules (CMV Property-Carrying)
| Rule | Limit | Hop And Haul Enforcement |
|---|---|---|
| 11-Hour Driving | Max 11 hours driving after 10 consecutive hours off-duty | Trip cannot exceed remaining driving hours minus buffer |
| 14-Hour Window | Cannot drive beyond 14th consecutive hour after coming on-duty | Trip must complete within remaining window |
| 30-Minute Break | Required after 8 cumulative hours of driving | Match blocked if break due before trip completion |
| 60/70-Hour Limit | Max 60/70 hours on-duty in 7/8 consecutive days | Weekly hours validated before match |
| 10-Hour Off-Duty | 10 consecutive hours off-duty required before driving | Cannot match drivers still in off-duty period |
| 34-Hour Restart | Resets 60/70-hour clock | Validated in weekly hours calculation |
10.3 ELD Data Requirements
| Data Point | Source | Required for Match |
|---|---|---|
| Current duty status | Samsara ELD | Yes - must be "Driving" or "On-Duty" |
| Hours driven today | Samsara ELD | Yes - for 11-hour limit |
| Time since on-duty start | Samsara ELD | Yes - for 14-hour window |
| Time since last 30-min break | Samsara ELD | Yes - for break rule |
| Hours in last 7/8 days | Samsara ELD | Yes - for 60/70 limit |
| Time of last 10-hour off-duty | Samsara ELD | Yes - for rest validation |
10.4 HOS Buffer Calculation
Before offering a match, calculate total trip impact:
estimated_trip_time =
drive_to_pickup +
pickup_dwell +
drive_with_passenger +
dropoff_dwell +
return_to_route
HOS_safety_buffer = 30 minutes # Mandatory
delay_buffer = 15 minutes # Traffic, loading, etc.
required_driving_hours = estimated_trip_time + HOS_safety_buffer + delay_buffer10.5 HOS Gate Checks
| Check | Calculation | Pass Criteria |
|---|---|---|
| 11-hour check | 11 - hours_driven_today | >= required_driving_hours |
| 14-hour check | 14 - hours_since_on_duty | >= required_driving_hours |
| Break check | time_to_break_required | >= required_driving_hours OR break available on route |
| Weekly check | 60/70 - hours_this_period | >= required_driving_hours |
10.6 HOS Validation Flow
MATCH CANDIDATE IDENTIFIED
│
▼
┌─────────────────────────────────────┐
│ QUERY ELD: │
│ • Current duty status │
│ • Hours driven today │
│ • 14-hour window remaining │
│ • Break status │
│ • Weekly hours │
└──────────────┬──────────────────────┘
│
┌───────┴───────┐
▼ ▼
ALL PASS ANY FAIL
│ │
▼ ▼
PROCEED EXCLUDE DRIVER
TO OFFER FROM THIS MATCH10.7 Default HOS Parameters
yaml
hos_compliance:
# Safety buffers added to trip time
hos_safety_buffer_minutes: 30
delay_buffer_minutes: 15
# Minimum remaining time to be eligible
min_11_hour_remaining_minutes: 60
min_14_hour_remaining_minutes: 60
# Break requirements
break_warning_threshold_hours: 7 # Warn if close to 8-hour break rule
# ELD data freshness
eld_data_max_staleness_seconds: 60
eld_query_timeout_seconds: 10
# Fallback if ELD unavailable
eld_unavailable_behavior: "exclude_driver" # Never assume compliance11. Same-Day Trip Constraint
11.1 Core Principle
Hop And Haul matches are same-day, en-route only. No overnight trips.
A transport match must:
- Begin and end within the same operational day
- Complete before the pickup driver's duty day ends
- Not require either driver to sleep in the cab together
- Fit naturally within the pickup driver's existing route
11.2 Why This Matters
| Risk | Mitigation |
|---|---|
| Cab sharing for sleep | Prohibited - no overnight trips |
| Personal safety | Trip ends same day, both drivers return to normal operations |
| HOS violations | Trip must fit within current duty cycle |
| Route deviation creep | Only en-route, same-direction matches |
11.3 Operational Day Definition
operational_day_start = driver's on-duty start time (from ELD)
operational_day_end = operational_day_start + 14 hours (or earlier if HOS exhausted)11.4 Trip Window Validation
| Check | Requirement |
|---|---|
| Drop-off deadline | Trip must complete >= 60 minutes before driver's 14-hour window expires |
| Time of day cap | No new matches initiated after 8:00 PM local time (configurable) |
| Duration cap | Maximum trip duration: 4 hours (configurable by company) |
| Same calendar day | Drop-off must occur on same calendar date as pickup |
11.5 Trip Window Calculation
MATCH REQUEST RECEIVED
│
▼
┌─────────────────────────────────────┐
│ CALCULATE: │
│ • current_time │
│ • estimated_trip_duration │
│ • driver_14hr_window_remaining │
│ • estimated_dropoff_time │
└──────────────┬──────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ VALIDATE: │
│ • dropoff_time < 14hr_window_end │
│ • dropoff_time < daily_cutoff │
│ • trip_duration < max_trip_hours │
│ • pickup_date == dropoff_date │
└──────────────┬──────────────────────┘
│
┌───────┴───────┐
▼ ▼
ALL PASS ANY FAIL
│ │
▼ ▼
PROCEED REJECT MATCH
TO OFFER (too late in day)11.6 Default Same-Day Parameters
yaml
same_day_trip:
# Maximum trip duration
max_trip_duration_hours: 4
# Daily cutoff for new matches
daily_match_cutoff_time: "20:00" # 8 PM local
daily_match_start_time: "06:00" # 6 AM local (quiet hours protection)
# Buffer before 14-hour window expires
window_end_buffer_minutes: 60
# Calendar day enforcement
require_same_calendar_day: true
# Overnight explicitly prohibited
overnight_trips_allowed: false # CANNOT be changed11.7 Ineligible Trip Scenarios
| Scenario | Outcome |
|---|---|
| Drop-off would occur after midnight | Match rejected |
| Drop-off would occur after driver's 14-hour window | Match rejected |
| Trip duration exceeds 4 hours | Match rejected |
| Match requested after 8 PM | Match rejected (queue for tomorrow) |
| Driver has <2 hours remaining in duty day | Driver excluded from matches |
11.8 En-Route Requirement
Matches are only offered when the pickup driver is already traveling in a direction that naturally passes the passenger's pickup and drop-off locations:
| Criteria | Requirement |
|---|---|
| Route overlap | Pickup and drop-off within X miles of driver's existing route |
| Directional match | Passenger drop-off is in same direction as driver's destination |
| Minimal deviation | Total deviation from original route < 30% of remaining distance |
This ensures matches are opportunistic, not destination-altering.
12. Company-Level Configuration
12.1 Configuration Interface
All parameters are configurable at the company level:
yaml
# Company: ACME Trucking
# Safety Buffer Configuration v1
company_id: acme_trucking
effective_date: 2025-01-15
safety_buffers:
pre_contact:
speed_max_mph: 65 # More conservative than default
time_to_next_maneuver_min_seconds: 240 # 4 min, not 3
traffic_density_block: ["moderate", "heavy", "severe"]
decision:
response_window_seconds: 45 # More time to decide
acceptance_to_action:
over_65_mph:
min_distance_miles: 2.5 # More conservative
pickup:
dwell_time_seconds: 150 # More time for boarding
dropoff:
remerge_buffer_seconds: 120 # More time to merge12.2 Parameter Governance
| Change Type | Approval Required |
|---|---|
| Make more conservative | Operations Manager |
| Make less conservative | Safety Director + Legal |
| Disable a buffer | NOT ALLOWED |
| Add new buffer type | Safety Director |
12.3 Minimum Enforced Values
Some values have hard floors that cannot be reduced:
| Parameter | Hard Floor | Rationale |
|---|---|---|
| Pre-contact speed max | 75 mph | Above this, no safe contact |
| Time to maneuver min | 60 sec | Minimum safe processing |
| Decision window | 15 sec | Below this = pressure |
| Pickup dwell | 45 sec | Minimum safe boarding |
| Drop-off dwell | 30 sec | Minimum safe exit |
13. Samsara Integration Requirements
13.1 Required Data Points
| Data Point | Samsara API | Refresh Rate |
|---|---|---|
| Current speed | Vehicle Stats | Real-time |
| Current position | GPS | Real-time |
| Heading | GPS | Real-time |
| Route (if dispatched) | Routes API | On change |
| Next maneuver | Calculated from route | Real-time |
| Traffic conditions | Traffic API or external | 5 min |
| ELD status | HOS API | Real-time |
13.2 Data Freshness Requirements
| Data Point | Max Staleness | If Stale |
|---|---|---|
| Speed | 10 seconds | Block contact |
| Position | 30 seconds | Block contact |
| Traffic | 10 minutes | Use "moderate" default |
| Route | 5 minutes | Re-query before offer |
13.3 Fallback Behavior
If Samsara data unavailable:
| Scenario | Behavior |
|---|---|
| Speed unknown | Assume 65 mph (conservative) |
| Position unknown | Block all contact |
| Route unknown | Cannot calculate buffers → block offer |
| Traffic unknown | Assume "moderate" |
14. Monitoring & Alerts
14.1 Safety Buffer Violations
If a buffer is violated (should never happen, but monitor):
| Violation | Alert Level | Response |
|---|---|---|
| Contact made inside maneuver window | Critical | Immediate review |
| Offer made without adequate exit distance | Critical | Immediate review |
| Pickup dwell under minimum | Warning | Review at shift end |
| Pattern of near-violations | Escalation | Parameter review |
14.2 Audit Queries
- All offers made with buffer calculations
- Any offers deferred due to buffer gates
- Buffer parameter changes over time
- Violations and near-misses
15. Document Control
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | December 22, 2025 | Hop And Haul Team | Initial release |
| 1.1 | December 22, 2025 | Hop And Haul Team | Added HOS/ELD compliance (Section 10) and Same-Day Trip Constraint (Section 11) |
| 1.2 | January 21, 2026 | Hop And Haul Team | Aligned with PLCY-COM-001 v3.0: Added Section 4.1a documenting 15-minute pickup and 15-minute drop-off buffer requirements for call initiation per PLCY-COM-001 Section 3.2. |