Where each number comes from

Two datasets sit in one database. dun publishes what it recorded on the developer's machine — commits, agent events, sessions, identities, teams. DevLake collects the rest from the systems you connect — the git host, the tracker, CI, incidents. The dashboards join them. This page is the join map: for each thing DevLake can supply, which tables it fills, which columns the panels read, the key on which it meets dun's data, which dashboards depend on it, and what those dashboards show when it is missing — because a missing connection never renders as an error, it renders as a plausible-looking absence.

Every table and column below was read out of the dashboard JSON in the repository, so it can be checked.

The join map

dun publishes                          DevLake collects
──────────────────────                 ─────────────────────────────────
whodunit_commits.commit_sha ─────┬──── issue_commits.commit_sha ── issues ── board_issues ── boards
                                 │         (tracker: Linear, Jira, Azure Boards)
                                 └──── repo_commits.commit_sha ── repos.name
                                           (git host: GitHub, GitLab, Bitbucket, Azure DevOps)
committer email ─ whodunit_identities ┬─ whodunit_teams.contributor      (dun: config map, read first)
                                      └─ team_users.user_id ── teams     (DevLake: org plugin CSV, fallback)
whodunit_sessions.model ───────────── whodunit_model_prices.model         (fetch-model-prices.py)

time window only (no join to dun rows):
  cicd_deployment_commits ── project_mapping   (CI: GitHub Actions, GitLab CI, Jenkins, CircleCI …)
  project_pr_metrics                            (computed by DevLake from pull requests)
  incidents                                     (PagerDuty, Opsgenie, incident.io, webhook)

Three things the diagram makes visible. The tracker and the git host join to dun's commits by commit SHA, which is why every attribution can be tied to an issue and a repository name without dun ever storing either. Teams join by committer email, so any team source has to speak in emails. And the delivery metrics — deployments, pull-request timings, incidents — never join to dun rows at all: they sit beside the adoption curve in time, which is why every "does delivery change with adoption" panel is a correlation over weeks and says so.

Git host — GitHub, GitLab, Bitbucket, Azure DevOps

DevLake table	columns the panels read	joined on
repo_commits	commit_sha, repo_id	= whodunit_commits.commit_sha
repos	id, name	repo_commits.repo_id = repos.id
commits	sha, authored_date	= whodunit_commits.commit_sha

What it supplies. The repository's name. dun identifies a repository by its root-commit id and, by design, never records the name or the remote — see Privacy. The name only ever appears on a dashboard by joining through DevLake's repo_commits, and the $repo dropdown and every per-repository panel resolve it that way with COALESCE(MAX(repos.name), LEFT(repo_id, 8)). commits also supplies the denominator for Coverage: how many of the repository's commits carry a trailer at all, which dun's own table cannot answer because every row in it exists because a trailer was written.

Depends on it. Attribution (Coverage), Adoption and its rollout view (per-repository adoption and the not-instrumented share), the $repo filter on the Executive Summary.

Without it. Repositories appear as eight-character ids rather than names. Coverage cannot be computed and the panel says so. Everything else still works — attribution never needed the name.

Setup. Connecting your data: the GitHub token needs read:user for the commit-to-author mapping.

Tracker — Linear, Jira, Azure Boards

DevLake table	columns the panels read	joined on
issues	id, issue_key, status, created_date, resolution_date, lead_time_minutes, assignee_name	via issue_commits
issue_commits	issue_id, commit_sha	commit_sha = whodunit_commits.commit_sha
board_issues	board_id, issue_id	scopes an issue to the $board you selected
boards	id, name	the $board dropdown

What it supplies. Everything about tasks: cycle time, issues opened and closed, whether an issue was AI-assisted (any linked commit is), the backlog and its drain rate, productivity per task, and the assignee that the per-team forecast uses for open work.

The one rule that decides whether any of it appears: the issue key has to be in the commit message. DevLake fills issue_commits by matching keys like WHO-123 in commit messages. A team that does not write keys into commits has issues in issues and nothing in issue_commits, and every assisted-issue figure reads zero — not because nothing was delivered, but because nothing was linked. All 32 panels that join the two carry the same guard, issue_key REGEXP '^[A-Z][A-Z0-9]+-[0-9]+$', because a tracker with bare-integer keys would otherwise attribute unrelated commits and report AI-assisted issues that do not exist.

Depends on it. The Executive Summary's cycle-time comparison and issue panels, the Delivery Forecast entirely, the Productivity page's cycle time per stratum, the Investment Case's cost per assisted issue, the funnel's last stage, the Leadership view, Adoption's issue cohorts.

Without it. Every issue panel is empty or reads zero, and the cohort panels withhold rather than compare: the median-cycle panels need five issues a side and show n/a below that. The tooltip on each says "unlinked, not undelivered". Commit-grain panels are unaffected.

Which tracker. Linear and Jira are both read; the $board dropdown lists linear: and jira: boards and deliberately excludes github: ones, whose repositories also appear in the boards table. Migrating from one tracker to the other keeps both sets of issues visible; keys are matched per board.

CI — GitHub Actions, GitLab CI, Jenkins, CircleCI, and others

DevLake table	columns the panels read	joined on
cicd_deployment_commits	cicd_deployment_id, cicd_scope_id, environment, result, finished_date	time window; cicd_scope_id = project_mapping.row_id
project_mapping	row_id	scopes deployments to your project

What it supplies. Deployment frequency, change failure rate (result = 'FAILURE'), and the deployment outcomes chart. Not joined to dun rows: a deployment carries commits, but the panels read it as a weekly count beside the adoption share.

Depends on it. AI Impact on Delivery, the board-facing delivery view.

Without it. The deployment panels are empty and the DORA benchmark tiles say "no data in range". Adoption and attribution are unaffected.

Setup. A CI run only counts as a deployment when it matches the deployment pattern configured on the DevLake project — see Deployments need a pattern.

Pull requests — computed by DevLake

DevLake table	columns the panels read	joined on
project_pr_metrics	pr_cycle_time, pr_merged_date, and on the board view pr_coding_time, pr_pickup_time, pr_review_time, pr_deploy_time	time window

What it supplies. Lead time for changes and its stages. DevLake derives this table from the git host's pull requests; it needs the git host connected and the project to include the repository. The dashboards read this table rather than pull_requests directly, so the two delivery pages agree.

Depends on it. AI Impact on Delivery, the board-facing delivery view.

Without it. Lead-time panels empty; "PRs measured" reads zero. A stage with no data — review stages need review activity collected — is absent from the stacked chart, not zero.

Incidents — PagerDuty, Opsgenie, incident.io, or a webhook

DevLake table	columns the panels read	joined on
incidents	created_date, resolution_date	time window

What it supplies. Mean time to recovery. Thin by nature — a handful of rows — and the panels say it moves a lot with each one.

Depends on it. AI Impact on Delivery, the board-facing delivery view.

Without it. MTTR reads "no data in range". Nothing else is affected.

Setup. Mean time to recovery needs incidents.

Teams — two sources, config first

table	columns the panels read	joined on
whodunit_teams (dun)	contributor, team_name	contributor = committer email, after aliases
team_users, teams (DevLake)	user_id, team_id, name	user_id = committer email, after aliases

What it supplies. Every team filter and every per-team panel — 75 panels across ten dashboards — resolve COALESCE(whodunit_teams.team_name, teams.name, '(unassigned)'): the config map published by dun sync first, DevLake's org plugin second, (unassigned) always offered. Both routes, and why DevLake's user Id must be the committer email, are in Teams and identities.

Without either. Everyone is (unassigned), every panel still renders, and the team dropdown offers the one option. Nothing errors and nobody disappears.

Identities — dun

table	columns the panels read	joined on
whodunit_identities	alias, canonical	alias = contributor on commits, events and sessions

Not a DevLake source, but it sits in front of every other join: 146 panels resolve COALESCE(canonical, contributor) before filtering by person or looking up a team, so one person's several addresses count as one. With no aliases configured the join is inert and every result is byte-identical to the plain form.

Model prices — a script, not a connector

table	columns the panels read	joined on
whodunit_model_prices	model, provider, input_usd, cache_read_usd, cache_write_usd, output_usd, source, fetched_at	model = whodunit_sessions.model

Filled by fetch-model-prices.py from the providers' pricing pages; created empty by dun's schema so the join runs before anyone has fetched. A session whose model has no row is reported as unpriced, never priced at zero. See The investment case.

Reading an empty panel

Work down the map. A panel about issues that reads zero is almost always the issue key missing from commit messages, not a missing connector. A repository showing as an id is the git host not connected. DORA tiles saying "no data" are the CI pattern or the incident source. Everyone in (unassigned) is teams not yet loaded by either route. In every case the attribution underneath — which commits an agent wrote, and how much — is already there; the connection adds context to it, and its absence removes only that context.