5-Dot Compliance

Every MARS work order must clear five document checkpoints before it can reach Completed status. These are displayed as five status dots on every WO row in the Active Queue — giving the FSS team instant visibility into which documentation is pending for any in-flight order.

The Five Dots

#	Dot	Full Name	What it verifies
1	BOL	Bill of Lading	Official transport documentation — the legal record that a haul occurred
2	LSP	Logistics Service Provider	The hauler identity and responsibility chain for the initial pickup movement
3	TON	Tonnage / Weight Ticket	Measured weight of the material — required for billing accuracy and regulatory reporting
4	DSP	Disposal Site Provider	The authorized facility where materials were delivered for final disposal
5	COD	Certificate of Destruction	Quantitative proof that the material was properly processed and destroyed

LSP and DSP are pre-qualified

LSP and DSP are verified at WO creation from registered provider lists — they don't require document uploads, only confirmation that a valid provider is on record. BOL, TON, and COD require file uploads.

Dot States

Each dot transitions through three states:

State	Color	Meaning
pending	Grey	Not yet uploaded or confirmed
review	Amber	Document uploaded, awaiting verification
verified	Green	Confirmed — this dot clears the gate

Rejection sends a dot back to pending.

The Compliance Gate

The compliance gate blocks WO state progression at a critical point:

• Serviced → Completed requires all five dots to be at review or verified — checked via allUploaded() in frontend/src/utils/compliance.js
• Full verification (allVerified()) is a stricter check — all five at verified — used for final compliance reporting and the Hauler Compliance Scorecard

A WO stuck with grey dots in the Active Queue cannot advance to Completed regardless of its other fields. The FSS dispatcher can see exactly which dots are blocking by opening the WO's SideDrawer.

The Work Order Journey

The work order lifecycle maps onto the 5-dot gate as follows:

Phase	WO Statuses	Compliance role
Intake	New → Acknowledged → Dispatched → Scheduled	No dots required yet — haul hasn't happened
Service Execution	Dispatched → Serviced	Hauler executes the pickup; documents begin accumulating
Compliance Gate	Serviced (blocked)	All 5 dots must reach review or verified before advancing
Clearing the Gate	Serviced → Completed	Gate opens once all dots are satisfied
Final Destination	Completed	All compliance docs verified — WO is closed

Where Compliance Appears in the UI

Active Queue — Each WO row shows all five dots inline. Grey dots flag actionable WOs at a glance. The "NTE Pending" and "Has Issue" badges also surface from the same row.

SideDrawer — Expandable compliance panel shows each dot's current state with upload controls and reviewer action buttons.

/compliance view — Five tabs:

1. Program Coverage (default) — Quality Risk Matrix across all WOs
2. LSP Registry — Registered logistics service providers
3. DSP Registry — Registered disposal site providers
4. Disposal Tracker — Per-WO disposal record
5. Non-Conformance Register (NCR) — Compliance violations and remediation tracking

Hauler Portal (/h/compliance) — Hauler-scoped compliance scorecard filtered by vendorId, with 14 / 30 / 90 / YTD date range selectors.

Implementation

Compliance logic is implemented as pure functions in two files that must stay in sync:

File	Role
frontend/src/utils/compliance.js	allUploaded(), allVerified(), dot state helpers — used by WO rows and SideDrawer
backend/app/state_machine.py	Gate enforcement on Serviced → Completed transition — called on every state advance API request

The backend is the authoritative gate. The frontend mirrors it for optimistic UI, but the backend will reject any transition that doesn't satisfy the compliance check, regardless of what the frontend shows.

MARS customers only

All current WOs in the system are MARS customers, so all WOs require all 5 dots. Non-MARS customers (future) will have compliance requirements defined per customer profile — the compliance module is already structured to support per-customer rules.