Editorial guidance, not a report of an actual event. The question this piece answers is procedural: how do you keep a nail sample observation record honest when some units were checked and others never were? The answer is to stop letting one word — "passed" — cover two very different states. Everything below is a proposed walkthrough and a hypothetical example; it describes no specific buyer, conversation, inspection, or outcome, and it attributes only the verified 365nails service facts named near the end.
The decision and the input record
The decision is a per-field one: for every observation line in a nail sample record, does this line carry an actual check result, or does it carry the absence of a check? Those are not the same, and they should not share a status value.
The input record is the sample observation sheet itself — one row per sample or per attribute, with, at minimum: the sample identifier, the attribute being observed (shape, finish, color, sizing, decoration alignment, packaging print), who observed it, the method used, the date, the observed result, and a status field. If the status field currently allows "passed" for untouched rows, that is the flaw the record needs to fix before any comparison is made.
A proposed walkthrough (editorial guidance only)
- Freeze the vocabulary. Use three states only: passed, failed, not inspected. Do not permit a blank cell, a dash, or "ok" to stand in for any of them.
- Stamp non-observation at the row level. Any row without a named observer and a method is not inspected by definition, regardless of how the sample looked when it arrived.
- Separate the ledger from the conclusion. The observation rows are evidence; the summary line is a conclusion. The summary must inherit the weakest row, not the best.
- Mark partial coverage explicitly. If three of five attributes were checked, the record says "3 of 5 inspected," never "sample passed."
- Keep the open fields open. Fields you cannot fill — an unresolved attribute, a missing method, an undated observation — stay visibly blank rather than being inferred from a neighbor.
- Re-read the summary against the rows. Before the record leaves the desk, check that every "passed" in the summary traces to a row with a named observer and a visible method.
Step 6 is the whole discipline. Most inflated sample records are not dishonest; they are summaries that drifted one state away from their own rows.
Evidence to request, fields to leave open, and the limit
Request observable evidence only: the raw observation rows with observer and method named, the sample identifier chain linking row to physical sample, the date of each observation, and the current status of every attribute. None of that asks anyone to characterize quality in prose; it asks for the record to show its work.
Leave these open rather than guessing:
- Attributes never examined on a given unit.
- Rows whose observer cannot be identified.
- Any comparison between two lots where one lot's coverage differs from the other's.
- Any claim about a whole production run drawn from a sample record alone.
The limit of the conclusion is narrow and worth stating plainly: a sample observation record tells you what was checked and what was not, for the units in hand. It does not certify a run, predict customer experience, or substitute for an inspection that was never performed. A record that separates not inspected from passed is more useful precisely because it is less flattering.
From the 365 Workbench
On the 365nails side, the verified terms are these: 365nails custom projects include sample approval before production and quality-check progress in the project workspace. That is a statement about how custom projects are structured and where progress is recorded — it is not a claim that any particular sample passed anything. And for a confirmed product quality issue, 365nails supports a refund without requiring return of the affected product, with the team reviewing the issue and confirming refund details. Both statements live at their published sources: the customization page and the refund policy. Everything in this article about how to label a row is editorial guidance, not policy text.
Operator Move
Open your current sample observation record and run one pass: find every cell that reads “passed” and ask whether it has a named observer, a stated method, and a date attached. Any cell that fails that test is reclassified as not inspected today, while the memory is still fresh enough to correct it. Then change the summary rule so a record can never report "passed" at a coverage lower than its own rows support. The operator move is not a bigger inspection — it is an honest one.
