The assessment rubric (v2)

This is exactly what WePerform measures — published in full, because secret scoring destroys trust. If it isn't written here, it isn't scored. Scores inform conversations; they are never an automated verdict.

Principles

• Individual metrics use rolling 90-day windows — daily numbers are noise.
• Deleting code, simplifying, and reviewing others' work are contributions, not absences.
• Every LLM score is stored with a rationale the author can read in full, and can dispute.

Static layer — all commits

• Survival rate: code still present 30 days after merge counts for you; code rewritten within 3 weeks counts against (churn).
• Complexity delta: adding behavior while holding or reducing cyclomatic complexity is good; complexity spikes without tests are flagged, not rewarded.
• PR scope discipline: small, coherent, single-purpose PRs; short cycle time.
• Review participation: substantive reviews on teammates' PRs.

Security layer — all PRs (Team and above)

• Semgrep findings: introduced counts against, resolved counts for; rule ids always shown.
• Dependency risk: new dependencies with known CVEs count against.
• Secrets: any committed credential pattern is flagged immediately — on every plan, always.

Review discipline — computed, not model-judged

Every assessed change carries a review-discipline score. It's a fact read from the data, not an opinion, so it's computed directly: reviewed pull request 5, pull request merged without review 3, direct to the default branch 1. Code quality and how the code landed are scored separately on purpose — a well-written change that reached production unreviewed is still good code that took an avoidable risk. Pull requests and sizable direct commits are both sampled, so people who don't work through pull requests still get feedback.

LLM quality layer — sampled significant changes, scored 1–5

• Readability — a new team member could follow the change without archaeology.
• Test discipline — tests cover the change, including edge and abuse cases; negative-path tests weigh heavily.
• Security craft — validation at trust boundaries, correct authorization, errors that fail closed without leaking internals, sane crypto.
• Scope & design — one thing, at the right layer, without gratuitous complexity.
• Interface usability — APIs, error messages and UI text are clear, actionable, and leak nothing sensitive.

Explicitly not measured

Lines of code, commit counts, hours worked, time-of-day patterns, and anything from repositories the integration is not installed on. Volume never raises a score.