Skip to learning content

DATA SCIENCE PYTHON PLAYGROUND

Machine Learning · Learn / Refresh

← Supervised Workflow lessonsQUESTIONS · MODELS · EVIDENCE
Debug and demonstrate readiness · ML-W-K2 · 35–50 MIN

Readiness · unfamiliar regression

Readiness · Build and explain independently

Exercises within this concept

  1. ReadinessBuild and explain independentlyCurrent exercise
Readiness · REPAIR96

At repair intake, give a customer an estimate of the time until their repair is finished.

Independently estimate a new repair’s completion time at intake. Choose and justify the target, available features, split, metric and simple candidate(s). Build the workflow without viewing the solution first. Use actual numbers to explain baseline, validation, final result and limitations. The rubric is visible; reasoning requires self-review or lecturer review.

Next: Readiness · unfamiliar classification.

The question and data dictionary

At repair intake, give a customer an estimate of the time until their repair is finished.

One independent device per ticket, from a stable workshop period. No devices repeat and there is no time-order field. Either typical absolute error or stronger penalties for large errors can be defended.

Decide what can be known at prediction time
ColumnMeaning and availability
ticket_idAdministrative identifier, assigned independently of the repair process.
jobs_waitingJobs already waiting at intake.
device_age_yearsDevice age in years, supplied at intake.
repair_hoursElapsed hours from intake to completion.
invoice_labor_hoursRecorded on the completed repair invoice.

The playground workflow

Use the same data boundary as ML → Workflow: frame, split, explore, prepare, validate against a reference, diagnose, then make the final evaluation. Each step answers one question.

  1. Question → X / yName the outcome and the inputs available when the prediction is needed. Later outcomes, identifiers and outcome-derived fields are not predictors.
  2. Split and protectReserve final rows before inspecting distributions or fitting. Independent rows permit a shuffled holdout; repeated entities or future forecasting need different designs.
  3. Explore training rowsInspect only development rows to identify types, missingness and class balance.
  4. Prepare → modelPut learned preparation inside a Pipeline so each fold learns it afresh. A numeric linear model can pass the original units through.
  5. Baseline → validateA dummy establishes what ignoring X achieves. Fit the candidate on matching training folds; these validation rows are not the final test.
  6. Choose → diagnoseChoose using training evidence, then inspect held-out training predictions. Simplify a model that fails to generalise; do not open the final test to choose.
  7. Final fit → predict → metricFix the recipe, fit all training rows, predict reserved rows once and calculate the declared metric from those saved predictions.
  8. Interpret and limitCompare validation with the baseline and final evidence. State units or class error costs, uncertainty from the small sample, and the population to which the claim applies.

Readiness rubric · self-review

For each criterion: 0 = missing or unsafe; 1 = plausible but unsupported; 2 = correct and supported by your actual evidence. Aim for 2 on every criterion. A target leak, test-driven selection or test-row fit means the boundary must be repaired before a readiness claim. Code checks cannot award these reasoning scores.

  1. Frame and boundaryName prediction time, observation, target and unavailable inputs. Choose a split that matches intended use.
  2. Preparation and baselineFit learned preparation inside each training fold. Compare the dummy on those same folds.
  3. Validation and selectionChoose from training-fold scores and error patterns. Explain any gap between training and validation.
  4. Metric and final testJustify the metric and interpret the reserved-test result. Do not revise the recipe using that result.
  5. Interpretation and limitsQuote baseline, validation and final results. Explain error units or costs, one failure case and one limit; avoid causal claims.

Use the interpretation field beside your output. After an attempt, Check identifies code evidence and shows reasoning guidance. The optional explained solution is one defensible approach, not the only acceptable answer.

Your inputs · REPAIR96

96 synthetic independent observations. The dataframe df is supplied afresh on each Run. Column availability is described in the question’s dictionary above.

REPAIR96 · first 8 rows
ticket_idjobs_waitingdevice_age_yearsrepair_hoursinvoice_labor_hours
900009.2645110.140310.3403
9001119.8136428.583828.7838
900285.8591919.835820.0358
900319.9134713.173613.3736
9004111.9555220.159720.3597
900535.1669312.896913.0969
900633.0164911.31411.514
900712.667538.309318.50931

Supporting concepts: When a good score is misleading → · Learn missing-value replacements safely → · Respect time →

Remember the idea

At repair intake, give a customer an estimate of the time until their repair is finished. Use the dictionary to frame a prediction claim. This dataset has not appeared in the teaching path. A working script is only one part of readiness: each decision also needs an evidence-based explanation.

At repair intake, give a customer an estimate of the time until their repair is finished.Question / X, ySplit: reserve testTraining-only foldsDummy + candidateChoose + diagnoseFinal predict / explainFit preparation inside folds. Open final evidence once.
Schematic · At repair intake, give a customer an estimate of the time until their repair is finished.Scroll the diagram horizontally if needed.

Required Python variables and evidence

Use these names so Check can inspect your workflow. Each meaning is shown beside its name.

Workflow evidence contract
VariableMeaning
target / feature_namesYour outcome column name and list of legitimate inputs. Choose from the data dictionary.
X / y / X_train / X_test / y_train / y_testOriginal indexed feature/target data and aligned partitions. A 15–30% holdout is supported; choose and justify its seed/design.
folds / metricA 3–5-fold shuffled KFold or StratifiedKFold object; metric is an sklearn scoring name. Regression: neg_root_mean_squared_error or neg_mean_absolute_error. Classification: f1_macro or balanced_accuracy.
reference / reference_resultsDummy estimator and its actual cross_validate result.
candidates / cv_resultsNamed Pipelines and matching cross_validate result dictionaries. Regression supports LinearRegression, Ridge and DecisionTreeRegressor; classification supports LogisticRegression, DecisionTreeClassifier, KNeighborsClassifier, GaussianNB, LinearDiscriminantAnalysis, SVC and MLPClassifier.
diagnostic_predictionsActual cross_val_predict outputs for the chosen candidate on training folds; inspect residuals or a confusion table.
chosen_name / final_modelName of your chosen validated candidate and a clone fitted on all training rows. Defend the choice, including any simplicity trade-off.
final_predictions / final_scoreOne saved final prediction array and its final metric. Positive error units for regression. No further selection after this call.
Hint 1 — Think

Independently estimate a new repair’s completion time at intake. Choose and justify the target, available features, split, metric and simple candidate(s). Build the workflow without viewing the solution first. Use actual numbers to explain baseline, validation, final result and limitations. The rubric is visible; reasoning requires self-review or lecturer review. At repair intake, give a customer an estimate of the time until their repair is finished. Which fields exist at that moment?

Hint 2 — Tools

Use a dataframe/series pair, train_test_split, Pipeline, cross_validate and a dummy suited to a numeric outcome.

Hint 3 — Approach

Keep final rows outside every fit. Compare matching training-fold evidence before predicting reserved rows in REPAIR96.

Explained solution
from sklearn.model_selection import train_test_split, KFold, cross_validate, cross_val_predict
from sklearn.pipeline import Pipeline
from sklearn.linear_model import LinearRegression
from sklearn.dummy import DummyRegressor
from sklearn.base import clone
from sklearn.metrics import mean_squared_error
# 1. Question, features available now, and later outcome
feature_names = ['jobs_waiting', 'device_age_years']
target = 'repair_hours'
X, y = df[feature_names], df[target]
# 2. Protect the final test; split X and y together
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=.2, random_state=42)
# 3. Inspect training rows only
print(X_train.describe())
# 4. Define preparation and the candidate; no fitting yet
candidates = {'simple': Pipeline([('prepare', 'passthrough'), ('model', LinearRegression())])}
folds = KFold(n_splits=3, shuffle=True, random_state=42)
metric = 'neg_root_mean_squared_error'
# 5. Compare a reference and candidates on matching training folds
reference = DummyRegressor(strategy="mean")
reference_results = cross_validate(reference, X_train, y_train, cv=folds, scoring=metric)
cv_results = {'simple': cross_validate(candidates['simple'], X_train, y_train, cv=folds, scoring=metric, return_train_score=True)}
print('Reference validation:', reference_results['test_score'])
print('Candidate validation:', cv_results['simple']['test_score'])
print('Candidate minus dummy mean:', cv_results['simple']['test_score'].mean() - reference_results['test_score'].mean())
# 6. Assess the candidate with training evidence; inspect training-only errors
chosen_name = 'simple'  # Sole candidate; report if it does not beat the dummy
diagnostic_predictions = cross_val_predict(candidates[chosen_name], X_train, y_train, cv=folds)
print(pd.DataFrame({'actual': y_train, 'predicted': diagnostic_predictions, 'residual': y_train-diagnostic_predictions}))
# 7. Fit the fixed recipe; predict the final rows once
final_model = clone(candidates[chosen_name]).fit(X_train, y_train)
final_predictions = final_model.predict(X_test)
final_score = np.sqrt(mean_squared_error(y_test, final_predictions))
print('Final metric:', final_score)
# 8. Explain the evidence and its limits in the self-review field

At repair intake, give a customer an estimate of the time until their repair is finished. The reference ignores features. Training-fold evidence informs the choice, and the final metric describes only the reserved sample. Excluding later outcomes prevents answering the question with information unavailable at prediction time. The reasoning rubric needs human review.

Helpful prior knowledge: When a good score is misleading · Supervised Workflow checkpoint These links are guidance, not locks.

Sources and API context

Examples run with this Playground’s scikit-learn 1.4.2 / Pyodide 0.26.4 runtime.

Your task · Readiness

Independently estimate a new repair’s completion time at intake. Choose and justify the target, available features, split, metric and simple candidate(s). Build the workflow without viewing the solution first. Use actual numbers to explain baseline, validation, final result and limitations. The rubric is visible; reasoning requires self-review or lecturer review.

reference_resultscv_resultschosen_namefinal_score
Keep beside your code

At repair intake, give a customer an estimate of the time until their repair is finished.

ticket_idAdministrative identifier, assigned independently of the repair process.
jobs_waitingJobs already waiting at intake.
device_age_yearsDevice age in years, supplied at intake.
repair_hoursElapsed hours from intake to completion.
invoice_labor_hoursRecorded on the completed repair invoice.

Frame → reserve final rows → compare dummy and candidate on training folds → diagnose → fit the fixed recipe → evaluate once.

Ctrl/⌘+Enter: Run · Tab: indent · Esc then Tab: leave editor

Python loads when you run. Code and results stay in this activity only.

Run your code to inspect its output. Check uses that same run.

What repair-time claim is supported by the dummy, training-fold scores and reserved-test result?

Use your Run output as evidence. This response is optional, not machine-graded or saved.