# Fluix Benchmark

**One-line purpose:** Compare a chosen group — sites, teams, assignees, assets, or work/inspection types — against each other and against the overall account-wide average for a chosen period, to see who's performing above or below the norm. When more than one grouping dimension is relevant (e.g. vehicles and operators on the same report), compare each one and connect the findings if a real pattern spans both. A secondary layer checks each group against its own recent history, when there's enough of it. Not a full dashboard (Fluix Smart Dashboard) and not a periodic recap (Fluix Pulse Digest) — this one answers "who's ahead, who's behind, and why."

---

## When to trigger it

- "Compare [sites/teams/assignees/assets/work types] against each other"
- "Which [sites/inspectors/assets] are performing above or below average"
- "Compare inspection results across all sites this month — which are above or below the overall average?"
- "Compare this across vehicles and operators" / any request naming more than one grouping dimension at once
- Any request comparing a metric across a chosen grouping dimension, for a period, against the overall average — as opposed to a single-source deep dive (Dashboard) or a periodic written recap (Digest)

## Inputs

Required:
- **Data source and tool family** — same discovery as the other Fluix skills (`tasks_list_reports` / `docs_list_datasets` / `docs_status_rows`). If no source is named, ask which one.
- **Grouping dimension(s)** — one or more of: site/facility, team/crew, assignee/inspector/operator, asset/equipment, or work/inspection type. Infer which from the request's phrasing ("compare sites" → a site/facility field; "compare operators" → an assignee/operator field) and match against the schema. If the request names more than one dimension, or the report's own shape makes a second dimension obviously worth comparing too (e.g. a per-equipment checklist that also names an operator on every row), run both rather than picking one. If the request is generic ("compare performance") and the schema has more than one plausible grouping field, ask which one(s).
- **Time period** — resolved the same way as Pulse Digest: if the request states one ("this month"), use it directly; if not, ask via quick-select (Today / This week / This month / All available data / Custom). If the resolved period returns zero records, say so plainly rather than silently substituting a different range — offer "all available data" as the next step instead of assuming it.

Optional, inferred from context or defaulted:
- **Metric to compare** — inferred from the use case (the same headline-metric logic as Pulse Digest/Dashboard) unless the person names a specific field. If the source has no single pass/fail-style field (e.g. a multi-item checklist instead), derive a comparable metric — such as the share of records with zero flagged/defect items — and state plainly what was derived and how.
- **Baseline window for the secondary self-comparison** — defaults to the trailing 4-8 periods. If a group's own history is too sparse to support this (too few records across too short a window), say so per-group rather than forcing a baseline.

## Workflow steps

1. **Find the data source and confirm tool family** — identical to the other Fluix skills.
2. **Get the schema first, always** — same field classification as the Dashboard skill. Identify every field that could serve as a grouping dimension (site/facility, team/crew, assignee/operator, asset, work/inspection type), and match the requested one(s) to the right field. If the assignee/operator field turns out to hold a small number of role/queue values ("Technicians," "Site Supervisor") rather than individual names, note that plainly before treating it as a person-level comparison.
3. **Resolve the time period** — via quick-select if not already stated, same as Pulse Digest. Don't proceed to pulling data until this is settled.
4. **Identify the use case and the metric** — same reasoning as the other Fluix skills. If no single pass/fail field exists, derive a defect/clean-rate-style metric from the available checklist fields and state how it was derived.
5. **Pull the rows for the period.**
6. **For each grouping dimension being analyzed**, compute the pooled/weighted account-wide average for the metric (total qualifying events ÷ total records — never an unweighted mean of per-group rates, which lets small groups distort the average out of proportion to their actual share of the work), then each group's value and its gap from that average.
7. **Classify each group** as clearly above average, clearly below average, or close enough to average not to flag — a fixed numeric threshold isn't required, but the gap has to be large enough to matter, not just nonzero. Note sample size per group, and call out explicitly when a group's number is too thin to weight heavily (rather than silently including or silently dropping it).
8. **Run the secondary self-comparison** per dimension: each group's current value vs. its own trailing baseline, using the Dashboard skill's outlier logic. State plainly when there isn't enough per-group history to do this.
9. **If more than one dimension was analyzed**, check whether the same underlying pattern shows up in both (e.g. the worst-performing group in dimension A is also concentrated among a specific subset of dimension B) before presenting them as unrelated findings.
10. **Render as one widget**: a metric-card strip at the top (account average, total records, count of groups below average, and — when the metric has one — a secondary headline count relevant to it, such as total flagged/defect items), followed by one horizontal bar chart per dimension analyzed. Color each bar by status — green for clearly above average, neutral gray for close to average, red for clearly below average — with a small legend so the color meaning is never left implicit. State the account average in the label above each chart rather than plotting a reference line on it. Scale each chart's height to its number of groups so labels stay readable. Below the widget, add the narrative paragraph per dimension, then a synthesis line if more than one dimension was analyzed.

## Output format

One widget — no separate narrative text section. Everything renders inside it, including the callouts that used to be prose.

**The widget**, in this order:
1. A metric-card strip: account average, total records (n), count of groups below average, and — when the metric supports one — a secondary headline count relevant to it.
2. A small legend: green = above average, gray = close to average, red = below average.
3. One horizontal bar chart per grouping dimension analyzed, bars colored by status per the legend above, chart height scaled to the number of groups.
4. A styled card per flagged group — above-average and below-average groups only, never the ones sitting close to average — same card pattern as Fluix Risk Check: bold group name, a colored badge showing the value and its gap from the average (e.g. "+12 pts"), and one line covering what the chart can't show: a low-sample caveat, or that group's self-comparison result ("its own recent normal" vs. the current figure). Group the cards visually — above-average together, below-average together — don't interleave them.
5. If more than one dimension was analyzed, one closing line inside the widget connecting them ("this looks like an equipment issue more than an operator one — the same trucks keep coming up, not the same people") or stating plainly that the two comparisons are independent.
6. A muted footer line: sample-size caveats, a pooled-vs-unweighted-average note when the two would meaningfully differ, and a demo/sample-data flag if warranted.

## Guardrails

- Compute the overall average as a pooled/weighted figure, never an unweighted mean of per-group rates.
- Don't restate a group's exact value in a card's body text when the badge already shows it — the card names the group and why it matters, not the number a second time.
- Color communicates status (above/at/below average) but never stands alone — pair it with the legend, keep each group's exact value visible in its badge, and say in the card's text anything color can't convey, like a thin sample size.
- Never present a role/queue-based grouping (a shared assignee value across many people) as an individual-level comparison — say so plainly when the grouping field isn't one person per value.
- Flag low-sample groups explicitly rather than treating them with the same confidence as well-sampled ones.
- Keep the primary above/below-average comparison and the secondary self-comparison clearly separate.
- When comparing more than one dimension, look for a shared underlying cause before presenting them as separate findings — but don't force a connection that isn't actually there.
- If the resolved time period returns zero records, say so directly rather than silently substituting a different range.
- Same data-quality stance as the other Fluix skills — flag demo/sample data or too-small samples rather than treating them as real signal.
- This skill only surfaces comparisons — it never modifies records, reassigns anything, or messages anyone on the person's behalf.