An expiration date looks precise, but the physical world around it is not. A package date may be known, a leftover may have only a preparation time, an opened container may follow a different rule, and moving food from a shelf to a freezer changes what the next useful decision should be. I designed the Inventory System’s quality model to preserve those distinctions and still answer the practical question: what needs attention now?

The first rule is that supplied evidence outranks a heuristic. An explicit expiration timestamp is kept as the reference. When it is absent, kitchen rules can infer a working date from the item’s category or type; after an opened event, opened-specific rules are tried first. Inferred dates carry an expiry_estimated flag, which follows them into queue language. An item can also be explicitly marked non-perishable by clearing its expiration projection. That is different from “unknown”: the system records that the absence of a date was intentional.

Those rules belong to the workspace, not to a global idea of what every object means. Kitchen settings define expiration windows, quality thresholds, and confidence behavior, while another workspace can keep a simpler policy. Locations belong to workspaces too, and a move to a location from another workspace is rejected. This prevents a kitchen-specific assumption from quietly becoming universal and keeps future physical domains—tools, supplies, or lab materials—from inheriting food semantics merely because they share the same ledger.

A moving item needs more than a newly calculated date. The projection stores an expiration anchor, the original reference date, accumulated progress, the time that progress was last advanced, and the decay multiplier of the reference location. Before a move changes the location, the old environment’s elapsed progress is accounted for; the remaining lifetime can then advance at the new location’s rate. A slower storage zone can extend the projected date, and returning to a faster one can shorten it again without erasing the time already spent elsewhere. The reference date remains available, so this adaptation is explainable rather than a mysterious overwrite.

Quality is related to that timeline but not reduced to a binary expired flag. A small set of named curves represents different shapes of decline: an ordinary linear path, an earlier visible decline, a late drop, or a slower shelf-stable pattern. The curve maps expiration progress onto a score, and workspace thresholds turn the score into labels such as fresh, okay, use soon, degraded, or expired. The names are bounded by the event schema, which avoids storing arbitrary formulas in user input while leaving the projection rules free to evolve.

Human observation remains stronger evidence than a curve. A condition event can record that an item is already mushy or still in good shape. Rather than pinning that score forever, the projector translates the observation back into progress on the selected curve and continues decay from the observation time. This preserves both facts: someone directly inspected the object, and more time will still pass. Related safeguards prevent a routine “observed” action from making food younger and prevent opening an item from raising its existing quality. Tracking a bulk container by percent remaining also has a physical interpretation: dropping below full marks it as opened, while a counted group of separate units does not.

The dashboard turns this reasoning into action queues. Active items can appear under use_soon or likely_expired, with reasons such as “estimated expires tomorrow” or “expired two days ago.” A separate audit queue reflects uncertainty about whether an item is still present, and an explicit free-for-taking action has its own queue. Finished and discarded items remain in history but disappear from active attention. Queue generation projects time-sensitive state on a copy for the read, so merely opening the dashboard does not append events or mutate the persisted projection.

This is intentionally decision support, not a food-safety oracle. The model distinguishes a printed fact, a local rule, a storage adjustment, and a direct quality observation instead of presenting all four as equivalent certainty. The practical lift is that the inventory can suggest what to use, inspect, share, or discard while still explaining why an item appeared on the list—and while leaving the final judgment with the person standing in front of it.