CASE STUDY / HYBRID SEARCH · APPLIED AI
Finding the right IoT capability through grounded recommendations.
The discovery problem
An IoT application catalog spans specialized domains, inconsistent terminology, and different user intentions. Pure keyword search misses meaning; unconstrained chatbot answers can invent capabilities.
HEDGE ExpertAI combines retrieval with evidence-linked explanations. It helps users describe a need, discover relevant applications, and understand why a recommendation was made.
Live discovery experience
The live HEDGE ExpertAI prototype puts application discovery into a conversation workspace. Users can explore the catalog, ask about an application's capabilities, follow its Store source, and select applications for comparison. A responsive layout switches between conversation and application tabs on smaller screens; an embedded-pane mode presents the assistant in a narrower host surface.
The interface currently identifies itself as a standalone English discovery prototype and private preview. During the October 2026 capture, it displayed EdgeConnect from INESCTEC and Semantic Treehouse from TNO as authorized Store applications. Asking for an EdgeConnect explanation returned a capability summary, quoted source information, a Store-source link, and follow-up prompts.
These are observations of the live experience, not a claim that release acceptance, catalog completeness, or production readiness has been independently verified. The repository's v2 README still describes a synthetic catalog and a disconnected real Store API. The live interface has moved beyond that description; its Store connection is visible in the product, while its private ingestion path and deployment configuration were not audited.
My work covers the service architecture, ranking and recommendation workflow, metadata ingestion, web validation tools, embeddable widget, and a companion mobile client consuming the gateway contract.
Product in use
These are actual browser captures of the owner-provided live deployment, taken on 23 October 2026. They show the product as served, including its prototype labeling; no interface or answer was composited.
Architecture and data ownership
The documented v2 architecture makes data ownership explicit: PostgreSQL is authoritative, while Qdrant is a rebuildable search index. Catalog revisions and an outbox make indexing retryable rather than treating a vector database as the only record of the catalog.
- Gateway and intent: route requests and interpret the user’s need.
- Discovery ranking: combine semantic similarity, keyword relevance, and SAREF ontology signals.
- Recommendation: use Ollama/Qwen explanations grounded in the retrieved catalog records.
- Metadata ingestion: process catalog updates through Celery and a persistent Valkey queue.
- Operational state: separate bounded cache/session state from durable queue state.
- Interfaces: a React validation console, an embeddable widget, and a separate Flutter companion client.
Retrieval and explanation
The documented retrieval stack uses multilingual-e5-small embeddings with explicit query/passage prefixes, Qdrant for vector retrieval, and keyword and SAREF signals for domain relevance.
The model explains the retrieved results; it does not become the source of truth for application capabilities. That distinction keeps recommendation quality tied to catalog evidence and makes ranking and explanation separately testable.
Engineering decisions
- Rebuildable indexes: PostgreSQL revisions and the outbox provide a durable path from catalog changes to searchable data.
- Bounded operational state: separate Valkey cache and queue instances give transient state and asynchronous work distinct lifecycles.
- Integration boundary first: keep the Store adapter versioned and distinguish synthetic evaluation data from the Store-backed experience shown by the live prototype. The deployed ingestion implementation needs separate verification.
- Separate quality gates: held-out retrieval relevance, first useful recommendation latency, and revision-to-searchable freshness require their own evidence.
- Gateway-first clients: web, widget, and mobile consumers share a contract instead of duplicating ranking logic.
Evaluation and delivery
The repository documentation defines targets for HitRate@2, first useful recommendation latency, and catalog freshness. It explicitly keeps these pending until acceptance evidence is retained and reviewed. Historical portfolio numbers are therefore not presented as current v2 results.
This project demonstrates the engineering around applied AI: data ownership, replay-safe ingestion, evidence-grounded output, evaluation boundaries, and an integration path into an existing product.
NEXT PROJECT