@Xaosflux writing on mediawiki.org:

Having rules live on-wiki (like at MediaWiki:EditCheckRules.json or the like) would help projects adjust to their needs in a lighter weight format than the abusefilter (inspired by the newcomer tasks setup). That would satisfy 1 and 3; as far as 2 - not sure. Actual edits with it should get identified (a revision tag would prob suffice). It seems like edit-check is going to interfere in the publish workflow - this should be carefully considered with how it overlaps or times with ORES and AF - there are certainly edit types that could trigger all 3 of these things.

@Xaosflux's comment above sounds like a more generalized (and much more succinct) version of something I was trying to say at T327330#8607428. Money quote:

So I'm envisioning each rule you develop no longer living embedded in the software you are developing, nor in a library in the code base, but rather interpreted from an external source that lives at en-wiki (or any other wiki). You would provide the platform, the API, and the doc, and we'd write the rules.

I expanded on that thought using Templating as a possible approach, but any model that as Xaosflux said, has the rules "live on-wiki", whether that ends up being JSON, Templating, or any other method (or multiple ones) seems like the right way to go. However, my opinion is based on my having no internal view into what you are actually developing, so I'm not sure how applicable it is.

Alright, a couple of updates...

Updates

1. This week, the Editing Team will start collaborating with the Growth Team to figure out the extent to which we might use Community Configuration to provide the kind of configuration experience @Xaosflux described on-wiki [i] and @Mathglot described in T327330#8607428 and T327959#8954388.
2. I've added "⭐️" to the configuration options in the task description I'm proposing that we initially expose on-wiki:
   • A) Account attributes for whom Edit Check will be active
   • B) Where the citations Edit Check automatically inserts will be placed: before/after periods
   • C) What categories Edit Check is not activated on pages within
   • D) Edits in what sections Edit Check is not activated within. Note: this proposal will not be final until the Editing and Growth engineering teams reviews it. See "Thinking" below for rationale.

Thinking

The four configuration options proposed above are grounded in the initial principles that surfaced in the Editing Team meeting on 12 July 2023:

• Impact: configurations ought to contribute to volunteers, on a per-project basis, being able to adjust Edit Check in ways that meaningfully impact things like the rate of false positives and false negatives and the automated actions Edit Check makes without depending on the Editing Team.
• Awareness: volunteers ought to be equipped with the information they need to independently evaluate the impact of the configuration adjustments they make so that they can iterate towards a state where the feature is causing behavior that aligns with projects's stated goals, policies, and conventions.
• Distinctness [ii]: configuration options should not cause volunteers to become confused about the distinction between the various places on-wiki where volunteers could potentially configure how Edit Check works.

i. "Having rules live on-wiki (like at MediaWiki:EditCheckRules.json or the like) would help projects adjust to their needs in a lighter weight format than the abusefilter (inspired by the newcomer tasks setup)."
ii. There is likely a more accurate word than "Distinctness." Tho, it's not currently coming to mind.