How a duty-status event captured on the ELD tablet becomes an HosEventLog row, and how that row fans out into timers, violations, AMQP broadcasts, and the externally-built “segment” that powers the driver recap UI.
Read first
There is no Segment or HosSegment table or Eloquent model anywhere in this repo. The system of record is hos_event_log. A “segment” (a continuous span of one duty status) is a derived projection built outside Orion: HosSegmentDispatchSqsListener publishes just {guid, recordStatus} to an SQS queue, and an external, Elasticsearch-backed denormalizer service looks up the full event and builds the segment.
A second, unrelated meaning of “segment” also exists in this codebase: the FMCSA/CCMTA compliant export file is assembled from named file sections — headerSegment(), eldEventListSegment(), driverCertificationSegment(), etc., in FileOutput.php. Same word, different concept — called out on the diagram.
Data flow & architecture
Solid arrows are write/event flow; dashed arrows are read paths, a synchronous direct call, or a terminology note (labelled individually).
The amber lane (HosEventLog → SQS → external denormalizer → “Segment” → Recap UI) is the path this diagram exists to explain: everything a “segment” is built from lives in this repo, but the segment itself does not. The dashed red box calls out a same-word, different-concept usage in the ELD export job. Dashed grey lines are reads or a synchronous (non-listener) call, each labelled.
What's captured on an HosEventLog event
Every write funnelled through HosEventRepository::save() carries this shape — it's the raw material the external denormalizer reads to build a segment.
Identity & provenance
guid / origin_guidevent identity; edits chain back via origin_guid
sequenceordering within a day
record_statusdraft · active · changed · change-requested · change-rejected