Blogfoundation

Sugra Research: a citation either resolves or it does not

A fabricated citation outlives the conversation that produced it. An identifier either resolves or returns 404, and that single rule removes a class of error that is otherwise very hard to catch downstream.

ShareXLinkedInFacebookTelegramRedditEmailCopy linkMarkdown
Sugra Research - registered identifiers, not recalled ones

A fabricated citation is a different class of error from a wrong number. A wrong number gets corrected on the next pull. A fabricated citation gets pasted into a document, cited by a colleague who did not check it either, and surfaces two years later in a board pack where nobody remembers who introduced it. It outlives the conversation that produced it.

Models produce them constantly, and they produce good ones: plausible authors, a plausible venue, a DOI with the right shape. The output looks exactly like a real reference because the model has seen a hundred thousand real ones and is completing the pattern.

The fix is not a better model. It is that an identifier either resolves or it does not, and asking is one HTTP call.

Three questions hiding inside “is this real”

Does the work exist. This is the identifier question and it has a binary answer. Not “probably”, not “I believe so”. A DOI or an arXiv id is registered or it is not.

Does it say what is claimed. A real paper can be cited for something it never argued. Existence is the floor, not the ceiling, and checking this means reading what the work itself cites and who cites it back.

What is its standing. A preprint and a peer-reviewed article are both legitimate and they are not the same object. So is knowing the licence, because a claim you cannot legally reproduce is not usable in a product.

Sugra Research answers the first two directly and gives you the material for the third.

What a fabricated identifier gets you

Ask for a DOI that has the correct shape but was never registered:

GET /api/v1/research/crossref/works/10.1093/bib/bbag999999
404  {"detail": "DOI not found: 10.1093/bib/bbag999999"}

Same for a preprint id that looks entirely normal:

GET /api/v1/research/arxiv/paper/2401.99999
404  {"detail": "arXiv paper not found: 2401.99999"}

That is the whole mechanism. Nothing clever. A model asked the same question produces a summary, an author list and a confident sentence about methodology, because producing text is what it does and it has no notion of registration.

A real identifier returns the record instead:

GET /api/v1/research/crossref/works/10.1093/bib/bbag239

type:       journal-article
publisher:  Oxford University Press (OUP)
issue:      2
published:  2026-03
licence:    CC BY-NC 4.0, applies from 2026-04-30 (60-day delay)

Note the licence block, because it answers the third question above without a lawyer. The content version, the start date and the embargo are all in the record. If you are building anything that redistributes or quotes at scale, that field decides what you may ship, and it is right there next to the title.

Existence is not agreement

The harder failure is a citation that resolves and still does not support the claim attached to it. For that you need the graph around the work, not the work alone.

GET /api/v1/research/crossref/references/10.1038/nature14539
reference_count: 103

One hundred and three outbound references for a single paper, each either a registered DOI or the raw unstructured string the publisher deposited.

The inbound direction sits on the work record itself, where the authoritative count lives:

GET /api/v1/research/crossref/works/10.1038/nature14539

title:                   Deep learning
publisher:               Springer Science and Business Media LLC
reference-count:         103        (what it cites)
is-referenced-by-count:  74,490     (what cites it)

A hundred and three out, seventy-four thousand in. That asymmetry is the citation graph in miniature, and it turns “the paper says X” from an assertion into something checkable: the reference list shows what the work was built on, the inbound count shows whether the field engaged with it. Neither is a verdict. Both are evidence, and both are absent from an answer generated out of training data.

Two practical notes. Reference coverage depends on what the publisher deposited, so an empty list means nothing was supplied rather than that the paper cites nothing. And unstructured references are common, so an agent consuming this must handle a plain string where it expected an identifier.

Facts with a committee behind them

Some questions have exactly one authoritative answer maintained by a specific body, and those are the ones models get wrong most confidently because the answer sounds like general knowledge.

GET /api/v1/research/nber/recession-dates

count: 35   (from 1854)
...
peak 1990-07  trough 1991-03   8 months
peak 2001-03  trough 2001-11   8 months
peak 2007-12  trough 2009-06  18 months
peak 2020-02  trough 2020-04   2 months

Thirty-five US recessions since 1854, each with a peak, a trough and a duration, from the committee that does the dating.

Now look at the response metadata, because it teaches something about the whole platform: data_time is 2021-07-20. Five years old at the time of writing.

That is not a stale cache. That is the date the dating committee last made a determination. The 2020 recession was declared over in July 2021, and no recession has been dated since, so the correct current answer carries a 2021 timestamp. Freshness means different things in different domains, and a system that hid this behind a synthetic “updated today” would be lying in a way that sounds reassuring.

An agent that prints the observation date alongside the value gets this right for free. One that assumes recent equals current does not.

Questions where the number cannot be recalled

Long-run economic history is the other place fabrication is guaranteed, because the honest answer requires a specific dataset with a specific methodology, and no model carries the table.

GET /api/v1/research/maddison/country/GBR

observations: 776
first:  year 1     population 800 thousand,        gdppc not available
last:   year 2022  gdppc 38,406.53, population 68,093.38 thousand

Seven hundred and seventy-six observations reaching back to the first century. Ask a model what British GDP per capita was in 1700 and you will get a number. Ask it twice and you may get two. The series has an answer, with a gap structure that is itself informative: gdppc is null for the early rows because the estimate does not exist, not because the value was zero.

The same shape covers world and regional aggregates, and the Penn World Table sits alongside for productivity and comparable cross-country accounting. Both publish their variable dictionaries and citation policy through the API, which matters because using these series without citing the project is a licence problem, not a style preference.

One trap worth knowing before you build

The search endpoint takes q, not query. Send the wrong name and you do not get an error:

/research/crossref/search?q=attention+is+all+you+need     -> relevant results
/research/crossref/search?query=attention+is+all+you+need -> HTTP 200, unrelated works
/research/crossref/search?nonsense=zzz                    -> HTTP 200

Unknown parameters are ignored rather than rejected, which is normal framework behaviour and is still a real hazard here: an unfiltered search returns plausible-looking scholarly records, so a typo in a parameter name produces output that passes review by eye. If you are wiring an agent to this, assert that the field you filtered on actually appears in the results.

The long run is a different instrument from the forecast

Scholarly data and macro data get filed separately, which hides the most useful thing either of them does: they measure the same quantity on scales that mean different things.

The long-run series for the United States runs 226 observations back to 1650. Compound what it contains:

GET /api/v1/research/maddison/country/USA

1820 to 2022    x21.9 over 202 years    1.54% a year
1913 to 2022     x5.8 over 109 years    1.62% a year
1950 to 2022     x3.8 over  72 years    1.89% a year

Roughly one and a half to two percent a year, sustained for two centuries. That is the whole industrial era expressed as a rate, and it is a startlingly small number.

Now put it next to a forecast revision. In the Macro post the IMF cut a single year of German growth by 0.29 percentage points between two publications, which reads as a rounding difference in a headline.

Against a long-run trend of 1.54 percent, it is not. A permanent shift of that size is the difference between an economy doubling in 45 years and doubling in 38. Nobody is claiming one revision to one year is permanent. The point is that the same unit means two completely different things depending on which instrument you are reading it with, and the only way to know which you are holding is to have both.

That is why the two directions belong to the same key. The forecast tells you about next year and gets revised. The long-run series tells you what a percentage point has historically been worth, and it does not move.

Where this stops

Research returns metadata and registered identifiers. It does not return judgement.

We can tell you a DOI resolves, what the work cites, who cites it, when it was published and under what licence. We cannot tell you the paper is correct, that the field agrees with it, or that a preprint has been reviewed. Reference lists are only as complete as publishers deposited. Full text is not ours to give: paywalled content stays with the publisher, and the licence field exists so you know which side of that line you are on.

The point is narrower than “AI for literature review” and more useful: if the tool did not return an identifier, the agent may not invent one. That single rule removes an entire class of error that is otherwise very hard to catch downstream.

Running it

H="x-api-key: $SUGRA_API_KEY"
B=https://sugra.ai

# does it exist
curl -sS -H "$H" "$B/api/v1/research/crossref/works/10.1093/bib/bbag239"
curl -sS -H "$H" "$B/api/v1/research/arxiv/paper/1706.03762"

# what it cites (outbound), and how often it is cited (inbound, on the work record)
curl -sS -H "$H" "$B/api/v1/research/crossref/references/10.1038/nature14539"
curl -sS -H "$H" "$B/api/v1/research/crossref/works/10.1038/nature14539"   # is-referenced-by-count

# search (note: q, not query)
curl -sS -H "$H" "$B/api/v1/research/crossref/search?q=attention+is+all+you+need&limit=5"
curl -sS -H "$H" "$B/api/v1/research/arxiv/search?q=diffusion+models&limit=5"

# facts with a committee behind them
curl -sS -H "$H" "$B/api/v1/research/nber/recession-dates"

# long-run series
curl -sS -H "$H" "$B/api/v1/research/maddison/country/GBR"
curl -sS -H "$H" "$B/api/v1/research/pwt/country/GBR"
curl -sS -H "$H" "$B/api/v1/research/maddison/definitions"

Store the identifier, not the summary. A summary is what you understood. The identifier is what you can hand to someone who disagrees.


Metadata and identifiers, not peer review. Values pulled live 2026-07-25.

Previous: Sugra Earth. Next: Platform intro. Full series: Platform intro.

Integrate with one key across every product direction.

Get API keyDocsFamily