Catch the bad exportbefore it corrupts everything.

Structural checks ask whether the file can even be parsed and lined up: is the header present, unique, and free of blank cells; is every row the same width; is the encoding clean UTF-8; is every required column present; is any column entirely empty. Any one failing forces BLOCK — these are categorical, pass or fail. Quality checks are graduated: each column scores 0–100 on four weighted levers (required-present 10, null-rate 25, type-match 55, format 10), where type-match dominates because a malformed value in a typed column is the real downstream-corruption risk. A column is CLEAN only at quality ≥ 80 with no type mismatch and its null rate within spec.

BLOCK on any structural failure, or if file quality drops below 50 — the file can't be safely processed. READY when there's no structural failure, every column is CLEAN, and quality is ≥ 80 — import it. FIX when the file parses but at least one column is DIRTY or MISSING — it's salvageable, but fix the flagged columns first. The fix-first pointer names the single thing to address: the first structural failure if there is one, otherwise the lowest-scoring dirty column.

No. The CSV / Data-Export Schema & Quality Gate is a gate, not a cleaner — it never transforms, rewrites, or repairs your file. It reads the raw file plus a small schema you define (column name, type, required, allowed null rate), measures real statistics, runs the structural and quality checks, and returns a verdict with a fix-first pointer. You (or the tool that produced the export) make the fix; the included Fix-It Runbook tells you how for each verdict. It's deterministic and offline — same file and schema, same verdict, every time, and nothing is uploaded.

Upstream of it. This gate runs first, on the whole file: can it be parsed, do the columns line up, is the schema right. Only once a file passes here does the Document Field Validator make sense — it checks each record's fields by rule (required, format, range, cross-field). One asks “is this file safe to process at all?”, the other asks “is each row's data valid?” Running the schema gate first means the field validator never wastes a pass on a file whose cells are silently in the wrong columns. It's the upstream force-multiplier for the whole Document Processing line.

CSV and delimited data exports — the kind that fall out of a CRM, a billing system, an analytics tool, or another RedHub kit. You point the runnable Python engine at the file and a JSON schema; it streams the file and measures row width, encoding, header integrity, null rates, and per-column type-match against the types you declared (int, decimal, date, email, enum, and so on). The companion workbook reproduces the same scoring and gate on a pasted sample so you can see the logic without running Python. It grades a file's structure and quality, never people, and it's not legal advice.