Reading your dataset report

You chose classification, but the target holds many distinct numbers — it looks like a quantity to predict.

What to do: Switch the task to regression, or confirm the values really are categories.

You chose regression, but the target has only a handful of repeating values.

What to do: Switch to classification, or confirm the numbers really are quantities.

Every row has the same answer — there is nothing to learn.

What to do: Pick a different target column, or fix the export that flattened it.

One category vastly outnumbers the rest — lesson 3's accuracy trap.

What to do: Auto-handled with balanced class weights; judge the model by balanced accuracy, not plain accuracy.

The target has very many distinct categories, some appearing only once or twice — scores per category become unreliable.

What to do: Group rare categories together, or treat the column as a number if it is one.

The target is lopsided — a few extreme values dominate the range.

What to do: Context only: expect error metrics to be driven by the large values.

A feature mirrors the target suspiciously well — often information recorded AFTER the outcome (a refund column "predicting" cancellations).

What to do: Strong cases block training; deselect the flagged column, or waive explicitly if you are sure it is legitimate.

A column is entirely — or almost entirely — empty.

What to do: Auto-dropped; keep it via the opt-out if the emptiness itself is meaningful.

A column has a noticeable share of empty cells.

What to do: Light gaps are auto-filled from the training data; heavy gaps get flagged for your call.

Every row holds the same value — zero signal.

What to do: Auto-dropped.

Almost every row holds the same value — the rare exceptions might be signal, or just noise.

What to do: Left in place, on purpose: decide whether the rare values are meaningful, and deselect the column if they are not.

A different value in every row — a row number or ID. Pure memorization fuel for a model.

What to do: Auto-dropped.

The column is named like an identifier (id, uuid, serial…).

What to do: Auto-dropped by name; opt out if it is real data.

Two columns are exact copies of each other.

What to do: One copy is auto-dropped.

Two features move together almost perfectly — redundant information.

What to do: Context only; feature selection handles the redundancy.

More columns than the row count can support — an overfitting risk (lesson 1).

What to do: Feature selection tightens automatically; more rows always help.

Exact copies of rows. Copies can land in both the study material and the exam, inflating scores.

What to do: Usually best deduplicated — unless the duplicates are genuinely separate events.

Numbers stored as text — "1,200 SAR", Arabic-Indic digits, currency symbols.

What to do: Auto-cleaned; the same cleaning is applied again at prediction time, so it stays consistent.

A column contains garbled � replacement characters — the file was probably saved with the wrong text encoding.

What to do: Re-export the file as UTF-8 and upload it again; the garbled values cannot be recovered from this copy.

Arabic content detected in the data.

What to do: Context only — handled natively.

A column contains dates.

What to do: Auto-decomposed into learnable parts (year, month, day-of-week…) for regression and classification.

Rows look chronological. A random train/test split can leak the future into the exam and flatter the scores.

What to do: If time matters to your question, consider the forecasting task instead — or read the scores with care.

Not enough rows to run the rotating exams from lesson 1 — any score would be noise.

What to do: Cannot be waived. Collect more rows; a few hundred is a workable floor.

The dataset is too large for the training machine's memory — the job would be killed mid-run.

What to do: Cannot be waived. Reduce rows or columns, or split the problem.

Forecasting needs a column that says WHEN each row happened, and none could be parsed.

What to do: Add or fix a date/time column.

The timestamps follow no consistent rhythm (daily? monthly?), so lags are undefined.

What to do: Resample the data to a regular interval first.

Mostly regular, but some intervals are off.

What to do: Check for missing or duplicated periods before trusting the forecast.

Holes in the timeline — a missing March breaks "each row follows the last".

What to do: Fill or acknowledge the gaps; lags spanning a gap mislead the model.

Too few time points for the lags and horizon you asked for.

What to do: Blocking when truly infeasible; otherwise shorten the lags/horizon or bring more history.

The series trends strongly over time rather than hovering around a level.

What to do: Context only — the lag-based models handle trend; just know far-out forecasts extrapolate it.

A repeating cycle (weekly, yearly…) was found.

What to do: Good news — the lag window is sized so the model can use it.

A supporting feature is empty in the most recent rows — exactly where forecasting needs it.

What to do: Fill the recent values, or drop that feature.

The lag settings generate a very large number of features for the available history.

What to do: Reduce the lag window, or bring more history.

The requested horizon is beyond what the history can support.

What to do: Ask for fewer steps ahead, or bring more history.