A spreadsheet can look orderly and still be unsafe to load. Headers may line up, filters may work, and every row may have the same number of columns. Those are useful technical checks, but they do not explain what a value means or whether a relationship is valid.
The release decision needs two separate reviews. First check whether the file can be read consistently. Then check whether the records mean what the receiving process expects. A file passes the first review and fails the second when it contains a duplicate identifier, an unmapped category, or a parent record that points back to itself.
Review the file as a file
Start with the structure that a loader will see:
- Are the headers present, spelled as expected, and unique?
- Does each row parse into the expected number of fields?
- Are delimiters, quoting, and other file-format details consistent?
- Are dates, identifiers, flags, and numbers parseable in the expected formats?
- Does the output preserve the source row or another traceable lineage key?
These checks find problems such as a shifted column, a duplicate header, or a value that has been converted into the wrong type. They are necessary because a technically malformed file may fail before anyone can inspect its meaning. They are not permission to change ambiguous values just to make the sheet look uniform.
Review the business meaning
Next write down the rules that give the columns their meaning. A category field may require an approved map. An identifier may need to be unique. A child record may need an existing parent that is different from itself. An inactive record may still need a historical category rather than an empty one.
Use formulas, filters, or a small script to find candidate exceptions, then review what each exception means. A formula can show that LEG-1004 appears twice; it cannot tell a reviewer which record should survive. A lookup can show that Legacy-Blue is absent from the map; it cannot invent an approved replacement. Keep those decisions visible instead of hiding them in a cleanup step.
Fictional example: clean format, unresolved meaning
The following example is fictional and uses invented identifiers and neutral categories. A ten-row CSV has consistent headers, one row per line, and no broken delimiters. A format-only check can pass it. A business-meaning review finds four different questions: LEG-1004 appears on two rows, one required category is blank, Legacy-Blue has no approved mapping, and LEG-1008 points to itself as a parent.
The correct result is not a prettier ten-row file. The duplicate rows remain traceable, the blank and unmapped values remain unresolved, and the self-reference is held for a relationship decision. Rows with an explicit category mapping can be corrected when the rule is documented. Rows with no approved answer stay held for review.
The fictional implementation data example shows this distinction in a readable fixture. Its input CSV preserves the supplied rows, while the reviewed CSV adds status, decision text, and source lineage. The reviewed output has two ready rows, three corrected rows, and five held for review; no input row is dropped. Those labels describe the fixture’s rules, not a historical client file or an employer result.
Make the release decision explicit
Use a small decision record before handing the file to the next system or person:
- Purpose: What load, report, or process is this file meant to support?
- Technical result: Which structural checks passed, and what exceptions remain?
- Meaning result: Which mappings, uniqueness rules, relationships, and required fields were checked?
- Disposition: Is each row ready, corrected under an explicit rule, or held for review?
- Evidence: Where can the reviewer find the source row, rule, and decision?
- Release gate: What must be true before the file can move forward?
A practical release gate might say: “Release only when every row has a traceable source ID, every category is approved or explicitly held outside the load, identifiers meet the documented uniqueness rule, relationships are valid, and the row count reconciles.” The gate should match the receiving process. If a downstream owner accepts held rows in a staging file, record that decision; do not silently call the file ready.
The useful handoff is a decision record, not a promise that every ambiguity has disappeared. Formatting makes a file readable. Business rules determine whether it is ready.
Applied principles
- Check structure before interpretation
- Use rules to expose questions
- Preserve lineage and unresolved decisions
- Release by an explicit gate
Composite, anonymized examples. No real member information. Views are my own and don't represent HCSC (HealthSpring).