ParticleSearch Golden Queries: Protect Important Searches Before You Publish

Protect the searches you would notice first if they broke. A golden query is a small promise recorded against a real search. It says which shopper job matters, which product, variant, position, or destination should satisfy it, and what kind of answer would count as a regression.

This matters because search changes have a wide blast radius and human memory is a poor release system. A synonym added for one phrase can broaden a neighbouring query. A catalogue update can move an exact variant. A layout change can preserve the result but break its handoff. Golden queries keep the important before-and-after promise visible when those changes occur.

This guide explains how that protection works, how it differs from general monitoring, which queries deserve a fixture, how to write an expectation without freezing the catalogue, and how to interpret and maintain failures. You do not need to protect every query; you need a representative set whose business and shopper consequences you can explain.

Analytics tells you what shoppers did. Monitoring tells you whether the system is healthy. A golden query answers a different question: did a change preserve a search outcome the merchant had already decided was important? It turns that judgement into a repeatable release check.

The fixture should protect meaning, not a screenshot. For an exact identifier, the promise may be the intended variant, availability, and safe handoff. For a broad category, it may be category fit, required constraints, useful breadth, and no incompatible products near the top. The exact order can change when the catalogue improves as long as the buyer’s job remains protected.

This makes golden queries a regression sample rather than a universal quality score. A passing set does not prove every search works, and a failure does not automatically prove the new rule is wrong. It tells the team exactly where a known promise needs interpretation before the release can be trusted.

A useful protected set has different levels of strictness. An exact identifier can require the intended variant and a maximum position. A broad category query should protect category fit, constraints, and a usable shortlist while allowing the product order to evolve. A content or navigation query should protect the destination and label, not a product position.

Include positive and negative fixtures. Positive fixtures state what should appear. Negative fixtures state what must not appear, such as an incompatible part, an unavailable market item, or a product above a stated budget. Without negative cases, a release can pass by returning a broader set that quietly damages the buying job.

Keep the set small enough to maintain, but broad enough to represent the store’s real risk. Five carefully chosen queries are more valuable than fifty copied examples with no owner or review date. The set is a sample of important promises, not a claim that the unprotected catalogue is healthy.

Take an exact query such as AB-120-BLK. “First result is the parent product” is not a complete expectation if the buyer needs the black variant, a sellable price, and a product-page handoff that preserves the identifier. Record the identity, acceptable alternatives, disqualifiers, and the action that should remain safe.

For a discovery query such as waterproof jacket for winter, a single expected product is too brittle. Record the intent, required constraints, acceptable category or collection, and the evidence that should appear on the cards. A new product can become the best answer without being a regression if it still satisfies the promise.

This distinction makes the protected set useful to both merchants and engineers. Merchants can explain what must remain true. Engineers can investigate whether a failure came from the query, field coverage, eligibility, ranking, variant handoff, or a changed catalogue record.

ParticleSearch lets merchants record protected searches with the products and positions that matter, then use those checks around search-setting and rule publishes. The workflow is designed for the question a merchant actually has: “Did this change damage a search I care about?”

The dashboard keeps the protected set visible, allows a merchant to review or update a query, and separates active protection from a fixture that needs data or has been intentionally paused. When a publish cannot satisfy the available checks, the release evidence stays visible instead of implying that a successful save means a successful search.

Protected replays use the same recorded manifest and preserve compact fingerprints for the tested input and ordered output. If the input fingerprint changes, the team is no longer comparing the same test conditions. If the input stays the same but the output fingerprint changes, the result order or returned identity changed and deserves inspection. A fingerprint is change evidence, not a relevance or confidence score.

Published settings and search-rule versions remain available for history and restore. That gives a merchant a controlled response when the regression is real: inspect the failed query, choose whether to fix forward or restore a validated state, then re-run the protection set after runtime confirmation.

The boundary is important. Golden queries do not prove that every query is correct, and they do not repair missing product data or an unavailable item. They protect the promises you explicitly chose and make the evidence around a release easier to trust.

A protected product can be discontinued, move to another market, lose a variant, or be replaced by a better item. A category can legitimately gain new products that deserve the top positions. If the fixture still demands the old result without recording the catalogue change, it creates a false failure and teaches the team to ignore the guardrail.

Review the promise, not just the expected position. For an exact identifier, a discontinued item may need an authorised replacement or a clear unavailable state. For a discovery query, preserve category fit and constraints while allowing ranking to evolve. For a content query, update the destination when the canonical guide changes and keep the old path redirected only when that is intentional.

ParticleSearch separates an active protected query from one that needs review or has been intentionally paused. That matters because deleting a failing fixture hides history, while blindly enforcing it can freeze a stale catalogue. The merchant can inspect why the expectation changed, update the protected outcome, and use the revised record in the next publish.