# Fluix Audit Pack

**One-line purpose:** Assemble a complete, report-formatted evidence bundle — records, photos, signatures, timestamps — for a specific date range and/or site/asset, ready to hand to an auditor, customer, or compliance team. Read-only compilation, not an analysis skill: reuses Fluix Data Integrity Check's completeness logic to make sure the pack states its own gaps upfront rather than hiding them, but the deliverable here is the assembled document itself, not a findings list.

---

## When to trigger it

- "Give me everything for the [month] audit"
- "Compile evidence for [site/date range]"
- "I need a compliance report for [X]"
- "Put together an audit pack for [scope]"
- Any request for a hand-off-ready evidence bundle for a defined scope, as opposed to an open-ended completeness check (Data Integrity Check) with no specific audience or window in mind

## Inputs

Required:
- **Data source and tool family** — same discovery as the other Fluix skills. If no source is named, ask which one.
- **A scope** — a date range and/or a named site/asset/report. This skill needs at least one; compiling "everything, ever" isn't a meaningful pack. If neither is given, ask for one before pulling data.

Optional, inferred from context or defaulted:
- **Audience** — defaults to internal (full detail, including assignee names and internal notes). If the request signals external use (a customer, a regulator, someone outside the organization), apply the same internal-detail suppression the Dashboard skill uses for its external, simplified proof-of-compliance job — no assignee names, no internal notes, summary framing only.

## Workflow steps

1. **Find the data source and confirm tool family** — identical to the other Fluix skills.
2. **Get the schema first, always** — same classification as Data Integrity Check, specifically separating out media/image fields, signature fields, and the date/identifying fields (site, asset, inspector) needed to scope and label each record.
3. **Identify the use case** — same reasoning as the other Fluix skills.
4. **Pull rows matching the scope**, across all statuses within that scope — not filtered to open-only, since a pack needs the completed record, not just what's outstanding.
5. **Run the same completeness checks as Data Integrity Check** on the scoped set (missing required fields, missing photos/signatures, logic contradictions, placeholder values). A pack with known gaps states them plainly — an audit pack that hides a problem is worse than no pack at all.
6. **Compile each record's evidence**: identifying info (asset/site/inspector), the key field values relevant to the use case, signature status, photo count/presence, and the timestamp of each key step.
7. **If the audience is external**, suppress assignee names and internal notes per step 2's audience setting — everything else about the record's evidence stays intact.
8. **Aggregate a cover summary**: total records in scope, completion rate, count with all evidence present vs. any gap, and the actual date range covered by the pulled data (which may be narrower than the requested range if the data doesn't go back that far — say so if it doesn't).
9. **Render as one widget.** Unlike the other Fluix skills, don't cap the record list to keep it short — an audit pack is meant to be comprehensive, so it uses a table, not individual cards, precisely because a table scales to any count without artificially limiting it. If the scope is very large (roughly 100+ records), show a breakdown (by site or by week, as a chart) and offer to export or list the rest, rather than silently truncating evidence the way "+N more" does elsewhere.

## Output format

One widget — no separate text block.

**The widget**, in this order:
1. A metric-card strip: records in scope, completion rate, fully-evidenced count, gaps found.
2. A small proportion bar showing fully-evidenced vs. has-a-gap as a visual share of the total — the at-a-glance companion to the completion-rate card, paired with labels since a bar alone doesn't say what the colors mean.
3. A full record table, not cards — every record in scope: ID, key fields, signature status, photo count, completed date. This is the comprehensive part of the pack, so it isn't capped the way findings lists are elsewhere. When the scope is very large, replace the inline table with a breakdown chart (by site or week) and state that the full list is available on request rather than rendering hundreds of rows inline.
4. A compact gaps list — one line per record with a gap (icon + record + what's missing), kept lightweight rather than full-size cards so it stays scannable regardless of count. "No gaps found — every record in scope has complete evidence" when the set is clean.
5. A muted footer line: the actual date range covered vs. requested, sample size, and a demo/sample-data flag if warranted.

## Guardrails

- Never omit or soften a gap to make the pack look more complete than it is — state every gap plainly, since an audit pack that hides a problem is a liability, not a deliverable.
- Never fabricate a signature, photo, or timestamp that isn't actually present in the data.
- Require an actual scope (date range and/or site/asset) before pulling data — never silently compile the account's entire history.
- Apply external-audience suppression only when the request actually signals external use — default to full internal detail otherwise.
- This skill only compiles and reports — it never generates, backfills, or resubmits missing evidence.
- The record table is deliberately uncapped — the "+N more, cap at 5-8" pattern the other Fluix skills use for findings lists doesn't apply here; if the scope is genuinely too large for one response, offer a breakdown or export instead of silently truncating evidence.
- Keep the gaps list compact (one line per record) rather than full-size cards — the point is staying scannable at any count, not visual weight per item.
- Same data-quality stance as the other Fluix skills — state plainly if this looks like demo/sample data, since an audit pack built on test data isn't real evidence.