A catalogue field such as is_complete can look harmless. It becomes ambiguous as soon as two people mean different things by “complete.” One means all regular episodes through season five. Another includes television films. A third is checking whether every disc is present in a used copy.
Those are different claims. In a product catalogue, I would store the underlying scope and evidence separately, then derive a carefully bounded display label. The design below is a proposal using fictional examples, not a description of a deployed system.
Identify which kind of completeness you mean
Start by separating content coverage from physical-copy completeness. Content coverage asks which works an edition includes. Copy completeness asks whether an individual item for sale contains all of that edition's expected components.
A complete copy of a five-season edition does not imply that every season ever produced is included. Conversely, an edition intended to contain the entire programme can still be sold as an incomplete used copy.
Putting both meanings into one Boolean makes it possible for a true value from one workflow to answer the wrong question in another.
Give the scope an explicit boundary
A coverage claim needs a target. That target might be regular episodes in seasons one through five, a named collection of television films, or a specific set of content identifiers. Store that boundary rather than leaving it in a product title alone.
For an ongoing series, a phrase such as “all released seasons” is time-dependent. Record the date or catalogue revision against which that claim was assessed. Newly announced content should not silently change the meaning of an old edition record.
The public label can be concrete: “Includes seasons 1–5; specials not confirmed.” It conveys more than an unqualified “Complete” badge and remains useful when the catalogue grows.
Model edition contents as relationships
Keep a content identity separate from an edition identity. Link an edition to the episodes, specials and supplementary items it is known to contain. Use stable identifiers for those links; titles and display numbers are not reliable substitutes for identity.
Content types can distinguish a regular episode from a special, film or extra. Do not assume every item fits a season-and-episode pair. A named reunion or an interview can be represented without inventing an episode number.
Physical layout is another relationship. Disc assignment can help a user locate content, but disc count should not stand in for coverage. An edition-to-content mapping and an edition-to-disc layout answer different questions.
Preserve uncertainty in the source data
For each relevant content relationship, distinguish confirmed included, confirmed excluded and not verified. An absent row should not automatically mean excluded unless the data contract explicitly guarantees an exhaustive inventory.
Store the evidence behind a claim: a source reference, a short note and a checked date. An exact-edition contents list and a generic series description should not carry the same meaning in the verification workflow.
When sources conflict, retain the conflict for review instead of choosing whichever value was imported most recently. A confident badge generated from unresolved inputs hides the work still required.
Derive labels from a defined rule
Suppose the expected set is all regular episodes in a stated season range. Let the included set contain only the episodes verified for that edition. A coverage check asks whether every expected episode is in the included set.
That calculation says nothing about specials outside the expected set. It also depends on the expected set itself being trustworthy. If the reference inventory is incomplete, the result should remain unverified rather than borrowing certainty from a successful set comparison.
Keep the rule version with the result if the rule can change. A later decision to include specials in a display category should trigger reassessment, not reinterpret old true values without explanation.
Keep copy condition in its own record
A used-copy record can reference the edition's expected discs and components. It can then record which components are present, missing or unchecked for that particular copy.
Do not write a missing disc back into the edition's content definition. That would make one seller's incomplete copy appear to redefine every copy of the release.
Likewise, a sealed or visually tidy package is a condition observation, not proof that an edition includes a requested special. Keep the evidence attached to the claim it actually supports.
Test cases that expose ambiguity
Useful cases include an edition with all regular episodes but unverified specials; a complete five-season range within a longer programme; two editions with different extras; and a used copy missing one disc from an otherwise fully documented edition.
Also test an incomplete reference inventory, conflicting source descriptions and a corrected mapping. An import should not downgrade confirmed evidence merely because a newer feed omits the field.
Check the public wording as well as the data result. A technically correct rule can still produce a misleading label if the interface hides its season boundary or uncertainty.
Make the product page specific
Most shoppers do not need to see the internal model. They need the season range, verified coverage, named specials and extras, and any unresolved detail that could change their decision.
The catalogue can be detailed behind the scenes while the interface stays concise. Replacing one ambiguous checkbox with explicit relationships makes that possible: the product page can describe what is known without promising more than the evidence supports.
Top comments (0)