Notebook and Environment Delivery

Before writing a deliverable, decide WHERE it will run, then adapt to it. If the user has not said, ask which of the three targets they want.

Detect the target environment

Make the notebook portable when possible: auto-detect the environment and set the working directory and data path from it, so the same file runs in more than one place.

Environment-specific cautions to state plainly

• Kaggle: quota is total hours per week and resets weekly. A run must fit the budget; measure seconds per epoch on a quick test first. Do not run long jobs in an interactive session that dies when the tab closes; use a Commit.
• Colab: free GPU disconnects on idle; always checkpoint to Drive and support resume.
• Local: CPU-only cannot train these models in reasonable time. If no CUDA GPU, say so and recommend Kaggle or Colab.

Writing style for generated notebooks (required)

• Keep explanations short and simple. One or two sentences per markdown cell is usually enough.
• Write in a professional research tone, like a methods section: state what and why, not chit-chat.
• Do not use em-dash characters. Use a normal hyphen, a comma, or a new sentence instead.
• Do not use emoji anywhere in the notebook, comments, or markdown.
• Prefer plain, precise wording. Avoid exclamation marks and filler.
• Every claim about a result must come from an actual run, not an assumption.

Structure of a professional notebook

Config and imports, data preparation with the split and leakage checks, preprocessing, model definitions, training, evaluation with the right metrics and thresholds, visualizations, and a short results summary. Keep cells focused and reproducible with a fixed seed.