Claudio Eden’s JevMDB is an inspectable movie recommender, not a one-request demo. It gathers film records from IMDb, Wikidata, Wikipedia, and optional TMDB or OMDb sources, then asks Jev to compare a reference movie with each candidate across selected criteria.

I inspected the README, server, Jev client, recommender, and mock implementation. I syntax-checked the JavaScript and started the application successfully in local mock mode. I did not make paid Jev calls, evaluate recommendation quality, or perform a security audit.

The decision pipeline

  1. The user selects a reference film or describes one in text.
  2. The application builds a structured film card with title, year, director, principal cast, genres, style tags, synopsis, and themes.
  3. For a large catalog, deterministic code first narrows the set to at most 60 candidates using overlapping metadata.
  4. Each remaining candidate gets one Jev request containing a five-level Score question for every selected criterion.
  5. The application maps each 0–4 score to 0–100, averages selected criteria equally, sorts candidates, and returns up to ten results.

The four criteria are style, cast/director, release year, and plot. Each has explicit levels rather than an unlabeled numeric scale.

Where Jev is actually used

  • Catalog enrichment: Jev generates style tags for newly imported films.
  • Free-text parsing: Noul questions decide which criteria the user requested.
  • Catalog choice: when Gemini is unavailable, a Choice question maps a description to one film already in the catalog.
  • Ranking: Score questions compare every reference-candidate pair.

That is real integration code: lib/jev.js sends the typed request, records input and output usage, limits concurrent work, and returns the answer map. It is not merely a repository whose README mentions Jev.

Useful operational choices

  • The server keeps the TypeSafe key out of the browser.
  • Parallelism, candidate count, result count, model, endpoint, and displayed pricing are configurable.
  • A no-key mock mode exercises the full interface with a clearly labeled word-overlap heuristic.
  • Every displayed search can be retained for 60 days with an optional 1–10 rating and comment.
  • Low-rated searches expire after 15 days, creating a lightweight feedback queue.
  • The interface exposes calls, tokens, elapsed time, and estimated cost, unless the operator disables that display.
  • Film metadata and search records live behind small file-store modules that can be replaced later.

The feedback plumbing is potentially more important than the first ranking: it gives the project a route toward evaluating outcomes instead of treating model confidence as correctness.

The scoring design has sharp edges

  • Release-year distance is deterministic arithmetic, but the final ranking asks Jev to infer it from text. Code could calculate that criterion exactly and more cheaply.
  • The cast/director levels are also explicit counting rules that ordinary code can implement without a model.
  • Scores are converted linearly from 0–4 to percentages even though ordinal categories are not necessarily evenly spaced.
  • The final average gives every selected criterion equal weight without user-specific or empirically fitted weights.
  • Missing answers silently become zero, which can turn a service or schema problem into a very poor recommendation.
  • The ranking ignores returned confidence and probability distributions.
  • The default model is jev-latest, so rankings can drift across model updates.

A better split would keep year and exact credit overlap in code, reserve Jev for style and plot similarity, and treat low-confidence or malformed results as unavailable rather than as zero-quality evidence.

No recommendation benchmark yet

JevMDB records user feedback, but the repository publishes no labeled test set, offline ranking metric, human pairwise study, or comparison with a simple metadata baseline. The mock proves application flow only; its word-overlap scores do not predict Jev quality.

This means the project establishes that the pipeline runs, not that its recommendations are good. A useful evaluation would compare:

  • deterministic genre, cast, director, and year overlap;
  • embedding similarity over synopsis and themes;
  • Jev style and plot scores;
  • a hybrid ranking;
  • human judgments such as pairwise preference or nDCG over a fixed candidate set.

Takeaway

JevMDB is valuable because the whole system is visible: retrieval, prefiltering, typed questions, concurrency, usage accounting, feedback retention, and a testable local mode. It also makes the boundary problem obvious. Some “judgments” are arithmetic in disguise and should stay in code; the model belongs where semantic comparison actually adds value.

Typed Score output guarantees a valid ranking ingredient, not a correct recommendation. Until the stored ratings become an evaluation dataset, JevMDB should be read as a thoughtful implementation prototype with unusually good observability—not evidence that Jev beats simpler recommenders.