Shelfery Data Concepts¶
This document lists, at a conceptual level, the types of data Shelfery
will likely need to reason about, based on the domain concepts in
docs/domain/domain-concepts.md. It is deliberately not a data model,
schema, field list, or database design — those belong to a future
technical/product specification once requirements exist. The purpose here
is to give product, design, and engineering a shared, early sense of what
kinds of information are in scope, and to flag sensitivity considerations
early.
Likely data concept categories¶
- Item identity — information identifying what a pantry item is (e.g. a name or description). No specific identity scheme (barcodes, product databases, free text, etc.) has been decided.
- Quantity — information representing how much of an item is present.
Expected to be approximate rather than precise, per
docs/strategy/product-principles.md. - Storage condition — information about where and how an item is stored (e.g. pantry, refrigerator, freezer), which affects freshness reasoning.
- Date entered — information about when an item was recorded into the household's tracked inventory. This is a user-supplied or system-recorded fact, not a food-safety claim.
- Estimated freshness window — a conceptual estimate of how long an
item might remain good, given its identity and storage condition. This
is explicitly an estimate concept, not authoritative safety data — see
docs/domain/trust-safety-and-food-claims.md, which governs how any such estimate must be sourced, qualified, and displayed.
No other data concepts (e.g. user account details, payment information, location data, health or dietary data) are currently in scope for this document. If any of those become relevant in the future, they should be evaluated separately and against the appropriate classification and privacy standards before being added here.
Sensitivity classification¶
Household inventory data (what food a household has, in what quantity, where it's stored) is expected to be classified as Internal/Confidential under the company's data classification scheme, not Restricted — unless it becomes linked to payment information or health/dietary information, in which case the more sensitive classification and associated handling requirements would apply. This classification determination should be revisited once an actual data model and company classification standard are available to confirm against; treat this as a working expectation, not a final classification ruling.
What must happen before this becomes a data model¶
A real data model requires an approved product specification
(product/product-requirements.md) describing what the product actually
needs to do, followed by deliberate technical design work — including
privacy, security, and classification review. This document should not be
used as a substitute for that process.