Review fictional sample data against a shared field contract

A small sample can look reasonable while different readers interpret its fields differently. Review an expressly fictional planning CSV in an existing document or spreadsheet before using it to explain a process. The outcome is a field contract and a mismatch register. This is a human review of synthetic rows, not a Kiguri CSV import or an automated data migration.

Define what each field represents

Create a small invented sample with task identifier, planned effort, effort unit, and target date. Write a companion contract explaining each field's purpose, permitted value type, requiredness, and scope. Decide whether task identifiers are unique across the entire sample or only within a project. State the date format in words and with an unambiguous example.

For this practice, include two rows named TASK-04, one blank effort value, one explicit zero, and a date written as 04/05/2026. These are deliberately synthetic test conditions, not actual project records. Keep the sample small enough that reviewers can point to the precise row and field behind every finding.

Keep missing, zero, and not applicable separate

Ask what a blank effort means before replacing it. It could mean no estimate has been supplied. An explicit zero might mean that no additional effort is planned. A not-applicable value may describe an activity for which effort estimation makes no sense. Those states need different rules if they are all permitted.

Specify the allowed representation of each state in the contract. If the team has not decided, record an unresolved rule rather than selecting the most convenient value. Treating a blank as zero can make the sample appear complete while silently changing its meaning. A visually tidy column is not evidence of consistent interpretation.

Check types, units, and cross-row rules

Compare every row with the agreed representation. A numeric effort field should not contain an unexplained word such as small if the contract requires numbers. A quantity written as two days cannot be compared directly with two hours without an agreed interpretation. Record the original value and its declared unit instead of guessing a conversion.

Check repeated identifiers within the defined scope. Two TASK-04 rows are invalid only if the contract forbids that duplication in their context. Also identify dates that remain ambiguous under the stated rule. Do not silently choose April or May for 04/05/2026. The reviewer must distinguish a rule violation from a rule that was never established.

Give each mismatch a decision path

Create a register naming the row, field, observed value, applicable rule, and finding category. Label one row as violating an agreed requirement and another as needing a contract decision. Assign an owner to unresolved choices and retain the original synthetic value while the decision is open.

For example, a duplicate identifier under a confirmed sample-wide uniqueness rule needs a corrected identifier. An ambiguous date with no format rule first needs agreement on representation, followed by an explicitly justified correction. Neither can be resolved by changing every suspicious value until the sheet looks uniform.

Revise both sample and contract, then recheck

After decisions are made, update the rules and the affected fictional rows together. Repeat the field checks and uniqueness checks across the entire sample, including rows that initially looked correct. A revised identifier rule can change which earlier finding was valid.

Ask another reader to classify one remaining issue using the contract alone. If they cannot tell whether it is invalid or undefined, the contract needs clarification. Keep accepted rules, corrections, and unresolved decisions together. A useful sample is one whose meaning can be checked, not one that merely contains no obvious empty cells.