System Map

Pullminder’s System Map (Phase 1) builds a dependency graph from your repository’s codebase so you can see how modules, datastores, queues, and services connect. It overlays incident history from Collective Memory as a heat layer, highlighting which parts of your graph have the most trouble.

System Map is a display-only feature. It surfaces the graph and heat overlay alongside the risk score. It never changes the score.

What System Map maps

System Map classifies every discovered entity into one of five node types and draws edges between them:

Node type	What it captures
Module	A code package, directory, or file that imports or is imported by other modules
Datastore	A database or persistent store (Postgres, Redis, SQLite, etc.) detected through connection strings or ORM config
Queue	A message queue or job broker (Redis queues, asynq, etc.) detected through connection URIs or client usage
External	An external API or SaaS endpoint called over the network
Service	Another Pullminder-tracked service in the repository

Edges connect these nodes by relationship type: imports (code imports another module), calls (function or method calls), reads/writes (data access), and depends-on (infrastructure or config dependency).

The graph is built in two passes: a tree-sitter pass extracts code-level edges (imports, calls), and a heuristic pass detects infrastructure edges from configuration files and connection strings. Only derived metadata persists. Source code is fetched transiently and deleted after extraction.

Privacy model

System Map follows the same privacy principles as Collective Memory:

Property	Behavior
Opt-in	Per-repo, off by default. No graph is built until you enable it.
Code handling	Source code is fetched transiently for extraction and deleted immediately. Only derived metadata (node keys, labels, edge types, file paths) persists.
Secrets	Never stored. Connection strings and environment variables are read in memory for classification only, then discarded. Persisted nodes carry a redacted handle (e.g. `datastore:postgres:primary`), never credentials or hostnames.
Disabling	Turning off System Map for a repo purges all stored graph data and cached renders immediately.

No source code, no file contents, no secrets. System Map stores only the structure.

Reading the incident heat overlay

When Collective Memory is enabled for the same repository, System Map overlays per-file incident counts onto the graph. Nodes representing files with prior trouble (hotfixes, reverts, recurring findings) appear with a heat color. Darker nodes mean more incidents. A node with no incident history appears neutral.

Clicking a node opens a panel showing the file path, node type, incident count, and a breakdown of finding categories from Collective Memory.

The heat overlay reads from the same file_memory table that powers Collective Memory and Red-Flagging. It does not write to it.

PR blast radius

When a pull request is analyzed, System Map checks which graph nodes the changed files map to. It walks downstream edges to find dependents and reports the blast radius in the PR comment:

Touches 3 modules; 7 downstream dependents (2 with prior incidents).

The blast-radius line appears in the System Map section of the PR review comment. It is advisory context. It does not block merges or change policy outcomes.

Blast radius is only available on the platform. The local CLI preview does not include it.

For cross-repository blast radius across your entire organization, see the Org-wide map section.

Previewing locally with the CLI

Run pullminder map from any repository root to preview the local working-tree graph without sending anything to Pullminder:

# Text summary (default)
pullminder map

# Structured JSON for tooling
pullminder map --format json

# Graphviz dot output for visualization
pullminder map --format dot | dot -Tsvg > graph.svg

The CLI command runs entirely on your machine. It extracts the graph from the local filesystem, prints it, and exits. No data is sent to Pullminder. No incident overlay or blast radius is available in the local preview because those need the stored history that only the platform has.

Org-wide map

Phase 2 extends System Map across repositories in the same organization. When multiple repos in your organization have System Map enabled, Pullminder stitches their individual graphs into a single org-wide view.

What stitching covers

Shared infrastructure nodes collapse across repos. If two repos both connect to the same Postgres database, that datastore appears once in the org graph, with a label showing which repos touch it. The same applies to shared queues, caches, and other infrastructure.

Cross-repo service-call edges are derived from identity matching. When one repo’s extracted graph shows an external API or HTTP client call whose host identity matches another repo’s internal service identity, an edge is drawn between those repos in the org graph. Identity matching is best-effort and not guaranteed to capture every service boundary.

Privacy-safe identity matching

Identity matching uses HMAC-SHA256 with a per-org salt. Internal host handles are hashed before any matching is performed. Raw internal hostnames are never stored or transmitted. The org view exposes only identity_key values (hashed internal or cleartext external) and driver labels. No hostnames or credentials leave the extraction pipeline.

A repo appears in the org-wide map if and only if its System Map toggle is enabled in the repository settings. There is no org-level toggle. Each repo opts in independently. Disabling System Map for a repo removes it from the org graph on the next build.

Cross-repo PR blast radius

When a pull request touches a module that maps to a shared service or datastore, and other repos in the org consume that same infrastructure, the PR comment includes a downstream-repos line:

2 downstream repos depend on changed infrastructure: repo-b, repo-c

The cross-repo blast radius appears alongside the per-repo blast radius in the System Map section of the PR review comment. It follows the same advisory pattern: it does not block merges or change policy outcomes. The line is omitted when no cross-repo dependents exist.

Enabling System Map

Open your Pullminder dashboard.
Go to Settings for the organization.
Find the repository you want to enable.
Toggle System Map on.

The graph builds on the next push to the default branch. There is no backfill of historical pushes. Only pushes after opt-in trigger a graph rebuild.

Current limitations

No live telemetry. The graph rebuilds on push to the default branch, not continuously. It reflects the state at the last build.
Hard caps. Maximum 5,000 nodes and 20,000 edges per build. Graphs exceeding these limits are truncated and flagged.
Display-only. The graph and blast radius are review context. They do not block merges or gate CI checks.

These limits are expected to narrow as System Map continues to evolve.