Omar YassinProjects & notes
← Development journal

Mediur / Foundations / Recommendations

Why I’m building Mediur

· Omar Yassin · 3 min read

The idea, the first implementation, and the questions that still need evidence.

The question behind the project

A story can stay with you because of its atmosphere, its pace, or the feeling it leaves behind. A genre label only captures part of that experience.

Mediur begins with a question: could that experience become the basis of a recommendation across different media? A player looking for the emotional qualities of Life is Strange, for example, might want to explore a book or a film. That is an intended use case, not a match the system has already demonstrated.

The project is also a way to learn practical machine learning alongside backend engineering: turning an idea into a representation, storing it, retrieving candidates, and eventually measuring whether those candidates are useful.

What exists today

The current backend separates the process into explicit steps:

  1. Create a media item with a title, type, and description.
  2. Generate a text profile describing emotional tone, pacing, themes, aesthetic, and aftertaste.
  3. Embed the profile with all-MiniLM-L6-v2.
  4. Store the vector and retrieve other items ordered by cosine distance.

FastAPI exposes the routes. SQLAlchemy manages the relational models, and PostgreSQL with pgvector stores the embeddings alongside the media data. The similarity route excludes the source item from its results.

There is also a TMDB movie-search endpoint. It returns catalogue metadata, including a title, description, release date, and TMDB identifier. Searching does not yet save a movie or generate its profile.

Start with an inspectable representation

The vibe-profile generator is currently a keyword-based scaffold. Words associated with loss can change the emotional tone; words associated with quiet or reflective descriptions can change the pacing. A few fields have defaults when no rule matches.

This makes the initial pipeline easier to inspect. A profile is readable text, so it is possible to look at what is being embedded before reasoning about vector distances.

The limitation is substantial: keyword rules cannot reliably interpret context, and different descriptions can collapse into similar default profiles. A working embedding pipeline does not by itself establish that the representation captures a story’s emotional qualities.

The first architecture trade-off

The implementation keeps vectors and media records in PostgreSQL. For a small prototype, that puts retrieval and metadata in one data system.

A dedicated vector service or a separate similarity index could be alternatives later. They would introduce a different operational boundary and different metadata-handling requirements. There is no benchmark in this journal establishing a winner, and this entry does not claim those alternatives were experimentally compared.

For now, the useful question is whether this pipeline makes the next experiment straightforward enough to run and understand.

What still needs evidence

Cosine distance orders the stored representations. It does not directly measure whether a person will find a recommendation emotionally convincing.

An evaluation should distinguish at least two questions: whether the profiles represent the intended qualities, and whether retrieving similar profiles produces useful suggestions. Otherwise, a disappointing result could be blamed on the ranking when the information was already lost during profile generation.

The repository also includes tests for movie-search validation and upstream failures. Those are useful checks on API behavior, but they are not recommendation-quality measurements.

The next step

The immediate direction is to move from catalogue search toward a deliberate import workflow, then build a small set of examples that can support evaluation. Better profile extraction and learned ranking remain future possibilities.

This journal will record decisions as they happen: what problem prompted a change, what was tried, what failed, and what the result actually supports. The aim is to keep a useful engineering record while the project is still changing.

This opening entry was prepared from the project brief and a repository snapshot on 9 September 2026.

Back to Mediur →