Entity condition

An entity condition is a named, reusable check that an item can carry — for example alcohol_se, which checks that a shopper is old enough to buy an item at checkout. Rather than building that check into your own item logic, you attach the condition's id to the item, and ECS runs the check automatically whenever that item is scanned.

Every condition has:

• an id — the catalog key items reference, e.g. alcohol_se
• a rule — which check actually runs; see Rules and supported checks
• a condition value — whatever input that check needs (for example, a minimum age)
• an enabled flag — see below
• a scope — GLOBAL or TENANT, see below

Global vs. tenant-scoped

• Global conditions are owned by the platform (for example, a legally required age restriction) and apply to every tenant. They're read-only — you can't edit or delete one.
• Tenant-scoped conditions are ones you define yourself, for your own catalog. They only apply to your tenant, and their id can't collide with a global condition's id — if it does, the global one wins.

Every condition you list or fetch through the API tells you its scope, so you always know whether you're looking at a platform rule or one of your own.

Items reference a condition by id only — that reference lives in your own item/catalog data, not in ECS. Attach alcohol_se to an item once, and the check runs automatically at every checkout from then on — see Decisions and outcomes for what checkout actually sees back, and the API reference for how to create your own conditions and preview one before relying on it.

Things worth knowing

• A disabled condition (enabled: false) is left out of evaluation entirely — items that reference it simply aren't checked against it. It isn't denied and it isn't an error.
• An item referencing a condition id that doesn't exist — removed, disabled, or just a typo — behaves the same way: silently skipped, not a denial.