# Fluix Data Integrity Check

**One-line purpose:** Audit any Fluix report or dataset for missing or inconsistent data — required fields left blank, photos or signatures never captured, placeholder/garbage values, mismatched template versions, and logic contradictions between fields (e.g. "needs replacement" and "approved for use" on the same record). A read-only integrity pass, not a dashboard, digest, or action list — this one answers "can I trust this data?"

---

## When to trigger it

- "Check `<report>` for missing data" / "is anything incomplete?"
- "Are all required photos attached?" / "is anything missing a signature?"
- "Audit `<report>` for data quality" / "which records are messy or inconsistent?"
- "Can I trust this data?" / "is this report reliable?"
- Any request about completeness, missing fields/media/signatures, or data trustworthiness — as opposed to what the data shows (Dashboard), what changed (Pulse Digests), or what needs action (Priority Focus)

## 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 report is named, ask which one.

Optional, inferred from context or defaulted:
- **Specific fields to check** — if the person names particular fields ("check signatures" or "are all photos there"), narrow to those. Otherwise check everything the schema supports (required fields, media, signatures, logic consistency, template versions).
- **Scope: whole report vs. one record** — defaults to the whole report. If a specific record/ID is named, narrow to that one record's completeness only.

## Workflow steps

1. **Find the data source and confirm tool family** — identical to the other Fluix skills.
2. **Get the schema first, always** — classify fields as in the other skills, but specifically separate out:
   - **Media/image fields** (photo attachments tied to a step or check item)
   - **Signature fields** (inspector, customer, supervisor, etc.)
   - **Fields whose "required" status must be inferred**, since the schema may not flag this explicitly: a field populated in the large majority of *finished/closed* records is presumptively required; a field only ever populated in later-stage records isn't missing on an earlier-stage one, it just hasn't been reached yet.
3. **Pull the rows.**
4. **Check completion status before flagging anything** — a record still at an early workflow step (task status TODO/IN_PROGRESS, low task-completion %) is expected to have later-stage fields blank; that is not a data-quality gap. Only flag a field as missing when the record's own status indicates that field should already have been filled (task marked finished/closed, or past the step that field belongs to).
5. **Check for these gap types**, scoped to records where step 4 says the field should be present:
   - **Missing required field values** — blank where population rate elsewhere shows the field is normally filled.
   - **Missing photos** — an image/media field left empty where a paired check item has a value.
   - **Missing signatures** — inspector/customer/supervisor signature fields empty or explicitly "unsigned" on a finished record.
   - **Logic contradictions** — two fields on the same record that can't both be true (e.g. condition = "needs replacement" and approved-for-use = "yes"; a failed safety-critical check paired with "no issues reported"). State the exact two field/value pairs that conflict.
   - **Placeholder/suspicious values** — a value that doesn't fit its field's evident purpose (an address in a free-text description field, a generic "test"/"n/a" repeated across otherwise-varied records, sequential fake-looking IDs). Flag these as "looks like a placeholder — worth checking," never as a confirmed error.
   - **Template/workflow version inconsistencies** — the same report containing more than one distinct workflow name/version, especially where one version has a different set of populated fields than the other.
6. **Aggregate into an overall completeness picture**: a completion rate (records with zero flagged gaps ÷ total eligible records), and counts per gap type. Rank individual flagged records by how many distinct gap types they have, not just by count of blank fields.
7. **Cap the per-record list** at roughly 5-8 worst offenders, same as the Priority Focus skill, noting "+N more records also flagged" rather than listing every record.
8. **Render as the fixed template below** — a small metric-card strip (same visual spec as the other Fluix skills: label / number, color only when unambiguous) for the headline counts, followed by the text breakdown by gap type.

## Output format

```
Data completeness check — [report/scope name]

[card strip: overall completeness rate, missing signatures, missing photos, logic contradictions]

Missing required fields:
- [record] — [field(s)]
(or: "No missing required fields found.")

Missing photos / signatures:
- [record] — [what's missing]
(or: "All required photos and signatures are present.")

Logic contradictions:
- [record] — [field A = value] contradicts [field B = value]
(or: "No contradictions found.")

Suspicious / placeholder values:
- [record] — [field] looks like [placeholder pattern], worth checking
(or: "Nothing suspicious found.")

Template/schema notes:
- [note on multiple workflow versions or inconsistent field sets, if any]
(or: "Single consistent template in use.")

Data confidence: [sample size, and whether this is demo/sample data]
```

Every section always appears, even when clean — "No missing required fields found" is as important a result as a list of gaps, since it answers the trust question either way.

## Guardrails

- Never flag a blank field on a record that hasn't reached that stage yet — check workflow/task status first, every time, before treating blank as missing.
- Never state a placeholder/suspicious value as a confirmed error — describe what looks off and why, and invite the person to verify, since this skill can't confirm ground truth.
- Never modify, fill in, sign, or resubmit any record — this is read-only. If the person wants something fixed, that's a separate, explicitly confirmed action.
- Cap the per-record list; "+N more flagged" is correct, dumping every incomplete record is not.
- Infer "required" from population patterns across completed records, not from field naming or guesswork — don't assume a field is mandatory just because it sounds important.
- Keep the same data-quality stance as the other Fluix skills: state plainly if this looks like demo/sample data, since flagged gaps in test data don't carry the same weight as gaps in live records.
- If the metric-card strip is used, follow the same visual spec as the other Fluix skills — don't introduce a new card style.