Skip to content

Collective Memory

Pullminder’s Collective Memory (Beta) tracks per-file history across your repositories so reviewers see not just what changed, but what broke before in the same files.

Collective Memory is a display-only feature. It surfaces context alongside the risk score — it never changes the score.

Collective Memory records three signals for every file touched by an analyzed pull request. Bot-authored pull requests (e.g., Dependabot, Renovate) are excluded from memory — they do not generate file history or churn signals.

Files repeatedly caught in reverts or hotfix branches signal fragile code. A file that has been reverted three times in the last six months carries different review risk than one with clean history — even if the current diff looks small.

Files quickly re-patched after merge indicate unstable changes. Collective Memory tracks how often a file is modified shortly after a prior merge, surfacing churn patterns so reviewers can ask whether the current change will hold. Churn detection also catches a quick re-patch of a previously-clean file — a file with no trouble history that is modified again within 45 days of a prior merge.

When the same finding category (e.g., SQL injection, hardcoded secret, test gap) recurs in the same file across multiple PRs, Collective Memory flags it. It also tracks authorship concentration — a file touched by only one author with repeated security findings is a different review signal than one maintained by a distributed team.

  • PR comment — Every analyzed pull request includes Collective Memory context in the review comment when relevant file history exists.
  • AI brief — For higher-risk PRs, the AI-generated reviewer brief includes Collective Memory signals alongside the risk score and finding summary.
  • Dashboard analytics — The memory dashboard provides per-repo trend charts and an org-wide troubled-files view so you can track signal patterns over time and across repositories.

Memory is surfaced as context, not as a gate. It does not block merges or change policy outcomes.

Does Collective Memory affect the risk score?

Section titled “Does Collective Memory affect the risk score?”

No. Collective Memory is display-only. The risk score reflects the current diff — diff size, security patterns, test coverage, and the other analyzer dimensions. Memory adds historical context to the review without changing the score.

This is by design. A file’s past is useful context for a human reviewer. It is not a signal that the current diff is risky.

Collective Memory follows the same privacy principles as the rest of Pullminder:

PropertyBehavior
Opt-inPer-repo, off by default. No data is collected until you enable it.
What is storedFile-path metadata and aggregate counts only. No source code, no diff contents, no file contents.
DisablingTurning off Collective Memory for a repo purges all its memory immediately.
GDPRAuthor erasure is supported (scrub author data on request). Per-repo purge covers right-to-deletion.

No code-level data means no code-level exposure. Collective Memory stores paths and counts — not your source.

  1. Open your Pullminder dashboard.
  2. Go to Settings for the organization.
  3. Find the repository you want to enable.
  4. Toggle Collective Memory on.

Memory begins accumulating from the next analyzed PR. There is no backfill of historical data — only PRs analyzed after opt-in contribute to the memory.

  • No data backfill. Only PRs analyzed after opt-in are recorded. Pre-existing history is not imported.
  • Per-repo only. Memory does not cross repository boundaries. A file’s history in one repo is independent of the same file path in another.
  • Display-only. Memory does not block merges, change policy outcomes, or gate CI checks. It is review context only.

These limitations are expected to narrow as Collective Memory moves from Beta to general availability.