Let’s talk business rules!
Author Kathleen DeRusso
Meet your Author:
Kathleen DeRusso has built and scaled search applications across homegrown software, Solr and Elasticsearch. After several years working on B2B search (and a side quest into the SaaS space), she's a Principal Software Engineer at Elastic with a passion for search relevance across whether it's for lexical, semantic, and hybrid search and context engineering. Other than being a search nerd, she's passionate about supporting other women in technology and search and happy to be part of the Women of Search community.
“We need to change our search results for xyz.”
Almost every search practitioner has had this conversation at least once. If you haven’t yet, you probably will in the future! It’s when you’re told that carefully curated NDCG and pure relevance alone isn’t enough, and that search results need to reflect broader business priorities.
Why do we need this? There could be a few reasons: Maybe a customer is complaining. Maybe a marketing campaign depends on certain results appearing. Maybe engagement or sales need help. Maybe there are legal or regulatory constraints that need to be addressed. The details vary, but the takeaway is always the same: your search needs to support business rules. Now your job is to implement these business rules in a way that supports these rules while having a minimal negative impact on overall relevance.
Over time, these requirements tend to fall into a few familiar patterns.
Promotion is one of the most common: boosting or pinning strategic, seasonal, or sponsored content so it appears more prominently than relevance alone would dictate. Sometimes there’s a need for guaranteed presence, where certain documents must appear on page one or at the very top. Often rules are conditional, applying only for certain queries, time windows, geographies, or user segments. And occasionally, there are hard overrides: “If the query is X, always return Y first.”
On the opposite end is suppression, where out-of-stock, discontinued, or restricted items need to be demoted or even removed entirely.
These are just the most common patterns - once, I was asked to randomize results so that different manufacturers had an equal opportunity to be returned at the top of a result set! This was actually a critical function, because we had to send a certain amount of traffic to each one.
So what do you do now?
Earlier in my career, I spent a lot of time ensuring that specific documents appeared on keyword-specific SEO landing pages. Each high-value keyword came with its own set of rules and expectations, and managing those overrides in application code was painful. When writing the query rules API in Elasticsearch, I often thought back to that experience. Having a centralized place where rules could be defined and managed would have saved a huge amount of time. Best of all, the UI that was later added would have allowed managers to maintain these rules and taken me, the engineer, right out of the equation! (This is probably why it remains one of my favorite features, even if it is rather simple to think about).
What are some of these rules? Well, let’s say that you need a specific document xyz to show up first in the list of search results. Elasticsearch supports this directly with the pinned retriever or query. Query rules make it easy to specify the conditional logic handling here, but you could also imagine calculating this at the application level and determining when to apply the pinned documents. Filtering is usually the least controversial form of business logic because it just removes documents that are ineligible to be returned.
In other cases, we simply don’t want content to be returned at all. If it’s a single document that needs to be excluded, this can still be done through query rules, but any more sophisticated rules (for example filtering out of stock items or filtering for content that is restricted for a given age range) require adapting the query entirely. Filtering is a great option here, where you can exclude any documents that meet (or don’t meet) a specific criteria.
But what if you don’t know the specific document, you just want to boost or demote a set of documents by some criteria, maybe brand, or even personalized to the user?
One of the most common approaches is adding query-time boosts. This can be as soft a touch as you make it - results can still be relevant, but documents that meet certain business criteria get an extra nudge. Let’s look at how you might achieve this in Elasticsearch:
First, there’s the old standard, a function_score query that boosts documents with a specific flag:
For a more out of the box solution, you could look at tuned weights in linear or RRF retrievers. Here’s an example with linear:
Query-time boosting works well when the goal is to help a result rather than guarantee its position. For example, boosting featured products or promoted content while still allowing a clearly better lexical or semantic match to win. The downside is that strong relevance signals can overpower the boost. Whether that’s a bug or a feature depends on your situation.
This approach fits naturally into a tiered relevance strategy. You might prioritize exact or phrase matches first, then promoted results, and then everything else. Business logic influences ranking, but doesn’t completely take over. Here’s what I mean when I’m talking tiered relevance strategy:
You can also update your application layer to use a hybrid approach, and rerank your results with business rules. This involves retrieving a larger candidate set purely by relevance. Then, you can apply business rules as a post-processing step. This preserves relevance signals while still allowing fine-tuned control and when handled at the application side can enforce rules that aren’t possible in Elasticsearch or other engines - for example pinning a result at position 3 while position 1 and 2 are organic results.
Every business rule comes with a cost. Overriding scoring can degrade relevance. Promoted results that feel irrelevant erode user trust. As rules pile up, explainability suffers, and debugging ranking behavior becomes harder. Maintenance is a real issue too: rules can be added quickly and almost never removed. You can mitigate this a bit by narrowly implementing your rules - they can be scoped to specific queries and time-bound with expiration dates when appropriate. Business rules shouldn’t be a replacement for relevance, just something that you can accommodate in your overall relevance strategy.
Women of Search - what business rules have you implemented, and how have they worked out for you?
I’d love to hear your stories!