by LiteratureMap (LX AI)
Open LiteratureMap, provide the required inputs, run Demo to preview the workflow, then switch off Demo when a live key is configured.
See how the research actually connects
Decision-support only — confirm before you publish or act.
I start by gathering the identifiers for the works I want to explore. These can be DOI strings, PubMed IDs, arXiv codes, or plain titles. I paste them into the input box, one per line, or upload a CSV file that contains a column labeled “id”. The product expects at least three items to generate a meaningful graph; fewer items still produce a view but the clustering step will be limited.
Next I choose the scope of the citation pull. The default pulls references from Crossref and OpenAlex for the last ten years. If I need a deeper historical view I toggle the “extend range” switch and set the start year manually. I also decide whether to include self‑citations; leaving this off often makes the map easier to read when I am looking at influence between distinct groups.
After the inputs are set I click the “Fetch metadata” button. The backend queries the selected sources, normalises author names, and builds a temporary cache inside the product’s .data/ folder. This step takes a few seconds for a set of fifty papers and up to a minute for a few hundred. I watch the progress bar; if it stalls I verify that my network allows outbound HTTPS to api.crossref.org and api.openalex.org.
Demo mode uses a publicly available test key that calls a small language model hosted on the product’s demo server. I press the “Run Demo” button to see a quick rendering of the citation graph. The demo limits the AI‑enhanced theme extraction to the first twenty nodes, but it still shows the raw citation links and the initial clustering based on keyword overlap.
While the demo runs I can pan the canvas with the mouse, zoom with the wheel, and hover over any node to see a tooltip with title, year, and a short abstract snippet. If I notice that a paper I expected is missing I return to the input step, add the identifier, and rerun the demo. This iterative loop helps me catch typos in DOI strings before I commit a live key.
When the preview looks satisfactory I note the number of nodes and edges displayed. I also check the “gap indicator” badge in the lower‑left corner; a high percentage suggests many papers in the set have few incoming or outgoing links, which may point to emerging sub‑topics.
To move from demo to a production run I obtain a personal key from the model provider I prefer (for example, an OpenAI API key or a self‑hosted LLM endpoint). I open the settings panel, paste the key into the field labeled “Live LLM key”, and press “Save”. The product immediately validates the key by making a minimal token request; if the request fails I see an inline error message with the HTTP status code.
After the key is stored I toggle the “Demo” switch off. The UI grays out the demo button and enables the “Run Live” button. I then repeat the fetch‑metadata step if I changed any inputs since the demo run, or I can proceed directly to “Run Live” if the metadata cache is still fresh.
The live run consumes tokens from my provider account. I monitor the usage counter that appears in the status bar; each request to the language model is logged locally so I can review cost later. If I need to stop a long‑running job I can click the “Cancel” button; the product will halt further API calls and preserve the partial results that have already been saved.
The main canvas shows each paper as a circle. The size of the circle reflects the total number of citations the paper has within the selected set (larger = more internal citations). Arrows point from a citing paper to a cited paper; the arrow thickness grows with the number of citing sentences detected by the AI model.
I look for nodes with many incoming thick arrows. These are the papers that other works in my set build upon directly. I click such a node to open a side panel that lists the citing papers and shows the exact text snippets where the citation occurs.
Nodes with few or no connections often represent either very recent pre‑prints or works that belong to a niche sub‑field. I double‑check their metadata; if the year is recent I may decide to wait for more citations before drawing firm conclusions.
Because the output is decision‑support only, I treat the graph as a hypothesis generator. Before I claim that paper A influences paper B I verify the citation context manually. I also cross‑check any surprising links against the OWASP LLM Top 10 to ensure I am not mistaking a superficial similarity for a substantive scholarly connection.
The product runs a clustering algorithm on the combined TF‑IDF vectors of titles and abstracts, then refines the groups with the language model’s thematic labeling. Each cluster receives a short descriptive tag (for example, “transformer‑based vision” or “federated learning security”).
| Cluster ID | Label | Node count | Average year | Key papers (DOI) |
|---|---|---|---|---|
| C1 | Large‑language‑model safety | 12 | 2022 | 10.18653/v1/2022.acl-long.456, 10.48550/arXiv.2103.00020 |
| C2 | Multimodal retrieval | 9 | 2023 | 10.1109/CVPR.2023.00123, 10.1609/aaai.v37i11.26544 |
| C3 | Parameter‑efficient fine‑tuning | 7 | 2024 | 10.18653/v1/2024.findings-emnlp.210, 10.48550/arXiv.2305.12345 |
| Table: Example cluster output from a sample run of fifty recent AI papers. | ||||
I use the table to quickly gauge which themes dominate my set. If a cluster has a low average year but a high node count I may be looking at a rapidly growing area. Conversely, a cluster with few nodes and a high average year could signal a fading topic that still holds foundational value.
The gap detector works by scanning the citation graph for missing links that would close triangles in a co‑citation network. For each pair of papers that share a common citer but do not cite each other, the model estimates the likelihood that a direct citation should exist based on textual similarity.
After the live run finishes I click the “Gap analysis” tab. The product lists candidate gaps sorted by a score that combines textual similarity (cosine of abstract embeddings) and network centrality of the missing edge. Each entry shows:
I treat every gap suggestion as a lead, not a conclusion. I open the PDFs of Paper A and Paper B, read the introductions, and see whether the authors indeed discuss related work. If the texts are topically distant the high score may stem from superficial keyword overlap; I discard those cases. When the texts show a clear conceptual bridge I note the gap as a potential literature‑review addition or as a cue to run a new experiment that ties the two lines of work together.
When I am evaluating gaps that involve safety or security implications I consult the NIST AI Risk Management Framework to see whether the missing connection could affect threat modeling or mitigation planning. This helps me keep the literature‑review step aligned with broader governance practices.
Once I am satisfied with the graph, clusters, and gap list I generate an exportable outline. The outline follows a simple markdown hierarchy:
I click the “Export outline” button, choose either markdown or plain text, and save the file to my local workspace. The export includes:
I then import the outline into my note‑taking tool or use it as the starting point for a manuscript’s related‑work section. Because the product is decision‑support only, I always review the exported bullets against the source PDFs before finalizing any text.
I want to be clear about the limits of LiteratureMap so you do not rely on it for things it cannot do.
Because the output is decision‑support only, treat every suggestion as a starting point for your own judgment.
See how the research actually connects
Operators and builders who need a fast first draft or checklist from LiteratureMap.
Yes in explicit Demo mode. Live AI requires a configured key.
No. Outputs are decision-support; you still review before publishing or acting.
Only if those features are implemented in this product build — do not assume them from marketing copy.
Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.