Authors

The Authors page is where you manage the people you track. Adding an author here creates a monitor — from then on, their new publications flow into your Feed automatically, and their identifiers (OpenAlex, Semantic Scholar, ORCID, optionally Google Scholar) are resolved and reconciled in the background.

Most days, you'll spend time in the Feed; you'll come to the Authors page to follow / unfollow people, fix identifier mismatches, and review author suggestions (the people you don't follow yet that ALMa thinks you should).

The author map

The page opens on a map of everyone in scope, placed by what they write about — so people working on similar things sit together and the map shows the research communities behind your corpus. Clicking a dot opens a compact card with their profile and follow controls.

Membership reads on the same three channels as the paper maps, one shared space:

	means
Filled dot	Yours — you follow them, or they co-authored a paper you saved. A dashed ring marks the followed ones specifically.
Gold outline	Currently suggested to you — the exact same snapshot and evidence as the rail below, independent of fill or cluster colour.
Hollow / faint dot	Other eligible corpus authors: context, not a claim.

Scope switches between the authors of papers you saved and every tracked paper. Colour shows communities (clusters) or the engine's score; the Terrain overlay washes the space by how you actually feel about each author's papers — saves, ratings and removals first, engine score as weaker evidence, from the same central per-paper valence primitive as the paper map.

The author aggregate is evidence-weighted and shrunk toward a neutral two-paper prior. An engine-only paper has one quarter of an explicit user signal's evidence, so one plausible recommendation does not imply that you like the author. Authors with no evidence do not contribute a splat. The colourbar always spans the canonical [-1,+1] domain instead of restretching the current population, making Authors comparable with the paper maps and keeping weak positive evidence near neutral.

There are no link lines: on an author map adjacency already is semantic similarity, and drawing a dense collaboration graph would bury the dots. Each author sits at the centroid of their papers on the shared paper substrate; communities are clustered over those centroids.

An author needs at least two papers already placed on the corpus substrate. Thinner profiles are left off and counted in the legend rather than parked somewhere arbitrary — see seeding a suggestion's evidence.

Clicking a dot opens quick profile/follow actions first; publication, community, score, and suggestion evidence are progressively disclosed. The two-column drilldown below the map expands the selected author and community. Select region summarizes a lassoed community from its visible nodes and can follow every eligible, not-yet-followed member. See Semantic maps for the shared interaction and rebuild lifecycle.

Adding an author

You can add by:

• Name (partial match against OpenAlex)
• OpenAlex author ID (e.g. A1234567890)
• ORCID (e.g. 0000-0002-1825-0097)
• Semantic Scholar author ID
• Google Scholar ID (if scholarly is installed)

The AddAuthor dialog shows candidate matches with disambiguation context — affiliation, paper count, recent works — so you can pick the right person before committing.

Identity resolver

After you add an author, ALMa runs a hierarchical identity resolution pass:

1. Direct ID hits (OpenAlex / ORCID / S2) take precedence — exact match wins.
2. Name + sample-titles match against OpenAlex with affiliation / year-range disambiguation.
3. Reverse mapping from S2 → OpenAlex via DOI overlap on a sample of works.
4. (Optional) scholarly Google Scholar lookup as a tiebreaker.

Each source contributes evidence; the final resolution is stored on the authors row with a id_resolution_status (confirmed, probable, ambiguous, failed) and an id_resolution_reason explaining the decision.

The AuthorIdentifierResolution panel inside the Authors page exposes this state per-author and lets you re-run resolution or pick a different candidate manually.

Duplicate profiles and merge

Author identity is canonicalized around one authors row. When the same person appears twice (for example a spelling mistake, institution move, or split OpenAlex profile), the Author detail card exposes Merge with author. The merge flow searches existing corpus authors, compares profile metadata, and requires one mutually-exclusive choice per differing field before it writes.

Merge is also the resolution path for needs-attention duplicate profile warnings. Those warnings open the same merge dialog with the suspected alternate profile preselected, so manual merges and needs-attention fixes share the same primitive and backend endpoint. On confirm, publications are reassigned to the primary OpenAlex ID, the alternate OpenAlex ID is recorded in author_alt_identifiers, the alt row is soft-removed, and the primary author centroid is invalidated. If hard identifiers still conflict, author_merge_conflicts keeps a follow-up row for needs-attention.

Needs attention — a focused card per flag

Every author the resolver couldn't finish surfaces in the Authors page Needs attention section, and each reason opens a focused card that makes that specific problem easy to fix — auto when possible, manual when not, composing the same backend primitives the rest of the app uses:

Flag	Card	How it resolves
No OpenAlex match / followed without an id	Resolve identity	Retry the auto-resolver, paste an authoritative ORCID / OpenAlex / Scholar id, or — if the person genuinely isn't in any index — accept that they can't be identified.
Candidates too close to decide	Review candidates	Opens the author detail panel's candidate picker to choose the right match.
Split profiles (same person, many ids)	Review profiles	The merge dialog, alternate preselected.
Merge kept a conflicting identifier	Resolve conflict	Pick which value sticks, or dismiss.
Affiliation evidence disagrees across sources	Choose affiliation	Pick which institution to display (the author moved labs).

Two of these are terminal acknowledgments — they end a flag that would otherwise re-appear forever, because it is recomputed from raw data on every assessment:

• Choose affiliation records the pick as an authoritative manual evidence row. It outranks every auto source, survives future refreshes (a refresh only replaces its own source's rows), and suppresses the conflict for good — even though OpenAlex / ORCID / Crossref still disagree underneath.
• Accept as unidentifiable sets id_resolution_status='dismissed', which is excluded from both needs-attention and the author-health counts. No identifier is invented; the user can still resolve it later by pasting one.

The Health page's author dimensions read the same predicates, so a resolved or acknowledged flag clears there too (the author-health snapshot's freshness fingerprint includes affiliation evidence, so the ribbon updates immediately).

Followed vs. tracked

Two states matter on the Authors page:

State	Meaning
Followed	You've added them to your watchlist. ALMa creates an author monitor that pulls their new works into the Feed.
Tracked (background)	An author appearing on a paper in your Library / corpus. Useful for co-author analytics; no monitor.

Following is the explicit, intentional act. Tracked rows accumulate naturally as you save papers; you don't manage them by hand.

Author suggestions

Below the Followed list, the Authors page surfaces Author suggestions — people you don't follow yet that ALMa thinks you should. The rail is built fresh on every visit by running six "buckets" in parallel and merging the results into a single ranked list. Each suggestion carries a suggestion_type chip showing the bucket it primarily came from, plus a Suggested by N sources indicator if multiple buckets independently agreed on the same person.

The six buckets

suggestion_type	What it surfaces
library_core	Authors who appear on papers in your saved Library. The closest-to-home signal.
cited_by_high_signal	Authors whose work is cited by your highly-rated (≥ 4★) Library papers. Strong endorsement-via-citation signal.
adjacent	Authors whose papers your Library cites, or who share many topics + venues with your Library. Citation-graph and content-graph neighbours.
semantic_similar	Authors whose paper-embedding centroid is closest to your Library's centroid (SPECTER2 cosine). Catches "vibe" matches that don't share topics or co-authors.
openalex_related	OpenAlex's own related-authors graph, seeded from people you follow. Pure discovery — these are usually authors you've never co-authored with or cited.
s2_related	Semantic Scholar's related-authors graph, same pattern. Independent second opinion to OpenAlex.

The first four buckets read your local data; the last two read from a cache (author_suggestion_cache) that's refreshed asynchronously by Refresh network (Authors → ⋯ → Refresh network buckets) so the rail never makes blocking external API calls.

Seeding a suggestion's evidence

A suggested author is, almost by definition, someone whose work you don't have yet — typically 0–1 papers locally. That thinness used to show everywhere at once: no dot on the author map (placement needs two papers), "No sample title" on the card, and no score. The sample titles are read from your corpus, so a blank card meant a missing paper, not missing metadata.

Refresh network now also seeds them: for each suggestion under two local papers, ALMa fetches their most-cited first-author works — topped up by citations in any position if they don't have two, so a senior author who always publishes last still lands something — and saves them as tracked corpus papers (never to your Library). One bounded fetch per author restores the dot, the titles, and the score together.

Authors OpenAlex holds fewer than two works for can't be placed at all. That verdict is recorded once and reported as exhausted on the Health page rather than re-attempted forever.

How a candidate's score is built

Every candidate gets a 0–100 score that drives the rail order. Five things go into it.

1. Per-bucket evidence. Each bucket computes its own raw score:

• library_core weights every co-authorship by rating × position ÷ √N where N is the paper's author count. So a first-author of a 5★ 3-person paper carries far more weight than a middle-author of a 30-person consortium paper. This means rating your Library papers feeds the model: a 5★ rating amplifies the candidate by 3× compared with an unrated paper, a 1★ rating shrinks them to 0.2×.
• cited_by_high_signal uses the same shape: each citing-paper's rating × the candidate's position on the cited paper, divided by √N of the cited paper's author count.
• adjacent rewards citation-graph proximity + topic / venue overlap.
• semantic_similar is a direct cosine: 0.9 cosine ≈ 90 score.
• The two network buckets read pre-computed composite scores from the cache.

2. Topic / venue prevalence weighting. When a candidate shares topics or venues with your Library, the contribution isn't a flat count — it's weighted by how dominant that topic is in your Library. A candidate sharing your #1 library topic contributes ~5× more than one sharing your #30 topic. The weight is log(1 + count) / log(1 + max_count), so the head dominates smoothly without zeroing the long tail.

3. Multi-source consensus bonus. If a candidate is independently surfaced by N > 1 buckets, the score gets a diminishing-returns bonus:

Buckets agreeing	Bonus
1 (single bucket)	0
2 buckets	+12
3 buckets	+17
4 buckets	+21
5 buckets	+24

This expresses "many independent systems think this person is relevant" — strong confidence signal that a single bucket can't fake. The buckets that confirmed appear in the suggestion's consensus_buckets field.

4. Paper-feedback projection. Your paper actions also move author suggestions. A liked or loved paper boosts its authors, co-authors, topics, venues, keywords, and tags. A disliked, removed, or low-rated paper lowers those same connected signals. The effect is capped and explainable as paper_signal_adjustment, so one paper can nudge a candidate up or down without overwhelming strong direct evidence from the buckets above.

5. Dismissal cluster penalty. When you reject a suggestion (or remove a followed author), ALMa records a negative signal on that person — but it doesn't stop there. It also remembers the cluster of attributes that author belonged to and penalizes future candidates that overlap the cluster. The penalty has four dimensions:

Dimension	Penalty per hit	Why this weight
Topic	2.0 / shared topic-cluster hit	Strong signal of "this kind of research"
Venue	1.5 / shared venue	Moderate: venues are broader buckets
Institution	1.0 / shared institution	Light: many candidates share institutions for non-cluster reasons
Coauthor	0.8 / paper co-authored with dismissed pool	Lightest: dismissing an author often means "not this person", not "no one they've written with" — co-authorship is noisy negative evidence, so only deep collaboration (10+ shared papers) registers meaningfully

Total penalty per candidate is capped at 30 points (30% of the band). Even a perfect cluster match never fully zeros a candidate — if you really don't want them, dismiss them explicitly. The lookback is 100 days, so old dismissals decay out and your taste can shift.

When this fires, the suggestion carries a dismissal_penalty field showing how many points were subtracted.

6. Bucket outcome calibration. ALMa observes which buckets actually produce authors you keep. Every Follow on a rail card is logged with the bucket label that surfaced the author; every Dismiss is logged with the same attribution. Over time, the follow / dismiss rate per bucket smooths into a multiplier in [0.5×, 1.5×] (Beta-Bernoulli posterior, α = β = 2, 180-day window with 60-day half-life decay). The multiplier applies on top of the static bucket weights from settings, so buckets that consistently produce keepers earn more airtime.

The card surfaces this as bucket_calibration_multiplier and renders an ↑ bucket 1.18× / ↓ bucket 0.74× chip when the multiplier deviates ≥0.05 from 1.0. On a fresh DB nothing changes — the priors keep every bucket at 1.0× until enough rail-side events accumulate.

How your actions shape the rail

Action	Effect on suggestions
Save a paper to Library	Adds the paper's co-authors to the library_core bucket.
Rate a Library paper 5★	Triples the weight of every co-author on that paper; doubly amplifies first / last authors.
Rate a Library paper 1-2★	Shrinks the weight of those co-authors (0.2× / 0.5×). The paper still feeds the model — it just barely contributes.
Like / Love / Dislike / remove a paper	Projects a signed ranking signal to the paper's authors, topics, venue, keywords, and tags. Paper Dismiss changes visibility only.
Follow an author	Removes them from suggestions; their followed status seeds the network buckets on next refresh and adds positive author-profile signal to Discovery ranking.
Dismiss / remove a suggested author	(a) Suppresses that author for 250+ days. (b) Adds their topic / venue / coauthor / institution profile to the dismissal cluster — future similar candidates lose up to 30 points. © Adds negative author-profile signal to Discovery ranking.
Refresh network buckets	Fetches fresh openalex_related and s2_related candidates from OpenAlex / S2 and writes them to the cache. The next rail visit reads them.

Each bucket has its own weight in the final merge (configurable in Settings → Discovery → Author suggestion weights). By default, library_core = 1.0, cited_by_high_signal = 0.9, semantic_similar = 0.8, adjacent = 0.7, openalex_related / s2_related = 0.9 each.

Tilting weights toward the network buckets surfaces more authors you don't already know; tilting toward library_core / adjacent keeps the rail tied to your existing reading.

For the precise formulas, constants, and tuning surface, see Scoring formulas → Author suggestions.

Preprint ↔ journal twin engine

A common problem in scholarly metadata: a single work shows up as two distinct OpenAlex rows — one for the arXiv / bioRxiv preprint and one for the published journal version. ALMa includes a deduplication engine that detects these pairs and collapses them.

Detection signals:

1. Vendor DOI prefix — 10.48550/arXiv.*, 10.1101/*, 10.31234/*, etc.
2. Normalised title key — punctuation / whitespace insensitive.
3. Year proximity — preprint and published version typically within ±2 years.
4. SPECTER2 cosine ≥ 0.98 (when both rows have vectors) — the tiebreaker for cases where the title changed between versions.

When a pair collapses, the journal version wins (canonical). The preprint row keeps its UUID for FK integrity but gets canonical_paper_id stamped to the journal id, and Library / Discovery reads filter canonical_paper_id IS NULL so you only see one card per work.

Activity-backed actions

Most heavy author-side operations run in the background and surface in the Activity panel:

• Refresh author — pull latest works.
• Refresh authors with scope — bulk refresh for all followed, all tracked, or a custom selection.
• Deep refresh all — fully re-pull every author's works (used after schema changes).
• Dedup preprint↔journal twins — runs the twin engine across the corpus.

The Activity envelope reports per-source timing and per-author results so you can see exactly which part of a slow refresh is slow.

API

GET    /api/v1/authors
POST   /api/v1/authors                          # add
DELETE /api/v1/authors/{id}                     # unfollow
POST   /api/v1/authors/{id}/refresh
POST   /api/v1/authors/deep-refresh-all
POST   /api/v1/authors/{id}/resolve-identifiers
POST   /api/v1/authors/{id}/merge-profiles
GET    /api/v1/authors/suggestions              # multi-source

GET    /api/v1/library/followed-authors
DELETE /api/v1/library/followed-authors/{id}

See REST API.