Upload validation
Upload validation reference.
Reference for the IADTX upload validator on app.iadtx.com. Twelve closed subcodes covering format, structure, columns, and session lifetime. Each card explains what triggered the message, the immediate fix, and what to do next when the source data needs upstream change.
Unsupported file type
The uploaded file extension is not one of CSV, TSV, or Excel. The validator rejects the file before any parsing or column inspection happens.
What to do now
Re-export the source data as a CSV, TSV, or Excel file. Keep the column headers on the first row. Save with a clear extension and upload again.
What to do next
If the source is a database export or a Parquet file, run a one-line conversion in your environment of choice. If the source is a PDF or an image, the diagnostic does not apply; IADTX classifies tabular data only.
Encoding error
The file extension was acceptable but the byte stream could not be decoded under any of the encodings the validator tries (UTF-8, UTF-8 with BOM, Latin-1, Windows-1252).
What to do now
Open the file in your spreadsheet tool, save it explicitly as CSV UTF-8, and upload the new file. Most encoding errors come from regional Excel exports that default to a legacy Windows codepage.
What to do next
If the file is generated by a pipeline you control, set the export step to UTF-8 by default. The Insurance sample on the upload page is a known-good UTF-8 reference if you need to compare.
Parse failed
The file extension was acceptable and the byte stream decoded, but the table structure could not be read. Mismatched delimiters, ragged rows, or unescaped quotes are the most common causes.
What to do now
Open the file in your spreadsheet tool, confirm every row has the same number of columns, save again as CSV, and upload. If you exported the file from a pipeline that wraps free-text fields, ensure those fields are properly quoted.
What to do next
The Insurance sample and the AI Labs sample on the upload page are both clean references. If your file parses but the diagnostic returns unexpected results, the parse layer is not the issue and the result-page evidence pack will explain.
Empty file
The file uploaded with zero bytes, or with bytes that decoded into a header row and nothing else.
What to do now
Confirm the source file actually contains data rows. Re-export and upload again.
What to do next
If the source pipeline produced an empty file, that is upstream of IADTX. The diagnostic needs at least the structural-signal floor of rows to return a verdict; see the minimum-rows section below.
File too large
The uploaded file is above the upload byte cap for your tier. The cap exists so the parse step stays bounded and predictable on shared infrastructure.
What to do now
Compress the file to remove redundant columns, downsample rows, or split into smaller files and upload one of them. CSVs are usually large because of free-text columns; remove any free-text column you do not need for the diagnostic.
What to do next
If the file is genuinely large because the diagnostic needs every row, the next step is a tier with a higher upload cap.
Per-tier cap
| Tier | Upload cap |
|---|---|
| Free | 50 MB |
| Growth | 200 MB |
| Pro | 500 MB |
| Business | 2 GB |
| Enterprise | Unlimited |
See the pricing page for the current tier matrix.
Minimum rows not met
The uploaded file parsed cleanly but contains fewer rows than the diagnostic floor. The structural test needs at least the floor count to compute a stable reading.
What to do now
Add more rows from the same source and upload again. The rows do not need to be a particular range or distribution; the diagnostic returns more confident results with more rows but does not bias on which rows you pick.
What to do next
The Insurance sample on the upload page is a 201-row known-good shape reference. If your domain genuinely cannot produce more rows, the diagnostic verdict will likely return as data-insufficient; that is the correct outcome and the result page records it explicitly.
Maximum rows exceeded
The uploaded file parsed cleanly but contains more rows than the per-tier row cap. The cap exists so the diagnostic step stays bounded and predictable on shared infrastructure.
What to do now
Downsample the file to fit your tier cap and upload again. A random sample of the cap size produces an equivalent diagnostic reading; the structural test does not require every row.
What to do next
If the file is genuinely large because the diagnostic needs every row, the next step is a tier with a higher row cap. See the pricing page for the current matrix.
Outcome column not found
The outcome column name you selected on the upload page is not present in the parsed file. Column names are case-sensitive and whitespace-sensitive.
What to do now
Pick a different column from the dropdown on the upload page. The dropdown lists every numeric column in the parsed file; one of them is the outcome you intended.
What to do next
If none of the columns in the dropdown match what you expect, the parse step probably read the wrong row as the header. Re-export the source file with a clean header row and upload again.
Outcome column not numeric
The outcome column you selected is present but its values are not numeric. The diagnostic operates on numeric outcome variables; categorical outcomes are out of scope for this commit.
What to do now
Pick a different column from the dropdown, or transform the categorical outcome into a numeric encoding upstream and re-upload.
What to do next
If your domain is fundamentally categorical (binary classification, multi-class), the diagnostic does not yet apply. Categorical-outcome support is on the roadmap.
Feature column not found
One or more feature column names you submitted are not present in the parsed file. The validator names the missing column in the error card.
What to do now
Re-check the column-name spelling against the dropdown on the upload page. Column names are case-sensitive and whitespace-sensitive. Resubmit with the corrected name.
What to do next
If the missing column was renamed in a recent pipeline change, update your local notes; the parse step always uses the header row as truth.
No feature columns
The parsed file contains the outcome column but no feature columns. The diagnostic needs at least one feature to fit either the multiplicative or the additive model.
What to do now
Add feature columns to the source file and upload again. The diagnostic accepts numeric features; categorical features must be one-hot encoded upstream.
What to do next
If the file genuinely has only one column, the diagnostic does not apply because there is nothing to compose. The Insurance sample is a 30-column reference.
Session expired
The session token associated with your upload has lapsed. Sessions live for 60 minutes from the last interaction; an expired session cannot resume the upload flow it started.
What to do now
Return to the app and start the upload again. Your file is not retained on the server; nothing to recover.
What to do next
If you are running a long-form review and need a longer session, contact us. The 60-minute lifetime is the default; enterprise deployments can configure longer sessions.