Start with the customer
A shopper describes a need instead of choosing a category. The assistant reads a synthetic purchase history, searches a synthetic catalogue, checks stock and current price, and returns recommendations with the customer signals and catalogue facts that support them.
Example: Nadia is planning multi-day hut-to-hut trips, carries everything herself, starts before sunrise, and already owns photography and hiking equipment. The checked-in receipt connects those facts to one packable neutral-density filter for long-exposure landscape photography, without recommending a product she already owns.
Open the complete checked-in customer recommendation →
Four questions a real shopping assistant should handle differently
- Nadia · connect several interests: combine hiking, dawn starts, carried weight, off-grid power, and photography into a coherent trip—not five unrelated keywords.
- Sofia · find the actual gap: distinguish a consumable she may replenish from durable equipment she already owns.
- Marco · ignore misleading history: do not treat gift purchases sent to somebody else as evidence of his personal interests.
- Luca · know when not to recommend: ask a useful clarifying question when one weak purchase signal cannot support confident personalization.
The business question
The interesting question is not “can a language model produce a plausible answer?” It is:
Can a team tell when the assistant is useful, when it is unsafe or unsupported, whether a controlled workflow behaves better than a flexible agent, and whether a later model or prompt change genuinely improved the customer experience?
VITRINE turns that question into a development loop. The recommender is only the example subject; the reusable contribution is the layer underneath it: observed model and tool calls, correlated execution records, explicit cost and missing-data states, versioned scenarios, repeatable comparisons, planted-defect tests, and durable evidence when a local report or evaluation receipt is requested.
What the evidence adds
- Fast checks first. Catalogue, tool, workflow, and recommendation invariants run locally without credentials or provider cost.
- Model calls only for questions that need them. Opt-in evaluations judge the four use cases, compare agent and workflow behavior, repeat runs to expose variability, and run a small safety-probe campaign.
- Failure stays visible. A missing observation is not silently turned into a passing score. Provider errors, incomplete safety scans, and inconclusive comparisons remain distinct outcomes.
- Proof survives execution. Results, costs when reported, comparisons, and safe failure explanations are written locally and can be exported or replayed without running the model again.
- The evaluator is tested too. VITRINE deliberately plants defects and requires the corresponding diagnostic to detect them and recover afterwards.
What this does not prove
The customers, purchases, catalogue records, prices, stock, reviews, and relationships are authored/synthetic; recognizable third-party product and brand names are used illustratively. VITRINE does not measure a Digitec Galaxus system, production customers, conversion, revenue, satisfaction, or regulatory compliance. A small safety campaign is not penetration testing. A few repeated cases are not a production reliability claim. The sample demonstrates an engineering method and makes its evidence inspectable; real deployment would require governed company data, human calibration, operational telemetry, access control, and product-owned success metrics.
A 60-second tour
- See the output: open the customer recommendation.
- See how it was produced: compare the agent and workflow in the architecture preview.
- See what is checked: read the plain-language evidence ladder in the value proposal.
- See the proof: inspect the checked-in offline report or the verification receipt.