Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/No-Country-simulation/G9-LATAM-Team-58/llms.txt

Use this file to discover all available pages before exploring further.

Every content item ingested into Mindloom is automatically projected onto a two-dimensional plane using UMAP dimensionality reduction. The web UI renders this projection as an interactive scatter plot, with each dot representing one content item and colors indicating its category. Unlike a tag cloud or list view, the map encodes semantic relationships spatially: items that discuss similar concepts appear near each other regardless of the words they share, and category clusters emerge naturally from the underlying embedding geometry rather than being manually arranged.

​
How the map is built

Coordinates are generated by the inference service at /predict time — the same single call that classifies the content and extracts keywords. After computing the 384-dimensional embedding, the service applies two additional models:
  • UMAP projection: x, y = umap_reducer.transform(vector)[0] — reduces the 384-dim vector to a 2D point that preserves neighbourhood relationships from the high-dimensional space.
  • K-means cluster assignment: cluster_id = kmeans.predict(vector)[0] — assigns the item to one of the learned topic clusters. cluster_id is stored in the database but is not yet exposed in the GET /map response.
The resulting x, y, and cluster_id values are stored in the contents table alongside the full embedding as part of the standard ingestion flow. No separate computation step is required.
Coordinates are computed once at ingestion time and stored permanently. They are not recalculated as new content is added. This means the map layout is stable — navigating back to a saved view will show the same positions — but may gradually drift from the global UMAP model as the corpus grows substantially. To refresh coordinates, content would need to be re-ingested.

​
The map endpoint

GET /map returns the complete list of map points for all content items in the corpus. There are no filter or pagination parameters — the full dataset is returned in a single response.

​
Response shape

Each item in the array corresponds to a MapPoint DTO with five fields: 
[
  {
    "id": "devto-4821",
    "title": "Intro to Spring Boot",
    "category": "Backend",
    "x": 2.14,
    "y": -0.87
  },
  {
    "id": "so-55190",
    "title": "Índices vectoriales en Oracle",
    "category": "Bases de datos",
    "x": 4.21,
    "y": -1.07
  }
]
FieldTypeDescription
idstringUnique content identifier.
titlestringTitle of the content item.
categorystringOne of the 8 taxonomy categories, in Spanish.
xnumberUMAP horizontal coordinate.
ynumberUMAP vertical coordinate.

​
Category colors in the web UI

The scatter plot assigns a distinct color to each of the 8 categories. Colors are defined as CSS custom properties (variables) in the web UI — the theme resolves them at runtime rather than hardcoding hex values. This means the palette adapts to light and dark themes automatically.
CategoryCSS Variable
Backend--cat-backend
Frontend--cat-frontend
Móvil--cat-movil
Datos e IA--cat-datos-ia
DevOps y Cloud--cat-devops-cloud
Bases de datos--cat-bases-de-datos
Seguridad--cat-seguridad
Fundamentos--cat-fundamentos

​
Use cases

Explore topic distribution

See at a glance which categories dominate your corpus and which are sparsely populated. Dense clusters indicate well-covered topics; isolated dots may warrant investigation.

Identify topic clusters

K-means clusters (visible through proximity on the map) group content that the model considers semantically close, even across different user-assigned tags or titles.

Spot coverage gaps

Empty regions of the map between expected clusters suggest topics that exist in the taxonomy but are missing from your corpus — useful for editorial planning.

Find visually related items

Items that appear close together on the map will also appear in each other’s related arrays, since both proximity and related lookups derive from the same embedding space.

​
Relationship to content ingestion

The UMAP coordinates exposed by GET /map are the same x and y values stored during POST /content. The two flows are tightly coupled:
  • A content item appears on the map as soon as ingestion succeeds — no separate indexing step.
  • If ingestion fails (for example, the JDBC embedding UPDATE is skipped), the row will have x and y values but no vector. The item will appear on the map but will not participate in semantic searches or related lookups.
  • Batch-uploaded items (POST /contents/batch) follow the same ingestion path and appear on the map immediately after the batch completes.
For the full endpoint reference and error codes, see the GET /map API reference.

Build docs developers (and LLMs) love

Get started for freeTalk to us