> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uselayers.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rules & safeguards

> Configure block rules for conditional recommendation behavior and add safeguards that enforce minimum and maximum product counts before a block is shown.

## Block rules

Rules allow you to modify block behavior based on contextual conditions and product attributes. Rules are evaluated in order, and the first matching rule's actions are applied.

### Targeting conditions

Targeting conditions evaluate context and product attributes. Available fields include:

**Anchor product attributes:**

* Product type
* Vendor
* Tags
* Price
* Any other product attribute

**Contextual data:**

* Geographic location (country, state, city)
* Customer tags
* Device type
* Marketing source, medium, and campaign

### Rule actions

<AccordionGroup>
  <Accordion title="Apply Filter">
    Add additional filtering to the block's product results.

    **Use cases:**

    * Show only products from the same vendor as the anchor product
    * Filter by price range based on anchor product price
    * Show only products with specific tags
    * Apply geographic filtering (e.g., show winter products to cold climates)
  </Accordion>

  <Accordion title="Hide Block">
    Hide the block entirely when conditions are met. The fallback chain will be used instead.

    **Use cases:**

    * Hide "Frequently Bought Together" if anchor product is out of stock
    * Hide blocks for specific customer segments
    * Hide blocks on mobile devices
    * Hide blocks for specific geographic regions
  </Accordion>

  <Accordion title="Change Strategy">
    Switch to a different strategy when conditions are met.

    **Use cases:**

    * Use "Similar Products" for mobile users instead of "Frequently Bought Together"
    * Switch to different interaction strategies based on customer segment
    * Use different strategies for different product types
  </Accordion>

  <Accordion title="Override Safeguards">
    Modify the block's safeguards (min/max products, hide out of stock) based on conditions.

    **Use cases:**

    * Show more products for VIP customers
    * Adjust minimum products based on device type
    * Enable/disable out-of-stock filtering based on inventory levels
  </Accordion>
</AccordionGroup>

### Multiple rules

You can configure multiple rules for a single block. Rules are evaluated in order, and the first matching rule's actions are applied.

## Safeguards

Safeguards ensure blocks display appropriately and provide a good customer experience.

### Hide out of stock

Automatically filter out products that are not available for purchase.

**Behavior:**

* Products with no available variants are excluded from results
* If your store has [location-based stock checking](/help/configuration/configure-search-behavior#location-based-stock-check) configured, the same location rules apply. A product is hidden only when it has no inventory at any of the selected locations
* Applies after strategy execution but before pagination
* Can be overridden by rules

### Minimum products

If the block returns fewer than the minimum number of products, the fallback chain is used instead.

**Behavior:**

* Evaluated after filtering and safeguards are applied
* If results are below minimum, the system tries the first fallback block
* If no fallback blocks are configured, the block returns the available products
* Prevents displaying blocks with too few recommendations

**Use cases:**

* Ensure "Frequently Bought Together" always shows at least 4 products
* Maintain consistent block appearance across pages
* Automatically fall back to curated collections when behavioral data is insufficient

### Maximum products

Limits the total number of products returned by the block across all pages.

**Behavior:**

* Applied after all filtering and sorting
* Caps the total result set to the specified maximum across all pages
* `totalResults` and `totalPages` reflect the capped total, ensuring consistent pagination metadata
* Pages beyond the cap return empty results

**Use cases:**

* Limit recommendations to fit specific UI layouts
* Control page load performance
* Maintain consistent block sizes

### Affinity weight

Controls how much a shopper's personal affinity signals influence product ordering within the block. Affinity signals are derived from the shopper's cart contents and purchase history — for example, preferred brands, product types, or attributes. When affinity weight is enabled, the block blends its base recommendation scores with these per-shopper signals so that products matching the shopper's preferences appear higher in results.

The **Affinity Weight** slider is available on all blocks except those using the manual strategy.

**Configuration:**

* Set the weight between **0%** (off) and **100%** (pure affinity) using the slider in the block's **Safeguards** section
* The default value is **40%**, which provides a balanced blend of the block's recommendation strategy and personal affinity signals
* Lower values keep recommendations closer to the base strategy (behavioral data or similarity)
* Higher values give more influence to the shopper's personal preferences

**How it works:**

* When context and identity data are provided in the API request, the platform computes affinity signals from cart contents and purchase history
* The affinity weight determines how strongly these signals re-rank the block's product results
* For interaction strategies (such as "Frequently Bought Together"), the system blends co-occurrence confidence scores with per-product affinity scores
* For the similar products strategy, the weight is passed through to the ranking pipeline to influence the final ordering
* At **0%**, affinity signals have no effect and results follow the base strategy ordering
* At **100%**, affinity signals fully determine the product ordering

<Note>
  Affinity weight requires [contextual information](/engine/contextual-information) (specifically `context` and `identity` parameters) to be included in the API request. Without context data, the block falls back to its base strategy ordering regardless of this setting.
</Note>

**Use cases:**

* Increase affinity weight on "You May Also Like" blocks to surface products matching the shopper's brand preferences
* Decrease affinity weight on "Frequently Bought Together" blocks where co-purchase patterns should take priority over personal taste
* Set affinity weight to 0% on blocks where you want purely data-driven recommendations without personalization

## See also

* [Fallback Chains](/platform/blocks/fallback-chains)
* [Strategies](/platform/blocks/strategies)
* [Blocks Overview](/platform/blocks)
* [Priority & Status](/platform/blocks/priority-and-status)
