What does a sample review look like when a lab finds a reconciliation fault?

A model lab requests a sample of professional services milestone billing schedules, in JSONL, to test a loader and an evaluation harness.

The lab's data engineer loads the sample and runs a reconciliation script. For agreement **AGR-2046**, a fixed-fee engagement of $90,000 billed across four milestones, the instalment rows sum to $89,990 after a scope adjustment, **ADJ-0077**, moved $15,000 from milestone 3 to milestone 4. The adjustment row shows $15,000 out but only $14,990 in.

The engineer logs the fault with the episode ID and the failing rule: instalments must equal the agreement total after every adjustment. The lab's evaluation lead notes that a grader built on this expected state would mark a correct model answer as wrong.

The team agrees with MirrorFirm that the sum rule becomes a named acceptance check, run on every delivered file. They also add two further checks that the review surfaced: each adjustment must have equal debits and credits across milestones, and every expected final state must itself pass the reconciliation rule.

A corrected sample is generated and rechecked. The lab then decides whether to widen scope.

**What it teaches:** treat the sample as an inspection exercise. Each defect found becomes a written check, which makes later releases easier to accept or reject on evidence.