[EPIC] API Endpoint for Funding Statement Parsing and ROR ID Matching

[adambuttrick]

Summary

ROR is increasingly used to structure funding metadata that appears in scholarly works. Today, the majority of that metadata is derived from free-text funding statements, but there is no widely-used tool to convert those inputs into structured, ROR-identified metadata. We want to explore adding an API endpoint that parses a funding statement, extracts each funder and its award IDs, and resolves every funder to a ROR ID using our existing matching pipeline, just as the affiliation parameter resolves a free-text affiliation string to ROR IDs. The COMET initiative has trained a small LLM purpose-built for the extraction step, which makes this a good moment to consider the scope the work.

Goal

A funding-statement endpoint should:

1. Accept a free-text funding statement.
2. Extract structured funders and their award IDs from it using a fine-tuned small LLM.
3. Resolve each extracted funder name to a ROR ID by running it through the existing
   affiliation-matching pipeline.
4. Return both the raw extraction (funders, award IDs, scheme, title) and the ROR matches,
   with enough scoring information for callers to trust or filter the results.

Questions and Decisions

• Where does the funding statement parsing model actually run? It can't live inside the existing CPU-only container, as model inference needs a GPU.
• Should the endpoint be synchronous or asynchronous? LLM inference served over an API endpoint would likely takes several seconds. Do we then hold requests open, or return something like a job handle?
• What shape should the endpoint take, e.g. do we use a new funding-statement-style query parameter like how the affiliation parameter works or use a dedicated route?
• How do we match extracted funder names to ROR IDs? Crossref has developed a modified form of the single search matching strategy, tuned for matching ROR IDs to funders, but this is not implemented in our API. Do we implement as part of this strategy or as a separate service?
• How do we express confidence in the results? Funding statement parsing has two stages, extraction confidence from the model and match confidence from the funder matching.
• What are the cost, scaling, and rate-limiting implications? GPU inference is a lot more expensive than ES queries, and the ROR API is currently free for affiliation matching (within rate limits).
• How do we handle model versioning and updates, ensuring compatibility with our inference setup?
• How do we test this? The rorapi/tests/ suite has pretty good patterns for affiliation matching, but our CI has no GPU.

Acceptance criteria

• A funding statement can be submitted to the ROR API and returns structured funders and award IDs, with each funder resolved to a ROR ID where a confident match exists.
• The latency and availability of the endpoint is defined, documented, and acceptable, given that it depends on LLM inference.
• The inference-hosting approach is documented and reproducible by any developer working on ROR or using the API locally.
• Test coverage exists for both the extraction stage (model service mocked) and the resolution stage (against real ROR fixtures).