A model can produce an impressive-looking score from data it should never have seen. Before selecting an algorithm, define the prediction and the moment when it will be made. For this exercise, imagine a support queue that predicts whether a new ticket will need specialist review. The prediction happens when the ticket arrives.
That timing rules out several tempting columns. A resolution note written days later cannot help an arrival-time decision in the real application. Neither can a field that directly records the specialist's final action. Keeping those columns in the training input would make the learning exercise misleading.
Write a data dictionary with a purpose
Start with fictional records and describe each field. ticket_id identifies the record. received_at is the arrival timestamp. message is the text available at arrival. needs_specialist is the label assigned later under a defined review policy. resolved_at is a later operational field that should not become an input for this prediction.
For every candidate input, record where it came from, when it became available and what a missing value means. An absent language code may mean the detector did not run. A blank message might be a failed import. Those are different conditions and should not silently become the same default.
Keep personal information out of the practice dataset. For a real project, confirm the rights and permissions needed for the intended use, and follow the data owner's handling requirements. A public download link alone does not establish permission to republish records or send them to an external model service.
Inspect a record before processing a thousand
Paste this deliberately small fictional document into the JSON formatter and Pointer inspector:
{
"tickets": [
{
"ticket_id": "demo-17",
"received_at": "2026-11-01T09:00:00Z",
"message": "The export button shows an error.",
"needs_specialist": true,
"resolved_at": null
},
{
"ticket_id": "demo-18",
"received_at": "2026-11-01T09:05:00Z",
"message": "",
"needs_specialist": false,
"resolved_at": null
}
]
}The tool processes this input in the browser without uploading it to a server. Use fictional data anyway, especially on shared devices. Formatting makes structure easier to read; it does not certify that labels are correct or that a dataset is suitable for training.
Enter /tickets/0/message as the JSON Pointer. The expected value is the export-button message. Enter /tickets/1/message and expect an empty string. That empty string exists; it is different from asking for /tickets/2/message, whose array entry is missing. RFC 6901 defines Pointer syntax, including zero-based array indices and escaping for names containing slash or tilde.
Now remove a required comma and try formatting again. Expect a syntax error rather than a corrected dataset. Restore the comma before continuing. RFC 8259 describes JSON's syntax; parseable JSON still needs application-specific checks for required fields, dates and permitted values.
Check duplicates according to the business record
Two tickets can contain the same message without being duplicates. Conversely, the same ticket id imported twice remains a duplicate even if one copy has a later status. Choose the columns that define a record before removing anything. Keep a record of the decision so an import can be repeated and explained.
With pandas, DataFrame.duplicated can inspect selected columns and can mark all members of a duplicate group with keep=False. Its official reference documents those options. Review the flagged rows before dropping them; an automatic keep-first rule may discard the more complete record.
Protect the evaluation from future information
Separate training and evaluation data before fitting preprocessing that learns from the data. For example, learn a vocabulary or imputation rule from training records, then apply the learned transformation to evaluation records. The scikit-learn pitfalls guide explains how leakage and inconsistent preprocessing distort results.
Choose the split to match the task. A future-ticket prediction calls for considering time order. Repeated tickets from one customer or incident may need grouping to prevent near copies crossing the boundary. A random split is a tool, not an automatic guarantee of a fair evaluation.
- Mark the empty message in the sample as a data-quality issue.
- Add a duplicate demo-17 record and identify it by ticket_id.
- Write the allowed arrival-time input fields separately from labels and later fields.
- Describe a baseline, such as always predicting the most common training label, before training a model.
The expected result is an auditable input definition and a list of rejected or unresolved records. This tiny example cannot establish accuracy, fairness or production readiness. It can establish whether you understand what the model would know at the moment someone asks it to predict.