Identifiers drift
A product cannot be joined, deduplicated, or traced reliably when its identifiers conflict.
Case studies
Ecommerce search / Product systems
Search quality starts before search.
SearchSignal is an inspectable catalog-readiness framework for finding the product-data issues that shape ecommerce search before a customer enters a query.
Deployed synthetic demonstrator
KeywordSemanticHybrid
01
Walnut writing desk
eligibleIn stock · $1,299.00 · Walnut
ReadinessPassNormalization4 rules
01 / Premise
Search interfaces inherit the quality of the information beneath them.
Ranking, filters, synonyms, and semantic retrieval all depend on a catalog that can be understood consistently. When a record carries conflicting identifiers, unclear availability, malformed prices, or thin descriptions, the issue travels downstream. It appears later as irrelevant results, broken filters, products that disappear from search, and debugging with no clear starting point.
Source record
sku WDN-04?
price $1,299
availability maybe
material walnut / wood
Canonical record
externalId WDN-04
price 129900 USD
availability in_stock
material walnut
Eligible for search02 / Problem
Ecommerce search often fails upstream.
Catalog data evolves under commercial pressure and usually arrives from more than one source. A migration or new retrieval model can expose inconsistencies that were already present. SearchSignal makes those conditions inspectable before they become a customer-facing problem.
Product facts blur
Price, availability, and attributes lose meaning when their format or source is ambiguous.
Retrieval amplifies gaps
Semantic methods can make sparse or poorly structured source information more influential, not more complete.
03 / Strategic insight
Search eligibility is a product decision.
SearchSignal changes the order of operations. It assesses whether a product has enough valid, interpretable information to support a search experience before that record enters an index. A source record can exist in a catalog and still be a poor candidate for retrieval.
Should this product be searchable at all?
04 / System
A visible path from source record to search result.
Each stage emits evidence that connects source quality, indexing decisions, and retrieval outcomes. The framework does not treat search as an isolated interface concern.
- 01Source catalog
Fictional product records retain their source structure and constraints.
- 02Map
Fields move into a canonical product contract.
- 03Validate
Required evidence and structural correctness are checked.
- 04Normalize
Named rules standardize interpretable values.
- 05Assess
Readiness is evaluated against the information available.
- 06Eligibility
Admission or rejection remains tied to visible evidence.
- 07Retrieve
Eligible products can be explored through three deterministic modes.
- 08Evaluate
Golden queries make retrieval behavior comparable over time.
05 / Product experience
Three surfaces, one argument.
The public experience turns a technical workflow into a readable product story without claiming that the demonstrator is production infrastructure.
Landing
Explains the framework and the synthetic demonstration boundary.
Search demo
Explores fictional products with keyword, deterministic semantic, and hybrid retrieval.
Readiness console
Shows catalog scenarios, validation findings, normalization, readiness, eligibility, and indexing admission.
06 / Designing for explainability
A decision is more useful when its evidence is visible.
SearchSignal avoids hidden corrections and opaque automation. A change, block, or admission should be understandable to the person responsible for the catalog.
- Named normalization rules show how a value changed.
- Eligibility decisions retain the evidence behind the status.
- Deterministic behavior makes the same input reproducible.
- Provider and configuration failures stay controlled and legible.
07 / Product decisions
The constraints are part of the product.
Deterministic by default
Critical catalog and eligibility behavior is reproducible. The tradeoff is a narrower system, with a clearer trail to inspect and test.
Normalize explicitly
The framework standardizes values only through named rules. It does not silently invent product facts.
Separate demo from production
Synthetic fixtures and deterministic providers never masquerade as live merchant infrastructure.
Fail closed
Missing production-provider configuration returns a controlled failure. It does not fall back to demo behavior.
Make evidence visible
Readiness and retrieval decisions can be examined instead of trusted blindly.
Keep boundaries honest
Future connectors, providers, persistence, and operations are documented as future work.
08 / Architecture
Clear responsibilities make the system easier to reason about.
SearchSignal is a TypeScript pnpm monorepo. Next.js and React provide the public surface. Zod defines shared structures. Vitest exercises behaviour. Vercel is the deployment target. The architecture separates product concerns so one part can change without obscuring another.
Source mapping
Translates source records into a canonical structure.
Validation and normalization
Checks required evidence and applies explicit data rules.
Readiness and eligibility
Assesses whether a record can support search.
Retrieval and evaluation
Runs deterministic modes and compares them with golden queries.
Public interface
Explains the workflow through the landing page, demo, and console.
09 / Building trust through constraints
The demonstrator is specific about what exists.
Implemented
- Synthetic ecommerce catalog
- Deterministic keyword, semantic, and hybrid retrieval
- Catalog validation and normalization
- Readiness assessment and eligibility
- Golden-query evaluation
- Public UI and automated verification
Future
- Live Typesense integration
- Live embedding provider
- Shopify connector
- Durable merchant persistence
- Search analytics and background synchronization
- Multi-tenant SaaS infrastructure
10 / Quality and verification
Evidence extends to the build.
The recorded clean Node 22 verification run passed frozen installation, linting, type checking, all tests, production build, and the Vercel-readiness validator. It also covers route smoke, responsive and keyboard checks, plus controlled failure behavior. The remaining 200% zoom capture evidence is documented as open rather than represented as complete.
11 / Outcome
A way to reason about search before ranking.
SearchSignal is a working product demonstrator for a question that is often left implicit: is this catalog information ready to support search?
- An inspectable catalog-readiness workflow
- A system for explaining search eligibility
- A controlled environment for comparing retrieval approaches
- A technical proof of concept with documented production boundaries
12 / What comes next
Logical validation steps, not a generic roadmap.
SearchSignal
Better search begins with better information.
SearchSignal treats search quality as a systems problem before it becomes a ranking problem.
