A Minimum Data Model for Reconstructing a QC Decision

Six months after a unit ships, someone asks a narrow question: what was checked on this item, by whom, against which version of the standard, and who authorised it to leave. Plenty of ecommerce teams inspect diligently and still cannot answer, because the inspection produced a judgment rather than a record that resolves back to a unit.

That is a data modelling problem before it is a quality problem. What follows is the minimum set of entities, keys, and state transitions needed to reconstruct a single QC decision later — written for operators and for the developers who build the systems they work in.

When this is worth modelling

High value here means expected-loss exposure, not a universal price threshold. The question is not whether the item costs more than some number, but what one bad unit reaching a customer costs across replacement, freight, dispute handling, and the time spent arguing about what happened. Where that exposure is large relative to margin, a reconstructable record is worth its overhead. Where it is not, it usually is not.

Three layers, two different jobs

L1 — SKU-level Judgment Standard. For each checkpoint on a SKU: the object being checked, the method, the pass rule, the fail rule, and the evidence form required.

L2 — Traceable Inspection Record. A record that resolves to a SKU, batch, order, or unit and preserves record ID, inspector, date and time, station, equipment and calibration where relevant, original evidence files, modification history, links to any exception, reinspection, or release, and the spec revision checked against.

L3 — Release Control. A failed unit is physically isolated, the matching system state is set, a reinspection creates a new record rather than overwriting the failed one, and a named authorised release owner is required.

L1 and L2 establish evidence. L3 controls whether a failed unit ships. Those are different jobs, and conflating them is the common design error: a team builds careful checklists and clean evidence storage, then a failed unit leaves anyway because no state in the system blocks it.

The four entities

SKU control plan. Fields: SKU; spec version; checkpoint; object; method; pass rule; fail rule; evidence form required. Natural key is (SKU, spec version, checkpoint). Treat spec version as part of the key, not as a mutable column — an inspection is only interpretable against the revision that was in force when it happened.

Inspection record. Fields: record ID; SKU / order / unit; inspector; date and time; station; equipment and calibration; spec version checked against; result; evidence files. It carries a foreign key to a specific control plan version, never to whatever the current standard happens to be.

Exception and reinspection record. Fields: exception ID; linked inspection record; exception type; isolation action taken; escalation path; reinspection ID; reinspection result; date. This is the entity most systems skip, and skipping it is why failures become invisible: without it, the only way to record a recovered unit is to edit the failure away.

Release authorization. Fields: SKU / order / unit; standard version; inspection record ID or reinspection ID; release decision; release owner name; date; signature. It points at the record it relies on, so the authority and the evidence stay joined.

These are field schemas — tools for you to populate, not filled-in records or case evidence from anyone else's operation.

Identifiers

Every record must resolve to something physical: a SKU, a batch, an order, or a unit. An inspection attached only to a date and a supplier name cannot be reconstructed, because there is no path from a returned item back to the row. Decide the resolution level per SKU before you build. For serialised goods the unit is the key, and the serial or date code belongs in the evidence itself, not only in a database column that nobody can verify against the object.

Immutable history

The failed record is the point of the system. Model inspection results as append-only: a correction is a new row with modification history preserved, and a recovered unit is a new reinspection record linked to the original failure. An update that turns a fail into a pass destroys the only thing that made the record worth keeping. If your ORM makes in-place edits easy, put the constraint in the database rather than in application convention.

Ownership

Release owner is a person's name, not a role queue, a shared login, or a service account. Every record needs an identified inspector and every authorisation an identified owner. Systems that authenticate as a shared station account produce records that answer which terminal was used instead of which person decided, and the second question is the one asked afterwards.

The retrieval test

The model is only real if it retrieves. Pick a shipped unit at random, hand the identifier to someone who did not inspect it, and ask them to produce, without help: the control plan version in force, the inspection record, the original evidence files, any exception and reinspection, and the release authorisation with a name on it. If that takes searching chat threads or asking the person who did the work, the entities exist on paper only. Run this as a scheduled exercise, not once at launch.

Release-state transitions

Model release explicitly rather than inferring it from a result field:

• pending to pass to releasable
• pending to fail to isolated, with physical isolation and the system state set to match
• isolated to reinspection, which creates a new inspection record while the failed record stays
• reinspection pass to released, only with a named authorised release owner

There is no edge from fail to released. Physical state and system state change together, or you have built a system that describes a warehouse which does not exist.

The path that overrides the model

Potential safety or regulatory risk is not a release decision and does not belong in this flow. It follows a separate path: stop sale, quarantine potentially affected stock, pause open orders, and escalate to a qualified safety or compliance lead. A commercial release signature cannot override safety, regulatory, stop-sale, recall, or reporting duties. Build the escalation as its own state, reachable from any point, and do not let a release form close it.

What records do and do not do

Photo or video selection is fact-specific. Images can fix appearance, labels, accessories, packed condition, and serial or date codes; claims about motion or continuity may require video. Neither format guarantees an outcome.

A complete record helps reconstruct what happened and identify a unit. It does not decide how a payment platform, carrier, marketplace, or regulator will rule, and it guarantees no chargeback, return, carrier, marketplace, or regulatory result. Retention works the same way: set it against the longest applicable process your operation actually faces, since no universal period follows from the model itself.

Source and provenance for the underlying QC framing: ASG Dropshipping, https://asgdropshipping.com/qc-proof-high-ticket-products-photo-video-checklist/