Signal scoring algorithm

Function: computeSignalScore() in lib/scoring/engine.ts

Each signal is processed in a fixed order. The order matters — later steps see the results of earlier ones.

1. Check zero-point conditions
   → if triggered: score = 0, skip all multipliers, stop here

2. Check penalties
   → spam: add spamPenalty (-12)
   → pr_close_no_merge: add prClosedNoMergePenalty (-10)

3. Bot activity check (zero-point)
   → author.type === 'Bot' OR login.endsWith('[bot]') → score = 0

4. [contributor only] Daily quota
   → if daily count for signal type > quota limit → score = 0

5. [contributor only] Diminishing returns
   → if weekly count > weeklyThreshold → apply decay formula

6. Apply multipliers (in order):
   a. first_activity (1.5×)
   b. merged_pr_commit (1.2×)
   c. pr_linked_to_issue (1.1×)

7. For review signals: multiply by reviewStateWeights[review.state]

8. Final score = (base × multiplier_product × reviewStateWeight) − penalties

Steps 4 and 5 only apply in contributor mode. Repository and team scoring use skipQuota: true.

Base points

Review state weights

Applied as a multiplier to review signals only.

A review comment (review_comment) is a separate signal type and does not use these weights.

Multipliers

All multipliers stack multiplicatively. They are applied in the order listed.

first_activity only applies to the first signal of each type within a single scoring run. Repository scoring skips the first_activity multiplier entirely.

Penalties

Penalties are subtracted after the multiplier product is calculated.

Zero-point conditions

Each condition is independently toggleable in a preset. All are enabled by default.

When a zero-point condition triggers, score = 0 and multipliers are not applied.

Daily quotas (contributor mode only)

Signals beyond the daily limit score 0 points. Quotas are tracked per-user per-day within a scoring run.

Diminishing returns (contributor mode only)

Applied when a user exceeds weeklyThreshold signals of the same type within the current week.

Formula:

if weeklyCount > weeklyThreshold:
  excess = weeklyCount - weeklyThreshold
  factor = max(0.2, 1 - (excess × 0.11))
  points = base × factor

Example: a user has 13 commits in the current week (weeklyThreshold = 9, decayFactor = 0.11).

• excess = 13 − 9 = 4
• factor = max(0.2, 1 − (4 × 0.11)) = max(0.2, 0.56) = 0.56
• A commit worth 10 base points scores 10 × 0.56 = 5.6 points.

At excess = 8 (17 commits/week): factor = max(0.2, 1 − 0.88) = max(0.2, 0.12) = 0.2 — floor is reached.

Entity aggregation modes

Contributor (computeScores() in lib/scoring/engine.ts)

• Processes signals chronologically per user.
• Full scoring context: daily quotas, diminishing returns, all multipliers.
• Output: entries[] sorted by score descending with sequential rank.

Repository (aggregateByRepository() in lib/scoring/aggregate.ts)

• Groups signals by repository.
• skipQuota: true — no daily quotas, no diminishing returns.
• Zero-point conditions and penalties still apply.
• Fresh scoring context per repository.
• first_activity multiplier is filtered out.

Team (aggregateByTeamSignals() in lib/scoring/aggregate.ts)

• Runs computeScores() first to get per-user scores.
• Maps users to teams via teamMemberships (fetched by fetchOrgTeamsDataGraphQL).
• Sums user scores per team.
• A user in multiple teams contributes their full score to each team.
• Deduplication within a single team (a user counts once per team regardless of how many team_members rows exist).
• Returns entries with teamSlug, memberCount, and breakdown.

Signal metadata

Each signal stores JSONB metadata (max 2048 bytes, enforced by DB CHECK constraint).

Bot detection

A signal is flagged as bot activity when either of these is true:

• author.type === 'Bot'
• login.endsWith('[bot]')

The isBot flag is set during normalization (normalizeGitHubData() in lib/scoring/normalize.ts) and stored in both the signal metadata JSONB and the users.is_bot column.

When the bot_activity zero-point condition is enabled (default: true), any signal with isBot = true scores 0 points.

Content hash and deduplication

normalizeGitHubData() produces a SHA-256 hash (first 32 characters) from:

SHA-256(event_type + user + repo + timestamp + identifier)

The signals table has a unique index on (user_id, type, repository_id, event_timestamp, content_hash). upsertSignals() is fully idempotent — re-ingesting the same GitHub activity produces no duplicate rows.