Why hardware matters to a TMS
FutureDetention charges, damage claims and missed appointments are disputes about physical facts. When arrival times come from a guard's notebook and weights from a separate scale ticket, reconciliation is slow and contested. Capturing evidence at the device, with provenance, shortens that loop.
Candidate device classes
Each class would publish events through a small Rust edge runtime using the same schema as the service core.
- Dock-door and yard-gate sensors: arrival and departure
- Barcode and RFID scanners: handling-unit linkage at loading
- Floor and axle scales: shipment weight evidence
- Temperature and humidity loggers: reefer compliance
- ELD and telematics gateways: location and status pings
The edge runtime
FutureA gateway would buffer events offline, sign them with a device identity and forward them when connectivity returns. Rust's small binaries, no_std support and memory safety suit unattended devices that must run for years.
Trust, calibration and safety
Device data is only as good as its calibration and identity. Any future integration would need device registration, key rotation, tamper signals and clear labeling of device-sourced versus operator-sourced facts. Kaporeal will not present device readings as certified unless the hardware and process actually are.
