Refactor confidence scoring to be based on a numeric system

[MoralCode]

We don't seem to be leaving ourselves much room on either end of the scale for things like git-ai (higher confidence) or online ai detection tools (lower confidence)

Maybe a followup to change to a numeric scoring system that we then collapse into "high medium and low" for user feedback alongside the numbers later would be a more extensible/flexible system for the future?

Originally posted by @MoralCode in #11 (comment)

email tools like spamassassin do this too. IMO this would allow for the option of maintainers to set a specific score at which something should be flagged as AI for their own repo.

The hard part is probably standardizing the number system. i.e. do we have points mean something? or just use them as arbitrary units (that can be configured) and maybe normalize them to some known scale before outputting to the user (so introducing new signals doesnt re-scale everyones existing points thresholds)

[MoralCode]

multiple "low/medium/high" values might be good so we can parallel the various categories (level of human involvement, etc, what model etc. made by the AI Attribution spec.

see #25

[omkar-foss]

Have created a basic proposal doc for numeric confidence scoring: https://gist.github.com/omkar-foss/a4ce5a23f4d8bff1a5a1c3d647031c24

Tried to keep it as simple as possible to maintain explainability to the user (yes, we could add a scrore drilldown shown to user after finalizing the scoring approach).

Request you all kindly check it out and provide feedback and we can iterate on top of this, thanks.

[MoralCode]

Part of the reason that i wanted to do a points system was to have something we could map all the different disclosure methods to that has like specific criteria for what certain things are worth point wise.

I'd like to know WHY/how you picked the point values you did for each of the detection methods you listed so we can define the rubric such that someone else could be given the list of detection methods and have a reasonable chance of assigning roughly the same points to the same things.

I don't want to assume that we will all be around working on this project forever, and I want a system that helps all contributors to this project consistently evaluate different/new detection signals that may come up in the future.

another motivation for the points system is to allow for normalization so that if a new detection method gets added we can calculate the total score and adjust it to be a 0-1 or 0-100 value so that end users dont have to adjust their configured threshold values as new things are added

I left a comment on the gist with an AI generated first-pass at such a rubric that looks like a good start to me. Hoping this can kickstart a discussion on what we want. I think id want to adjust the scales a little bit and maybe find a way to introduce the concept of "concurrency" in our pipeline, i.e. some detection signals are likely to be seen together and some are likely to be seen independently. How can we make it so that the existence of additional independent signals doesn't affect the overall point total and thus the normalized score?

[omkar-foss]

I'd like to know WHY/how you picked the point values you did for each of the detection methods you listed so we can define the rubric such that someone else could be given the list of detection methods and have a reasonable chance of assigning roughly the same points to the same things.

I've assigned point values (+35, +30, etc) based on the probability of each Finding e.g. a committer email being present has a significantly high probability compared to AI tool mention. But the points are absolute values right now i.e. +35 doesn't have any further drill down as I tried to keep it simple so we can iterate on it.

another motivation for the points system is to allow for normalization so that if a new detection method gets added we can calculate the total score and adjust it to be a 0-1 or 0-100 value so that end users dont have to adjust their configured threshold values as new things are added

+1 yes, we should keep the end score scale constant throughout. IMO we should always show the user a final score in range 0 to 100.

I left a comment on the gist with an AI generated first-pass at such a rubric that looks like a good start to me. Hoping this can kickstart a discussion on what we want.

I think for implementation we could start with Axis 1 part in the rubric from your comment which is the confidence rating (or score). Then we could go to Axis 2 in next phase of implementation, as it's much more detailed and goes into repo-level AI checks - which I'm concerned is a bit nuanced with cases where false positive could be possible (e.g. some repos that delegate QOL to AI agents will have large number of AI commits)

some detection signals are likely to be seen together and some are likely to be seen independently. How can we make it so that the existence of additional independent signals doesn't affect the overall point total and thus the normalized score?

For such cases we can use weighted averages. We define signals' individual points and weights for when they occur together. e.g. Individual points: sig1=10 pts, sig2=2pts, Weights for combined occurrence: sig1=80%, sig2=20%. So when they occur together we shall take a weighted average: sig1withsig2 = 10 * 0.8 + 2 * 0.2 = 8.4 pts. As more combinations are added weights need to be adjusted so their sum equals 1 (i.e. 100%) so the score will always remain constant and normalized.