Amendment 2026-05-29: BI tool is Hex Apps, not Metabase Cloud. See WF-6.9 v1.1 change log for rationale (MotherDuck connector gap in Metabase Cloud). All references to “Metabase” below should be read as “Hex” — build effort estimates remain unchanged. Substantive rewrite of this document deferred. New dashboard added: Strategic Weekly Review (owner-facing Monday capacity-economics view; live 2026-05-29). Not in the v1.0 seven-dashboard inventory below.

WF-6.10 — Dashboard Layer Plan

Type: Implementation plan Value Driver: VD6 Financial Operations (delivery infrastructure) → consumers across VD1–VD5 Version: 1.0 Date: 2026-05-13 Owner: Roger Thompson (dashboard build); BCs (daily consumers); Jana (financial consumer) Status: Active — WF-6.11 dependency cleared 2026-05-13 Companion to: WF-6.9 Dashboard Tool Decision (Hex Apps per v1.1; v1.0 originally Metabase Cloud), WF-6.11 Website Infrastructure Decision (Astro/Cloudflare), WF-6.12 Internal Portal Build Plan (portal where dashboards embed)

Purpose

Per-dashboard scope for the seven scorecard surfaces. Defines what each dashboard contains, where its data comes from (gold views per WF-6.8), how it refreshes, how it gets distributed, and what depth of interactivity it supports at each Metabase tier. This is the spec each Metabase dashboard build follows.

Scope

In scope:

• Seven scorecard dashboards (Daily BC, Daily Owner, Weekly Friday, Monthly Driver Scorecard, Monthly P&L, Quarterly QBR, Annual Review)
• Data source mapping for each block of each dashboard
• Refresh cadence per dashboard (and per question where it varies)
• Distribution channels (portal embed, email digest, Slack alert)
• Drill-down depth and per-tier capabilities (Starter static vs Pro interactive)
• Build sequence with phase dependencies

Out of scope:

• Portal route and authentication mechanics (WF-6.12)
• BI tool selection rationale (WF-6.9)
• Gold view DDL and warehouse build (WF-6.8 + dev repo)
• Per-scorecard layout (already authored in /Templates/Scorecard-Templates-v1.0.md)
• Operational governance once live (WF-6.6 proposed)

Design rules (apply to every dashboard)

These rules anchor every dashboard build. Lifted from the discipline that’s already operating in /Templates/Scorecard-Templates-v1.0.md and reinforced by Roger’s operating philosophy.

1. Contract Standing gate opens every operational dashboard. Before any other metric, the dashboard answers: are we operating within FedEx contract? GREEN / YELLOW / RED status from the contract_standing_composite view (when live; before that, a manual placeholder).
2. One owner per action surfaced. When a dashboard surfaces a decision-worthy number (e.g., “driver X is rest_candidate”), the owner of the next action is named on the card.
3. Taxonomy wins on definitions. Every metric on every dashboard maps to a KPI ID from KPI-Taxonomy-v1.1.md. The KPI ID appears in the question’s description in Metabase.
4. Decisions, not explanations. The dashboard surfaces the number and the threshold. It doesn’t lecture. Drill-down is for “why”; the headline is for “what.”
5. Plan vs Actual is a first-class structure. Where FRO or AOP plans exist, the dashboard compares to actuals from WSW + Settlements. Variance is the improvement lever.
6. Display names route through ref_driver_alias. FedEx system names and roster names differ. Every driver-level dashboard joins against ref_driver_alias to render the right human-readable name.
7. EXP 01 and EXP CLOSE are excluded from delivery metrics. They’re holding-status routes, not delivery routes. WF-6.8 view filters apply; dashboards inherit them.
8. Mobile-readable. BCs check from phones. Metabase responsive defaults handle most cases; per-question layout chosen with mobile in mind (e.g., one big number not a wide table).

Dashboard inventory

Seven dashboards, mapped to the six scorecards plus the Monthly Driver Scorecard built artifact (WF-4.4) which becomes its own dashboard surface.

Build sequence:

• v1 (4 dashboards): Daily BC → Daily Owner → Weekly Friday → Monthly Driver Scorecard. All P0 gold views. Ships in WF-6.12 Phase C and D.
• v1.1 (2 dashboards): Monthly P&L Review and Quarterly QBR. Depend on P0 monthly_pnl_rollup + P1 captures. Targets July–September 2026.
• v2 (1 dashboard): Annual Review. Depends on a full year of clean monthly data. Targets January 2027.

Dashboard 1 — Daily BC Dashboard

Primary audience. Vincent, Brandon. The first thing each BC opens at the belt every morning.

Cadence. Daily. Refreshes overnight by 4 AM Pacific; BCs check between 5–7 AM.

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/daily-bc (primary)
• Mobile-readable for belt-side glance
• No email digest (BCs check the portal directly — that’s the morning ritual)
• Slack alert: only on threshold breaches (Contract Standing → YELLOW or RED, driver rest_candidate flag for someone scheduled today)

Embed mode. Static iframe at Starter tier (1 CSA). Interactive at Pro tier (5+ CSAs).

Block 1 — Contract Standing gate. GREEN / YELLOW / RED across the day’s standing.

Block 2 — Yesterday’s Results. Per-route + fleet aggregate. Fully buildable from existing P0 views.

Block 3 — Today’s Plan. Today’s route plan from RouteSmart capture. Currently blocked by WF-2.4 capture not flowing. v1 launches without Block 3; backfilled when bronze_routesmart_plan populates.

Block 4 — Blockers / Staffing. Who needs attention before dispatch.

Block 5 — Action items. Manual entry; surfaces what each BC needs to do today. Lives in Metabase as a markdown text card the BC on duty edits each morning, or as a separate /dashboards/daily-bc#actions section linked from the dashboard.

Drill-downs available.

• Click any per-route row → route detail (per-stop breakdown for that day)
• Click DNA cell → DNAs by exception code (Code 7, Code 2, “not on truck”)
• Click driver name → driver detail (last 30 days)

Open dependencies.

• WF-2.4 Nightly RouteSmart Plan Capture must flow into bronze for Block 3
• RYDE export pipeline for Block 1
• VEDR event capture for Block 1 composite

Build effort. 1.5 days in Metabase. Aligns with WF-6.12 Phase C.

Dashboard 2 — Daily Owner Dashboard

Primary audience. Roger. Single morning check at 7 AM Pacific.

Cadence. Daily. Refreshes overnight by 4 AM; Roger checks between 7–8 AM.

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/daily-owner (primary)
• Email digest: 6 AM daily summary emailed to Roger via Metabase Subscriptions (Pro tier feature; Starter tier has limited alerts only)
• Slack DM: optional, on threshold breaches

Embed mode. Static iframe.

Differences from BC dashboard. Roger sees the same operational data plus a few owner-level items:

Additional metrics on Owner dashboard.

Drill-downs available.

• Click weekly settlement → settlement detail by route
• Click cash forecast → 13-week breakdown by line item
• Click recruiting funnel → applications + interviews + 90-day survivors

Open dependencies.

• thirteen_week_cash_flow view depends on cash balance log (capture SOP not yet built)
• recruiting_funnel_daily view exists; bronze_applications has 234 rows already loaded

Build effort. 1 day in Metabase. Reuses Daily BC questions where possible. WF-6.12 Phase C / D.

Dashboard 3 — Weekly Friday Review

Primary audience. Roger + BCs. Friday morning sync (existing meeting cadence).

Cadence. Weekly. Refreshes Thursday end-of-day; reviewed Friday morning.

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/weekly (primary)
• Email digest: Friday 6 AM emailed to Roger + BCs (Pro tier)
• Used live during Friday meeting (screen-shared)

Embed mode. Static iframe v1; interactive at Pro tier.

Block 1 — Contract Standing weekly trend. Same composite as daily, but trended over the past 4 weeks.

Block 2 — Operational summary (Mon–Sun).

Block 3 — Financial week-in-review.

Block 4 — Plan vs Actual (when WF-2.4 captures flow).

Block 5 — Issues + decisions for the meeting. Manual text card; BCs and Roger add issues during the week, decisions go into Decisions-Log.md after.

Drill-downs available.

• Click any driver row → driver weekly detail
• Click OT figure → OT by driver
• Click variance → per-route variance table

Open dependencies.

• weekly_driver_summary, ot_summary_weekly, stop_pay_weekly, weekly_settlement_summary are P0 — buildable day 1
• cost_per_stop_weekly, cost_per_mile_monthly, fuel_efficiency_monthly are P1
• Plan-vs-actual depends on RouteSmart capture

Build effort. 1.5 days in Metabase. WF-6.12 Phase D.

Dashboard 4 — Monthly Driver Scorecard

Primary audience. BC on duty (during scorecard month), Roger (review), drivers (one-page printable per WF-4.4).

Cadence. Monthly. Built Day 1 of next month; Roger reviews Day 3; drivers receive Day 5–10.

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/monthly-scorecard (primary; replaces the xlsx workflow for BC + Roger)
• Printable per-driver one-pager (preserves the WF-4.4 printable Individual-Scorecard sheet behavior)
• Driver distribution: BC prints + delivers per WF-4.4 SOP
• No email digest (review is intentional, not glanced)

Embed mode. Static iframe v1; interactive at Pro tier (drill-down to per-driver detail).

This dashboard replaces the xlsx workflow in WF-4.4. The xlsx workbook stays available as a backup, but the canonical source becomes the Metabase dashboard reading from monthly_driver_scorecard (P0 materialized gold table — 8 rows current partial-May load per memory; full month-end load after May closes).

Block 1 — CSA Average row. Anonymous, all-driver aggregate.

Block 2 — Top Driver row. Anonymous, z-score-ranked top performer for the month. Disqualified by VEDR events > 0 or accident on record (per WF-4.4 design).

Same 9 metrics, Top Driver values.

Block 3 — Per-driver detail. One driver selected; full scorecard with banding (Red/Yellow/Green per WF-4.4 threshold reference).

Selector: driver dropdown (joined to ref_driver to display roster names).

Block 4 — Trends. 12-month trailing chart per metric. Trends are read-only at Starter tier; interactive at Pro.

Block 5 — Printable view. Print-CSS-styled view that produces the same one-pager /VD4 - Service Quality/Data/Monthly-Driver-Scorecard-v1.0.xlsx Individual-Scorecard sheet produces. BC prints; hands to driver per WF-4.4.

Drill-downs available.

• Per-driver: click driver → full 12-month history
• Per-metric: click metric → all drivers ranked

Migration from xlsx (per WF-4.4). The xlsx workflow stops at v1 launch; the Metabase dashboard becomes canonical. The populate_scorecard.py script in the dev repo (which previously bridged gold view → xlsx) is repurposed if a CSV export is needed for external reporting.

Open dependencies.

• monthly_driver_scorecard is materialized gold table; 8 rows as of 2026-05-12 (partial May)
• VEDR events column requires bronze_vedr_events to load (currently 0 rows per memory)
• Attendance call-outs column requires attendance log capture SOP

Build effort. 2 days in Metabase. The most complex of the v1 dashboards. WF-6.12 Phase D.

Dashboard 5 — Monthly P&L Review

Primary audience. Roger + Jana. Monthly close review.

Cadence. Monthly. Refreshes Day 1 of next month after Tensor closes books (typical Day 5–10 close cadence).

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/monthly-pl (primary)
• Email digest: PDF generated Day 10 via Metabase Subscriptions and sent to Roger + Jana
• Jana accesses via Cloudflare Access exception list (her external Tensor email)

Embed mode. Static iframe v1. Interactive at Pro tier (Jana drills down to GL accounts).

Block 1 — P&L summary.

Block 2 — Variance vs prior month. Same line items, % change.

Block 3 — Variance vs AOP plan (when AOP exists).

Block 4 — Cost structure breakdown.

Block 5 — Cash position.

Drill-downs available.

• Each P&L line → GL accounts comprising it (Tensor GL data, when available in bronze)
• Cost structure → per-truck or per-route allocation (when route_profitability_weekly P2 unblocks)

Open dependencies.

• monthly_pnl_rollup is P0 — buildable
• AOP variance and route profitability are P2 — blocked on Roger’s allocation rule decisions (overhead, service-charge, eComm-Ground revenue split)
• Tensor GL bronze ingestion timing — Jana confirms cadence

Build effort. 2 days in Metabase. Includes Jana onboarding (her first Metabase session). v1.1 — targets August 2026 once Tensor month-end practice is consistent.

Dashboard 6 — Quarterly QBR

Primary audience. Roger + Jana + BCs. Quarterly Business Review meeting.

Cadence. Quarterly. Refreshes first business day after quarter close.

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/quarterly (primary)
• PDF generated post-quarter via Metabase Subscriptions; saved as the QBR packet
• Used live during QBR meeting (screen-shared)

Embed mode. Static iframe v1.1; interactive at Pro tier for deep dives during meeting.

Block 1 — Apex Scorecard. Apex 1 (Financial Outcome) + Apex 2 (Contract Standing) trended across the quarter.

Block 2 — Quarterly operational.

Block 3 — Strategic indicators.

Block 4 — Quarter narrative. Manual text — what happened, what changed, what’s next. Owned by Roger; reviewed by Jana + BCs.

Block 5 — Decisions made this quarter. Pulled from Decisions-Log.md filtered to the quarter window.

Drill-downs.

• Click any quarterly metric → monthly trend within the quarter
• Click strategic indicator → underlying detail

Open dependencies.

• P1 views above must be live (Phase 1 + 2 captures complete)
• P2 views are blocked on AOP, Tensor entity-separated reporting, allocation rules

Build effort. 2.5 days in Metabase. v1.1 — targets October 2026 (post-Q3 close).

Dashboard 7 — Annual Review

Primary audience. Roger + Jana. Annual planning + tax-period close + AOP build for next year.

Cadence. Annual. Builds in December (preliminary) and January (final after Y close).

Distribution.

• Browser at portal.cedarfell-logistics.com/dashboards/annual (primary)
• PDF Annual Report generated via Metabase Subscriptions
• Distributed to Roger + Jana

Embed mode. Static iframe v2.

Block 1 — Year-over-year P&L.

Block 2 — Apex Scorecard year trended.

Block 3 — Strategic year-end summary.

• Each STR.* KPI year-end value + target
• Wage structure assessment (STR.WAGE)
• Fleet strategy progress (STR.FLEET, including diesel exit 2028 readiness)
• Expansion readiness (STR.EXIT.04 + STR.EXIT.06)
• BC bench (STR.BENCH)
• Aaliyah continuity (STR.AALIYAH)

Block 4 — Driver tenure + retention summary. Per-driver scorecard rolled annual; tenure buckets; retention rate.

Block 5 — Quarter-by-quarter recap. 4 mini-quarterly summaries.

Block 6 — Annual decisions log summary. All material decisions from Decisions-Log.md for the year.

Block 7 — AOP comparison + next-year plan. Manual; outputs feed into next year’s AOP.

Open dependencies.

• Requires full year of clean monthly data
• AOP must exist for prior-year-vs-plan comparison
• Strategic KPI captures need to be operational

Build effort. 2 days in Metabase, leveraging Monthly + Quarterly questions. v2 — targets January 2027.

Refresh schedules summary

Implementation note: Metabase Cloud refreshes question cache on a schedule (per-question, configurable). Dashboards display cached data; on-page-load triggers a cache check. Setting per-question schedules avoids needless compute against MotherDuck.

Distribution channels summary

Slack alert thresholds for v1:

• Contract Standing → YELLOW or RED
• Any rest_candidate flag for a driver scheduled today
• OT spend YTD exceeds plan + 10%
• Driver attendance call-out pattern hits Brandon’s 180-stop-on-short-staff threshold

Embedding tier capability summary

Upgrade trigger: 5th CSA. Until then Starter is sufficient because the v1 dashboards are designed read-only — interactivity is a Pro perk, not a requirement.

Build sequence with WF-6.12 phasing

Open dependencies (full inventory)

Cross-references

• WF-6.4 Scorecard Data Acquisition Plan — /VD6 - Financial Operations/Workflows/
• WF-6.7 Warehouse Engine Decision — /VD6 - Financial Operations/Workflows/
• WF-6.8 Gold View Map — /VD6 - Financial Operations/Workflows/ (data sources)
• WF-6.9 Dashboard Tool Decision — /VD6 - Financial Operations/Workflows/ (Metabase)
• WF-6.11 Website Infrastructure Decision — /VD6 - Financial Operations/Workflows/ (stack)
• WF-6.12 Internal Portal Build Plan — /VD6 - Financial Operations/Workflows/ (portal)
• WF-6.6 Dashboard Operations SOP (proposed) — operational governance
• WF-4.4 Monthly Driver Scorecard SOP — /VD4 - Service Quality/Workflows/
• KPI Taxonomy v1.1 — /Strategic/
• Scorecard Templates v1.0 — /Templates/
• Decision Catalogue — /VD6 - Financial Operations/Data/
• Decisions-Log.md — entry dated 2026-05-13 for this plan

Change log

Appendix A — Question library plan

Each Metabase dashboard is composed of “Questions” (saved SQL queries with chart spec). Building a library of reusable questions reduces duplication across dashboards:

Library lives in a Metabase Collection called Cedarfell Question Library. Each dashboard references questions from the library rather than re-implementing SQL inline. Naming convention: <KPI ID> — <metric name> (e.g., OP.VD4.02 — ILS % daily).

Appendix B — Slack alert channel setup

When Slack is operational (currently in setup per project context):

Channel: #cedarfell-alerts

Subscribers: Roger, Vincent, Brandon, Aaliyah.

Alert types and triggers:

Alerts post to Slack via Metabase’s Slack integration (Pro tier feature; Starter tier supports email-only).

Appendix C — Mobile considerations

BCs check from phones at the belt. Per-question design rules:

1. One number bigger than the rest. Each block has one headline number; everything else is supporting.
2. No wide tables. Tables over 4 columns require horizontal scrolling on phones. Use card layouts for per-route detail.
3. Color before text. GREEN / YELLOW / RED is faster than reading a value + threshold.
4. Tap targets large. Drill-down links sized for thumbs; Tailwind min-h-[44px] for clickable elements.
5. Loading state visible. If the dashboard takes >2 seconds to load, a skeleton shows. Metabase handles this by default.

The Daily BC Dashboard specifically is tested on a phone before launch — that’s the highest-stakes mobile use case.