The models in question

• https://meta.wikimedia.org/wiki/Machine_learning_models/Production/Language_agnostic_link-based_article_topic
• https://meta.wikimedia.org/wiki/Machine_learning_models/Production/Article_country

The Problem

• The newer models only take in the article title as a parameter (which I assume is internally resolved into a revision ID by the API)
• The PageTriage extension expects the ORES extension to store the predictions indexed using (pageID, revisionID, model ... etc)
• The ORES extension is written with the expectation that the models being accessed can be fed a revision ID and that they will return the same output (as long as the same model is being used). This assumption is broken by the model, which, given the same article name (which can be derived from the revision ID) will give you different outputs depending on the underlying revision.
• There is a strong expectation (in PageTriage) that early on in an article's lifecycle, some articles will evolve significantly with each on-wiki edit, and the topic in which it is classified will evolve based on revision ID (this is particularly important in the context of PageTriage since we primarily deal with articles in the earliest stages of development)

Could PageTriage use the API instead of the ORES extension?

Not really, so the problem is mostly the feed, which needs to keep track of a lot of articles, each of which would be a separate query. The ORES extension is, in theory, supposed to be a very thin wrapper around the API itself; it has a bunch of hooks in the "correct" points in the recent-changes pipelines, which query the status of an article from the API and dump it into a DB for easy use (theoretically) by other extensions.

Would both the ores extension and pagetriage need changes?

If ORES (the extension) changes, PageTriage would need to change, but it would probably be relatively minor (I think). PageTriage really doesn't do much with ORES besides doing a bunch of DB joins