What does a first sample review look like for an environment team?

An environment team building a lending simulator requests a sample covering three task families: clean booking, booking after an amendment, and a file that should be returned.

A platform engineer loads the Parquet tables and the JSONL task file into the harness. The manifest check passes, and a key-integrity script confirms that every `facility_id` resolves to an `approval_id`.

A second engineer runs a reference solver over the tasks. Two findings come out:

- TASK-0207 cannot be solved, because the policy document referenced by the task is missing from the folder. - TASK-0215 passes, but so does a deliberately wrong run that activates early, which shows the expected state omits the drawdown flag.

The team also reads a handful of handover notes. One note repeats the wording of another almost exactly, which they record as a variety concern.

They send a short list back: add the missing policy, include `drawdown_enabled` in the expected state, and vary the note phrasing. The next iteration of the sample addresses these items, and the team runs the same checks again.

**What it teaches:** the value of a first sample is the list of defects it surfaces. Decide in advance who runs the checks, what counts as a defect and how it is reported back.