Milestone 1 of 8

Inspect the source and state the contract

Record the source structure, field rules, row count, and two hand-classified examples without changing the file.

Begin with the file, not with a parser. Before writing code, make the source contract visible. Later decisions are easier to check when you can point to the exact headers, field rules, and rows that introduced them.

Milestone goal

Inspect data/raw_measurements.csv, record its structure without editing it, and write a short source contract with two hand-classified examples.

Inputs

Use these read-only inputs:

  • data/raw_measurements.csv;
  • the field names and schema revision in src/schema.py;
  • the small public fixture in tests/public_cases.py.

Do not normalize the CSV, remove defective rows, or replace it with a file that is easier to parse. The original bytes and row order are part of the evidence.

Inspect the source

Record the following in the source-and-contract section of report.md:

  • the source filename and schema revision;
  • the exact header order;
  • the number of data rows, excluding the header;
  • the five field rules from the project overview;
  • two examples, including the source line, raw fields, and the classification you expect after applying the rule.

Use one ordinary valid row and one row that needs a decision, such as a blank reading or a repeated identity. Keep the raw values in the examples. Do not turn an example into a corrected row.

The source contract

Your contract should state these assumptions in plain language:

The header is fixed and ordered.
Each data row has the five named fields.
record_id identifies a source row and is retained in every later artifact.
sensor, observation, reading, and unit are checked under the supplied rules.
Every data row will receive exactly one final status.

The last statement is a project invariant, not a claim that every row is usable.

Deliverables

Save in report.md:

  • the source row count and exact header;
  • two source-linked examples;
  • the five supplied field rules;
  • the validation order you will use in the next milestone.

Checks

Before moving on, check that:

  • the raw file still has the supplied header and row order;
  • the recorded header matches src/schema.py exactly;
  • the row count is reproducible from the file;
  • the two examples quote raw values rather than repaired values;
  • no source row was omitted from your inspection notes.

The public checks can verify the header, field names, and source identity. They cannot decide whether your prose accurately explains an example, so read the two examples against the actual file.

Next step

The next milestone turns each CSV row into a parsed record while preserving the raw fields and source identity. It should consume this contract rather than quietly inventing a new one.

HintStart with the header
A parser that accepts the wrong columns can produce convincing but meaningless records. Compare the header before inspecting values.
HintKeep the two kinds of evidence separate
Raw source fields describe what the file contains. A later classification describes what the project can safely use. Do not overwrite the first with the second.

How to check your work

Checks compare your contract with the supplied fixture. The fixture is a model for traceability, not a substitute for reading the supplied file.

LLM PrimerInspect the source and state the contracthttps://llmprimer.com/python/projects/inspect-and-validate-a-dataset/inspect-source-and-state-the-contract© 2026 LLM Primer