Very interesting our conversation yesterday! I expand to give some context to @diego:

• Q1 is motivated by the examples you have presented in the past providing SHAP values for model explainability (@ppelberg @nayoub would be interested not only in informing editors about the likelihood of the edit getting reverted, but also about the features that explain that likelihood).
• Q2 is motivated by the current engineering constraints of using the model with edits that are not yet stored.

Documenting some notes to help answer the open questions and goals described in the task based on my review of available resources.

2. [optional] What information does the Language-agnostic revert risk model need in order to assess the likelihood that said edit would be reverted? In what format does the model need this information? E.g. does it simply need a revisionID?

• The revision risk model currently calculates a score for each revision indicating the likelihood that the edit should be reverted. This can be calculated based on the revision id and and wiki of the published edit. The Research team has been discussing and working on schemas for this data (T331401) which will be helpful in accessing the data for future analyses.

We also think this model could be useful for distinguishing edits that are being made in good vs. bad faith. We think know this distinction will be useful as part of the analysis we have planned in T342930.

• In that planned analysis, we identified one of the indicators as a "Significant drop in edit completion and a spike in edit abandonment in good faith edit session where Edit Check is activated”. This would require us to determine if it is a good-faith edit session while the user is attempting an edit, which is not feasible yet per engineering constraints @Pablo mentioned in T343938#9082581. The revision risk model requires a revision ID, which is only stored with published edits.
• Additionally, per the project page, "the goal of the model is to detect revisions that might be reverted, independently if they were made on good faith or with the intention of creating damage".
• As an alternative, I think it would be useful to review if the edit check causes any changes in the proportion of published edits that add new content and are above an identified revert risk threshold (as an indicator that edit check is improving edit quality) (already identified as one of the KPIs for the AB test). This can be reviewed along with any significant changes in overall edit completion and abandonment rate to help provide some insight into the type of edits that are likely being abandoned due to this intervention.
• Related to possible approaches to identifying vandalism, the Moderator tools team is working on proposing criteria to identify a vandalizing edit to evaluate the Automoderator project (See T349083). This would also require us only to review published not attempted edits as the criteria includes if it was reverted.

Per earlier discussions with @ppelberg, I've created T354303 for the work to be done based on findings from this task.

Noting that T356102: Allow calling revertrisk language agnostic and revert risk multilingual APIs in a pre-save context is done, so it's possible to check the contents of an edit before it's saved. The questions about how to interpret the score and what thresholds would be concerning are the focus of a hypothesis in Q2, WE4.2.11a that @Kgraessle is working on.

In T343938#10287746, @kostajh wrote:

Noting that T356102: Allow calling revertrisk language agnostic and revert risk multilingual APIs in a pre-save context is done, so it's possible to check the contents of an edit before it's saved. The questions about how to interpret the score and what thresholds would be concerning are the focus of a hypothesis in Q2, WE4.2.11a that @Kgraessle is working on.

@Samwalton9 and probably @KCVelaga_WMF can comment on this.

In T343938#10294057, @diego wrote:

In T343938#10287746, @kostajh wrote:

Noting that T356102: Allow calling revertrisk language agnostic and revert risk multilingual APIs in a pre-save context is done, so it's possible to check the contents of an edit before it's saved. The questions about how to interpret the score and what thresholds would be concerning are the focus of a hypothesis in Q2, WE4.2.11a that @Kgraessle is working on.

@Samwalton9 and probably @KCVelaga_WMF can comment on this.

These thresholds are now defined for 20 wikis (see T391964: [Epic] Recent Changes ORES Enabled Revert Risk Powered Filters Rollout Plan) and there is discussion in T398291: AI/ML Infrastructure Request: Expand ORES-enabled RevertRisk filters deployment to all wikis, excluding Commons and Wikidata about what would be needed to expand the threshold calculations for other wikis as well.