Engineering productivity

Concepts

Productivity → Outcomes combines observed AI activity, merged PRs, and productivity points in one reporting workspace. Use aligned timelines and comparisons to investigate relationships between AI use and recorded output. An association between metrics does not establish causation.

Workspace views

Administrators explore activity and delivered work in four tabs:

Tab	What it answers
Overview	How did productivity points, merged PRs, gateway requests, active AI sessions, and parallel activity change over the selected period?
Compare	How do developers, teams, repositories, or projects compare? Use ranked charts, the full searchable table, trends, or a two-entity Head-to-head comparison.
Relationships	Are observed activity and outcome measurements associated across the full eligible population, or across completed weeks in one scope?
Evidence	Which work types, merged PRs, and retained AI activity support the measurements? Related work opens the existing contribution workflow.

One scope, period, and saved reporting timezone apply across these tabs. Complete 7-, 30-, and 90-day windows exclude today; last week and last month use local calendar boundaries. Current periods include only elapsed time and show that they are in progress. Custom selections include both displayed dates, up to 366 local dates. Calendar-year API selections include leap days and compare with the previous calendar year; year-to-date comparisons preserve the local date and wall-clock cutoff, with February 29 mapped to February 28 when needed. Each current or previous range remains separately bounded to 366 local dates. Quarter and year API buckets disclose partial calendar edges. These calendar options do not imply that older source data is retained.

Day lengths follow the selected timezone, including daylight-saving changes. Changing timezone saves your preference for the next sign-in.

Highest/Lowest 5, 10, or 20 and manual chart selections affect the chart only. They do not narrow the full comparison table, the scoring baseline, or the Relationships population. Head-to-head compares exactly two entities of the same kind across the metrics supported by the selected scope. Repository, project, and developer comparisons use productivity points and merged PRs from PR analysis. Their requests omit person-level session and activity metrics. Overlay and side-by-side layouts retain identical dates and shared value scales; A is blue and B is coral.

Entity total describes recorded group output and activity. Median observed user describes a typical user with observations; users without observations are not treated as zero. Team scope uses current primary membership, including for earlier periods. Repository/project delivery follows PR repository mappings; activity follows recorded session context. These evidence populations can differ.

Missing evidence remains unavailable, while observed zero remains zero. Open coverage details to see collection, retention, identity, or attribution gaps. Parallel session activity remains unavailable when source coverage cannot verify the parallel-window denominator; a session count is not substituted. Relationships excludes ambiguous identities and lost-source intervals and shows the included and excluded population. A lag aligns earlier activity with later outcomes; it does not establish that AI use caused those outcomes. Effectiveness already includes delivery signals, so correlations with output are not independent measures of AI behavior.

Outcomes keeps displayed results unchanged until you select Refresh data or change the reporting selection. Source updates and retained-result expiry do not replace the report or show an automatic refresh notice. Expired report values remain readable; refresh before requesting new details or exporting. Account access checks continue independently.

CSV exports contain the full filtered result, including rows beyond the visible page. Chart entities only explicitly limits an export to the selected chart cohort. Exports retain missing-value reasons and reporting context. Expired results require a refresh; an over-capacity request requires a narrower query, not a silently shortened CSV.

See Explore engineering outcomes for the workflow. Existing AI attribution, metric explorer, related-work, published reports, and settings links remain available. Older bookmarks retain their legacy workflow, and viewer accounts retain their authorized attribution view.

Comparison and history

AI PR share counts distinct merged PRs with observed or declared AI authoring or AI review evidence, divided by eligible merged PRs. Routine automation is excluded. Effectiveness scores pool PR facts in the selected period; saved weekly percentile ranks are not averaged. Membership and project mappings reflect current settings. Projects may overlap, so their scores must not be added into an organization total.

AI effectiveness shows Elite, High, Medium, or Low beside the overall score and comparable dimensions. Bands use fixed score thresholds configured under Settings → Productivity → AI Effectiveness: by default, Low below 50, Medium from 50, High from 75, and Elite from 90. Numeric scores still reflect the selected period and comparison group, but a given score receives the same band regardless of peer rank. AI adoption is displayed as counts and percentages without a performance band. Insufficient evidence receives no performance band.

AI effectiveness comparisons use the portion of your selected period that every participating repository has finished collecting. AI effectiveness data through shows the common cutoff. Scores remain available during routine refreshes; PRs merged at or after that cutoff join the comparison after collection catches up. AI PR counts and productivity points can include newer available activity. Weekly trend points use the completed portion of each week within your selected period. Coverage includes all eligible onboarded repositories in the comparison scope, even those with no PRs yet. Separate scans cover only the intervals actually collected; a gap stops the comparison at the beginning of that gap. After an upgrade, retained completed scans restore verified coverage. If the scan history is no longer retained, use Scan now for the desired period to establish coverage.

Collection pending means at least one participating repository has not collected the start of the period, or its access or scope needs attention. Open Repository status to inspect collection progress. Not enough evidence means there is too little comparable PR evidence to calculate a score. A low-volume team can have insufficient evidence even after collection finishes.

Developers have My Activity and My AI Effectiveness in the Builder Portal. My Activity uses the developer's saved reporting timezone and local-day or calendar-period selections. It shows matching summary cards for productivity points, merged PRs, gateway requests, and peak concurrent sessions, full-period productivity standing with band and percentile at the top of the summary stack, and an immediate comparison with the current primary team or permitted organization scope. The comparison shows your standing and colleagues’ bands, scores, bars, and whole-number percentiles, with member navigation below. A Metric selector emphasizes productivity points or productivity percentile. The same compact card order and chart style apply in administrator Developer scope and the Builder portal. Anonymous colleagues keep only their names private. Administrator Team or Global visibility overrides member name-sharing preferences; Member choice honors those preferences and Self disables comparisons. Changing the comparison group leaves personal points unchanged. Aligned productivity and gateway activity charts, repository/project PR charts, and PR evidence loaded on demand complete the report. Its custom ranges allow up to 366 inclusive local dates. See Productivity standing and percentile for the band, tie, missing-score, and percentile rules.

For selections of 2–7 local dates, My Activity shows daily retained productivity points grouped by each PR's local merge date, provided at least two actual day intervals exist. Missing scores remain gaps; recorded zero remains zero. A current day is clipped to the reporting cutoff and marked partial. The headline score and team band still cover the full selected period. A single-day selection shows its summary only. Longer ranges show trends when at least two complete local weeks exist; ranges over 90 days prefer complete local months when at least two are available. Partial weekly/monthly boundary periods are excluded from those trends and disclosed.

My AI Effectiveness retains its existing date ranges, calculations, coaching, privacy-aware comparison overlays, and Monday-based UTC completed-week history.

Manual PR work types

You can correct a merged PR's work type without reviewing its entire contribution assessment. Administrators can classify any PR in the authorized productivity scope. Developers can classify their own attributed PRs when the corresponding permission is enabled. Initial classification of an Unclassified PR and reclassification of an already classified PR have independent permissions; both are enabled by default. Viewer accounts cannot change classifications.

Administrators who sign in through OIDC can also classify PRs from the admin portal. Activity records identify them by their identity provider and stable subject, so changing an email address does not change the recorded identity.

A manual work type takes precedence over subsequent automated assessments, reprocessing, and assessment expiry. Selecting Unclassified is also a manual choice. A work-type change does not mark the full assessment as human reviewed.

Each change preserves the work type before the first manual edit and records the latest editor and change time. If the original value was Unclassified, the record also preserves whether the assessment was missing, expired, stale, ineligible, or explicitly unknown. Activity history records each successful change, including the previous and new values and a link to the source PR. The PR keeps its original and latest-change metadata for its lifetime; the event history follows your configured Activity retention period.

Changing an explicit manual Unclassified choice is a reclassification in history. Developer permissions continue to depend on the PR's current work type.

Changes recalculate the PR's productivity points from retained file statistics and the weights applicable to its merge date. Missing or stale file statistics remain unavailable until collection completes. Previously published report snapshots stay unchanged.

Live work-mix charts and PR filters use the corrected work type, even when equal weights leave the points unchanged. A missing file-statistics record still shows unavailable points. Human reviewed only continues to require a reviewed contribution assessment; changing a work type does not satisfy that filter.

New evaluated-report previews identify manual classifications separately from full human reviews. A feature work type alone does not supply evidence of novelty or implementation stage for those reports' feature multipliers.

Developers within one project

The following describes the retained metric explorer workflow and its older bookmarks. For the new workspace, use project scope with Compare → Developers; its chart limit is 20 and its full table remains independent of that selection.

Project scope selects the work being compared. Compare: Developers selects how to group that work; Compare: Projects groups work by project instead. The developer comparison uses only eligible merged PRs from the selected project's repositories, shared period, and optional team, repository, work-type, and target-branch filters. Contributors can come from different teams. A developer's work in other repositories does not enter this comparison.

Choose up to eight contributors using the searchable Developers to compare control. Duplicate display names include a stable identity. Selection and filters stay in the URL across the Overview, Productivity, and AI Effectiveness tabs and PR drilldowns, so a bookmarked comparison can be reopened. Relative periods advance when the report refreshes; custom dates retain their bounds.

Separate charts show points, merged PRs, and AI PR share on a common scale for each metric. Development mix counts all collected PRs by current work type, including unclassified work and PRs without points. Coverage shows classified, scored, and pending-data samples. Weekly trends align developers to UTC weeks and leave gaps for absent observations or unavailable scores. AI effectiveness uses all contributors with evidence in the filtered scope as its peer cohort; selecting fewer developers does not change that baseline. Its common collection cutoff and small-sample limits still apply.

Select a bar or trend series to inspect the developer's PRs for the comparison period. A work-mix segment additionally selects that work type in the evidence table. The drawer shows repository, target branch, AI authoring/review evidence, work type, applied weight, and points. Evidence-only filters narrow that table without changing the summary or trend. Export comparison CSV exports only the selected developers with scope, date bounds, samples, coverage, and work mix; unavailable scores remain blank.

Included eligible repositories are listed below the controls. Projects currently use repository membership: two projects sharing a monorepo include the same work. Paths and labels do not isolate their contributions. Each PR counts once within the comparison, even if mappings overlap. Missing collection or classification can make results partial; no matching collected PRs is not proof of zero activity. Points remain a measure of recorded code output, influenced by work type and the selected target-branch and delivery-candidate scope, rather than a complete measure of individual performance. Review the work mix and PR evidence alongside any comparison.

Productivity score

For each merged PR, points equal (eligible added lines + deleted lines) × work-type weight. The score sums these points. Edited lines already appear as diff additions and deletions; there is no extra updated-lines term.

Work types reuse session-intent names where applicable: Feature development, Bug fix, Refactoring, and Infrastructure change. Additional types are Reliability & security, Maintenance, Documentation, Testing, Engineering enablement, and Unclassified. All weights default to 1× and can be configured from 0× to 5×. Historical assessment labels are mapped to the common vocabulary; novelty is no longer a separate classification axis.

Feature development includes implementation, integration, review remediation, and hardening that completes an evidenced new feature. A standalone repair of established behavior is a bug fix. A fix title or branch and an enhancement label are context, not conclusive classifications. Pure documentation and test-only changes retain their immediate Documentation or Testing type, including when linked to a feature.

The score uses eligible human-authored merged PRs across all target branches of onboarded repositories, including development, release, and hotfix branches. Open and closed-unmerged PRs do not earn delivered-output points. Unknown target branches are included in the all-branch scope. Generated files, vendor directories, and lockfiles are excluded using a versioned path heuristic. Repeated edits in separate PRs count again. Points describe recorded code-change volume and depend on group size and configured weights; they are not a measure of customer value or total engineering effort.

AI or human-reviewed assessments must match the collected PR revision. Without a manual choice, missing or unusable assessments use the Unclassified weight. Missing file statistics remain unavailable. Score coverage separates scored PRs from PRs awaiting usable file data. Classified PRs count known effective work types independently of point scoring. The evidence drawer shows target branches, work-type totals, line counts, applied weights, points, and supporting PRs.

Target branches and repeated delivery

The live Productivity and personal views default to All target branches. Select one or more Target branches to constrain counts, points, AI-assisted share, effectiveness, and trends to the same scope. Select Unknown target branch to inspect legacy PRs without recorded branch information. Branch choices come from the selected period and repository, team, or project scope. The GitHub default branch remains repository metadata; it does not restrict live scoring.

Each distinct PR counts once in a combined result. A feature PR into develop, an integration PR into main, and a backport into release-1.16 are three separate PRs, even if they carry the same changes. Points measure recorded change volume, not unique new lines. There is no automatic deduplication of copied changes.

The supporting PR table labels Possible backport and Possible integration merge candidates using explicit title prefixes such as Backport:, [backport], Cherry-pick , or Merge branch . These hints are uncertain and do not verify ancestry. Exclude delivery candidates lets you intentionally remove either group from live comparisons. Unclassified titles remain included. Branch names and copied code do not themselves establish new AI assistance; each PR retains its own observed or declared evidence.

New evaluated-report repository selections default to all target branches. You can choose up to 100 exact target branches for each repository, including main and maintained release branches together. Existing saved single-branch selections remain exact until an administrator changes them. Published reports retain their captured scope and evidence; new publications show target branches beside supporting PR references.

Existing live scores are recalculated in bounded background batches after upgrading to all-branch scoring. Scores from the previous branch policy show as updating until refreshed. Historical live totals can increase; immutable published reports do not change. Use the same explicit branch and delivery-candidate filters when comparing periods.

Automatic scanning and retained reports

Onboard repositories once under Settings → Productivity → Repositories, then enable Productivity score in Settings → General → Features. All eligible onboarded repositories participate, including repositories added later. The initial scan covers at least 90 days. Merge events update new PRs; incremental collection and daily history reconciliation catch up on missed events.

The summary separates repositories that are actively scanning, queued, or retrying. Needs attention identifies failed or repeatedly failing jobs and repositories paused by access or collection settings. A transient retry alone is not counted as needing attention.

PR counts can appear before productivity file statistics have been collected. When scores are missing, the view explains whether it is waiting for file statistics or complete repository coverage for AI effectiveness comparisons, and links to repository status. Open a repository for its stage, processed and discovered PR counts, last successful collection, request time, retry eligibility time, and error. See resolve collection problems for recovery steps.

Open Settings → Productivity → Repositories and use Sync selected for multiple repositories or Scan now for an individual repository. Select 7, 30, or 90 days, or a custom duration up to 365 days. Jobs keep checkpoints, progress, timestamps, and errors. Retry failed resumes failed collection work and retries eligible failed assessments when automatic assessment is enabled. Assessments remain failed while automation is disabled. Repository access and scope restrictions still apply. Scans also refresh shared PR facts for AI effectiveness and attribution while productivity scoring is disabled; score file collection resumes when scoring is enabled.

When upgrading from customized category multipliers, scoring pauses until an administrator confirms the new work-type weights in Settings. The previous multipliers remain visible, and Feature development requires an explicit choice if its former categories differ. Confirmed weights become the baseline for all history in the new productivity view; published reports are unchanged. Then enable Productivity score in General → Features. Existing default 1× weights carry forward automatically.

Saving weights offers future merges only, recalculation for the last 30 or 90 days, or a custom period. Recalculation uses stored facts without a new GitHub scan or AI request. Future-only changes use the PR merge timestamp, including PRs collected later. Previous results remain visible while recalculation runs. Earlier published reports retain their original rules and evidence; the current workflow does not require previewing or publishing reports.

Understanding contributions

Work-type assessment uses bounded PR descriptions, typed linked-issue context, file paths, and patches to classify the change, with optional human review. Ambiguous changes use the configured AI provider. Assessment budget, retention, historical window, review sample, and provider approval are managed under Settings → Productivity → Assessments. Enabling Productivity score also enables automatic assessment when an AI provider with known pricing is available, using the existing budget or a $10/day default. Otherwise, points can still be calculated with the Unclassified weight while the provider is configured. General Features and score settings show a warning with a direct link to assessment settings when automatic assessment is unavailable, disabled, or waiting for provider approval. If repository onboarding is awaiting activation, the warning links directly to repository setup and migration progress.

Approval covers the selected assessment provider, model, endpoint, authentication protocol, resolved credential, classification rubric, and pricing. A change to any of these inputs requires you to review and save assessment settings again. Editing or reordering unrelated upstreams does not pause classification. During an upgrade, an existing approval carries forward only if it still matches the previously approved configuration. New, unused routing settings do not invalidate an existing approval. The classification worker saves the compatible approval update automatically before processing more PRs. If that update cannot be saved, Settings, Health, and Outcomes continue to show the pause and direct you to review and save assessment settings.

Anthropic assessments use the selected upstream's base URL with /v1/messages. Earlier versions sent these requests to Anthropic's default endpoint even when you selected a custom gateway. Existing approvals for a custom Anthropic gateway require you to review and save assessment settings because honoring that gateway changes the actual destination.

Outcomes and Health → Productivity show why automatic classification is paused, even when the pending queue is empty. A provider approval pause prevents new assessment jobs from entering that queue; zero pending jobs does not mean every PR is classified. Saving assessment settings resumes eligible missing assessments within the configured historical window. Outcomes offers Check classification status without refreshing the displayed analysis. The button shows progress and confirms whether classification is active or still paused; a failed check offers a retry. Analysis results still change only when you refresh them or change the selection. Background synchronization of unchanged PR reviews preserves the displayed result. Review corrections and removals still require a refresh.

Assessment history retains summaries, evidence references, and bounded PR and linked-issue metadata, including titles, labels, branch references, and issue identities. Administrators can inspect that metadata to understand the original decision. It follows the assessment retention configured in Settings: 90 days by default, from 1 to 395 days. Each revision receives its expiry when created; changing the setting does not rewrite existing expiry dates. Raw PR descriptions and patch text are not retained in assessment records. An optional, separately bounded PR evidence cache can retain raw source for reprocessing after administrator opt-in. Cache clearing preserves assessment history. See configure PR evidence caching for retention and refresh controls.

Configurable classification rules are paused by default. Administrators can edit, disable, add, and reorder rules in Settings → Productivity → Productivity score. The first enabled rule whose conditions and safeguards match classifies the work type. Manual classification takes priority. The defaults include three narrow file-based rules and six conventional-title rules for fix, feat, doc/docs, ci, test/tests, and perf. Specific custom rules can precede broader built-in rules.

A match produces a Rule assessed proposal without an AI request or budget reservation. Rules still require complete source and PR context, with an inspectable patch for every changed file. Unmatched PRs follow the existing AI path when enabled, including provider approval, budget, and concurrency checks. Rule changes apply to future classifications; existing assessments retain their rule ID and configuration revision. Significance and novelty remain unknown for rule classifications. See Configure classification rules.

A classification rubric upgrade requires you to save assessment settings to approve the current provider and rubric before automation resumes. Existing current assessments and failed jobs remain in place; the upgrade does not automatically reprocess your historical window. Use bounded retries for selected failures, or replace an individual assessment after inspecting its source.

Automatic assessment prioritizes PRs merged in the last 30 days and rotates between repositories. Four out of five claims prefer recent PRs; the fifth prefers older history in your configured backfill window. Empty groups share their capacity. Two assessments run concurrently by default, sharing capacity with manual analysis. Administrators can configure one to eight in Assessment settings; GitHub request capacity and the AI budget remain independent limits. Ready work continues without a fixed delay between batches. Budget limits, GitHub rate limits, provider approval, and repository scope still apply. Missing file-data recovery queues at most 25 refresh jobs per UTC minute across the shared workspace; worker restarts and replica changes retain that allowance. Recovery targets eligible human PRs merged in the last 90 days across all target branches; the same shared budget applies. Use an explicit scan for older missing file data.

Rejected AI output remains failed until you retry it. When the provider returns reliable token usage with an invalid assessment, the budget uses that usage; interrupted or ambiguous requests retain their reservation. Requests abandoned for more than ten minutes release their analysis slots when the next automatic batch or manual analysis starts; their reserved costs remain charged and failed jobs require an explicit retry. Inspect failures before retrying because another attempt can incur another charge. Health → Productivity lets you filter a retry batch by failure category and choose up to 100 jobs, with a default of 25. Completed assessments are retained. The retry button in Automatic assessments queues at most 25 eligible failures per request.

Development mix shows one stacked bar for each selected entity. The default comparison shows up to six entities with the most merged PRs; select up to twelve. Share uses a common 0–100% scale; PR count uses a common count scale. Colors consistently identify work types. Click a bar segment to inspect that entity's PRs for that work type. Each bar shows its own classification coverage, including manual work-type choices. Human reviewed only still requires an eligible reviewed assessment; a work-type edit alone does not meet that filter. The mix CSV separates classified PRs from PRs with eligible full assessments.

See Review PR contributions and the calculation reference.

Repository scope and discovery

Productivity maintains a repository inventory with three independent concerns: the onboarding decision (Pending review, Onboarded, or Skipped), GitHub access, and collection health. A repository can be Onboarded while waiting for access. Losing access does not erase the administrator's decision.

Onboarding mode	New discoveries	Existing decisions
Manual	No automatic candidates; add or import repositories explicitly	Preserved
Discover and review	Eligible discoveries enter Pending review	Preserved until an administrator acts
Automatic	Eligible discoveries are verified and onboarded	Explicit skips and review holds remain in force

Discovery can use observed gateway sessions, GitHub inventory visible to the configured credentials, or both. Session-only discovery describes observed gateway activity, not company-wide coverage. GitHub inventory includes accessible repositories with no sessions, but its coverage is still limited by installation or token access. Last session activity and last inventory observation are distinct timestamps.

Allowed owners establish a required collection boundary; an empty owner list never means unrestricted access. Include and exclude patterns further narrow it. Scope rules apply to ongoing collection as well as onboarding, so an existing onboarded repository can become Outside scope without changing its decision. Forks and archived repositories are excluded from automatic onboarding by default.

Skip stops future GitHub collection and productivity processing. It survives rediscovery and mode changes, retains historical evidence and published reports, and does not affect ordinary gateway session governance. Restore-to-review sets a hold that Automatic cannot immediately undo. Explicit onboarding or releasing the hold is required before automation can promote it again.

Onboarding adds collection coverage; it does not create project membership or expand evaluated-report scope. Report repository and target-branch selections remain explicit; all branches includes future branches of the selected repositories. A selected repository that becomes skipped, inaccessible, or outside scope remains visible with incomplete-coverage information. Collection gaps are not verified zero activity. Existing installations migrate their known collection scope into Manual mode; new configurations default to Discover and review.

See Manage Productivity Repositories for configuration, bulk actions, and report selection.

Repository productivity and spending reports

Select all eligible repositories in the organization, the canonical repositories configured in one Project, repositories touched by one Team, or a manual set of up to 1,000 repositories. A Project with unresolved or ineligible members must be repaired before its complete scope can be reported. Search and pages only help you choose repositories; they do not limit the scope to the visible page.

Team scope discovers repositories from merged PRs by current primary-team members in the selected timeframe and PR filters. It then includes all contributors to those repositories, including external authors. Secondary memberships and provider name matches do not establish membership. Existing reports keep their discovered set when new PRs arrive; Refresh discovers new matches. Current roster and repository access changes invalidate the affected report.

The overview shows four cards: merged PRs, total productivity points, PR-active contributor identities, and source-labeled attributed estimated spend. Points per active contributor identity appears beside the active count. Contributor labels identify the returned denominator; provider identities do not imply linked people. Missing identity or cost evidence remains unavailable or partial; it does not become zero. Matching-period timeline thumbnails accompany PRs and points, with other thumbnails shown when the selected trend supplies that metric for the report period. The contributor thumbnail shows points per active contributor identity, not a count of contributors. Top contributors by PRs and points follow the cards. Contributor previews use the full selected population and identify ties. Authors with unscored PRs can appear among PR leaders; missing points cannot become point leaders. Bands and percentiles are not assigned. One selected trend and the contributor table follow; work mix, score explanations, investment, rankings, reviews and session evidence open in focused detail. Repository names and PR evidence link to their captured GitHub destinations when the source identity is available.

Output concentration, inside productivity-point details, shows the share of retained points from the largest known contributor total and up to three known contributors. It pools each identity across the selected repositories before ordering. The denominator includes points without an author identity, and the detail shows those gaps and the actual contributor count. Table search and paging do not change the shares. Incomplete scores, named-contributor filters, or a zero point denominator withhold the shares. These are descriptive output shares, not contributor-quality ratings or comparable-repository bands.

A Repository report counts each distinct merged PR in its canonical destination repository. Historical and external authors remain visible. A qualified provider identity can count as an active contributor identity without being a linked native developer. Missing author identity stays in an unassigned output subtotal; it does not become one synthetic contributor. Points per active contributor are unavailable when that identity denominator is incomplete.

Productivity points use stored native scores and their applied versions. Pending or recomputing scores remain distinct from known zero points. Active contributors are identities with observed merged PRs; AI-only actors can appear in the table without entering that denominator. A bucket computes its own contributor count. Adding weekly contributor counts does not produce the period's distinct count.

Repository spending uses exclusive original-request attribution. It examines the full recorded repository support before applying your repository or contributor selection. An original request supported by two repositories stays shared even when you select only one. Shared, unresolved, and unpriced evidence remains separate from accepted exclusive cost. Directory and branch hints do not allocate Observer costs, and a linked session's lifetime cost is not PR spending.

Cost per 1,000 productivity points requires compatible output and cost scope, usable points, and accepted pricing. An observed exclusive subset can support a qualified ratio while population comparisons and rankings remain unavailable. A low spend rank requires accepted usage evidence: missing activity or pricing is not zero spending. Gateway request counts use eligible original requests, including MCP tool activity with no cost event. Only exclusively attributed requests enter the count and AI-active population. Failed or internal requests do not enter that population. Missing or rebuilding evidence leaves the count unavailable; retained partial collection remains disclosed.

Received-review evidence follows the selected merged-PR cohort, including reviews submitted outside the merge period. It is separate from reviews performed by a contributor during the period. Missing human reviews do not become zero waiting time. Ready-to-merge uses a recorded ready observation. PR/session evidence keeps its native many-to-many links and attribution tiers.

Review concentration, inside received-review details, shows the exact number of distinct human review events associated with the top one and up to three known reviewer identities, alongside the full observed human-review count. A reviewer does not need an authored PR or an active application account to appear in this population. Reliable person mappings combine handles; otherwise recorded provider identities remain separate. Missing identities remain in the denominator. Bot, Copilot, unknown-kind, missing-time, and tied-count evidence stays explicit. These counts describe the selected merged-PR cohort, not reviewer effort or quality.

Search and pages do not change complete report totals. A report retains its period, timezone, source, filters, and captured evidence until you refresh. Coverage and unavailable reasons remain visible alongside the values. Repository reports require administrator access. See open a Repository report.

Repository eligibility gates collection; attribution is a join

For an eligible onboarded repository, collection includes every merged pull request in the collected window — from registered developers, unregistered developers, contractors, and bots alike. Attribution to an AI session never gates ingestion. Pending, skipped, inaccessible, or out-of-scope repositories do not contribute new collected activity; retained history can remain in historical views.

This matters for the rollup: you can't credibly report "60% of shipped code is AI-managed" if the other 40% was never counted in the first place. A pull request with no attributable session is still counted — bucketed honestly as manual (or, if the author has no AIControls session at all, as unattributed) rather than silently dropped.

Automated PRs are excluded from the AI-share percentage and efficiency comparisons. The weekly chart includes them in its combined AI series; expand AI breakdown to distinguish automation from self-declared and witnessed work. Rows keyed by a raw, unmatched GitHub login (no AIControls identity behind them) are still shown — tagged unresolved rather than dropped — because hiding them would quietly corrupt the honest-denominator story. An unresolved login has no known developer identity (no confirmed account mapping, SSO match, or admin override), so it can never be assigned to a Team — its PRs always land in "Unassigned" on the Breakdown and Adoption tabs until someone resolves it. Settings → Users → Identity mappings lists every unresolved login and lets an admin map it to a developer or mark it as a bot.

Attribution tiers

A merged pull request can be linked back to the AI session(s) that produced it with varying confidence.

Tier	Signal	Confidence	Status
1 — SHA exact ("witnessed")	The PR's head commit or any commit in its history matches a git commit SHA captured from a Claude Code session	Deterministic	Shipped
Marker ("self-declared")	The PR body, a commit trailer, or the PR's own authorship carries a self-declared AI-tool marker	Self-reported	Shipped
2 — Branch/file match	The PR's branch or changed files match a session's branch/file activity in the right time window	High	Planned
3 — Content similarity	Code the session produced line-matches the PR diff	Medium	Planned
4 — Time + ticket	Session was active around the same time and references the same ticket, with no stronger signal available	Low	Planned

A single PR can carry commits from more than one session — and even from more than one day, if it went through revisions. Attribution is stored as a many-to-many link between PRs and sessions, not a single column, so "what did this PR cost?" has one correct answer even when several sessions contributed to it.

Witnessed vs. self-declared

Both tiers count as AI-managed, but they come from very different places and the dashboard never blends them silently:

• Witnessed means AIControls itself saw the commit come out of a Claude Code session it proxied — the SHA-exact match above. This is the only tier with cost data attached, since cost is tracked per session.
• Self-declared means no proxy-witnessed session was found, but the PR carries a marker one of these tools leaves behind on its own:
  • PR body — a footer like "🤖 Generated with [Claude Code]" or "Generated by OpenAI Codex"
  • Commit trailer — e.g. Co-Authored-By: Claude <noreply@anthropic.com>, or Cursor's/Aider's equivalent
  • PR authorship — the pull request itself was opened by a coding agent's bot identity (GitHub Copilot's coding agent, Devin, Jules)

Precedence: when a PR has both a witnessed session and a marker, witnessed wins for display — a PR is never double-counted, and the headline reads e.g. "41% AI-managed (28% witnessed · 13% self-declared)".

warning

Self-declared markers are exactly that — self-declared. They're a footer or trailer text, not a cryptographic proof: a developer who strips it disappears from this tier, and anyone can paste one into a commit message by hand. That's why marker-based attribution is always reported as a distinct, lower-confidence tier and never merged into "witnessed." Marker-only PRs also carry no cost data — cost aggregation is session-based and doesn't extend to markers.

One specific trap worth knowing about: a Co-authored-by: Copilot commit trailer is not counted as generation. GitHub adds that trailer automatically whenever a developer accepts a Copilot code-review suggestion — it marks code that was reviewed, not code Copilot generated. A fully human-written PR that accepted one review nit would otherwise show up as AI-managed, which would be wrong. Copilot generation is instead detected from PR authorship (the Copilot coding agent's bot identity), not from that trailer.

Match methods

Witnessed vs. self-declared (above) is about how a PR's AI involvement was determined. A separate question — how a GitHub login got tied to an AIControls developer in the first place — is identity resolution, and it's orthogonal: either axis can pair with either PR, e.g. a witnessed PR whose author was resolved via self_service. Resolved logins carry a match_method; unconfirmed suggestions carry a candidate method. The methods are:

• admin_override — an admin set or confirmed the mapping directly.
• self_service — the developer connected their own GitHub account, either from the admin/viewer Connected Accounts page or from the developer-portal dashboard's Integrations tab (see Configure GitHub Delivery Attribution).
• vcs_token — a GitHub token observed at the proxy, confirmed against GitHub's own API.
• sso_lookup — matched via the org's SSO/SAML external identities.
• verified_domain — matched via a member email on the org's verified domain.
• commit_email — a commit email matches a known AIControls user; this creates a suggestion that requires admin confirmation.
• session_linkage — PR sessions trace back to one user; this creates a suggestion that requires admin confirmation.
• noreply_witnessed — the commit author's email is a GitHub-generated noreply address (id+login@users.noreply.github.com); every proxy-witnessed commit under that login traced back to one AIControls user. GitHub's noreply address space belongs to this source alone — it's excluded from commit_email matching entirely, so the two never compete for the same commit.

Precedence: automatic sources (vcs_token, sso_lookup, verified_domain, noreply_witnessed) never overwrite a login that's already resolved. self_service overwrites an automatic match, but not an admin_override. admin_override always wins and is never overwritten by anything else. Legacy GitHub case variants with conflicting owners remain unresolved until an administrator reviews and unlinks the account; no resolver chooses an owner from those conflicting records. See Automatic identity resolution for how each source works and what it requires.

commit_email and session_linkage always record a candidate: a stored suggestion under Settings → Users → Identity mappings. A PR can contain another contributor's commits and sessions, so neither source proves who owns the PR author's GitHub account. Signed commits and an email's presence in gateway audit history do not remove the confirmation requirement. A candidate does not count as resolved or attribute PRs until an administrator confirms it. Unresolved logins can also show a second, unrelated kind of suggestion — always an exact match after normalization (never fuzzy or similarity-scored) — see Suggestions. Open the identity to review either suggestion, then choose Save mapping; confirming records the mapping as an admin_override.

Any mapping, however it was made, can be undone by an admin under Settings → Users → Identity mappings using Unlink identity. Unlinking deletes the mapping — any pending candidate goes with it — and reverts every pull request previously attributed through that login back to unresolved, so the login re-enters the automatic-resolution pipeline from a clean slate.

What gets tracked

For every merged pull request in a configured repository, AIControls records:

• Repository, PR number, title, author, and merge time
• Lines added/removed
• Whether the author is a bot
• Every commit SHA and commit message in the PR (squash and rebase merges rewrite the head SHA, so the full commit list — not just the head — is what witnessed matching checks against)
• The AI session(s) attributed to it, if any, and the attribution tier
• Any self-declared marker found, its tool, and where it was found (PR body, commit trailer, or PR authorship)

Automated PRs

Every merged pull request lands in exactly one of three buckets, checked in this order:

1. Witnessed or self-declared — a linked AI session, or a marker, beats everything else. Any AI evidence at all — witnessed or self-declared — outranks the bot heuristic below, so a bot-authored PR that carries a marker (e.g. GitHub Copilot's coding agent opening the PR itself) is still reported as AI-managed, never as automated.
2. Automated — the author is a bot (Dependabot, Renovate, and similar) and neither of the signals above fired. This is the catch-all for dependency bumps, generated changelogs, and similar bot housekeeping that never touched an AI coding tool.
3. Manual — everything else: no witnessed session and no marker, and not caught by the bot check above. This also covers PRs whose author identity hasn't been resolved to human or bot yet — not just confirmed human authors.

Automated PRs are excluded from the AI-share percentage entirely — both the numerator and the denominator. A repository that merges a hundred Dependabot PRs a month shouldn't see its "AI-managed" number move at all, in either direction; automated work was never a human-vs-AI authorship decision to begin with. The definition of the AI-share % itself is unchanged by this split — it's still (witnessed + self-declared) / (witnessed + self-declared + manual), with automated PRs simply never entering that ratio.

The weekly chart uses a broader grouping for its default overview: AI = automated + self-declared + witnessed, compared with Manual. Choose AI breakdown to show the three constituent categories alongside Manual. Switching detail levels preserves the same weekly totals and filters; it does not reclassify PRs. The AI-share cards and breakdown percentages retain the non-automated denominator described above.

Projects

Project configuration stores stable repository IDs, optional owning-team metadata, and an active or archived status. An owning team does not restrict the authors in the repository set. A repository can belong to more than one project, so overlapping project totals are not additive.

Membership history starts with the state observed when history capture becomes available. The History known from timestamp does not reconstruct earlier membership from the project's creation or last-update date. Later changes record a revision, actor, and time together with the configuration audit. Unresolved legacy references stay visible until an administrator removes or replaces them. Archiving preserves configuration and history and does not stop repository collection.

Project membership is repository-wide. Target-branch selection belongs to the reporting scope and does not change project membership. Overlapping projects may each include the same PR; their totals should not be added together as unique workspace output.

Projects use the repository groups configured in Settings → Projects. Choose new members from the onboarded repository inventory, including repositories without sessions. Project membership does not change onboarding decisions or collection settings. Skipping a repository preserves existing project assignments and history; pending, skipped, and unknown repositories cannot be added as new members. Select one or more projects in the scope bar to filter the cards, weekly chart, breakdowns, pull requests, and adoption details. Multiple selected projects include the union of their repositories; an additional repository or developer filter narrows that work further.

The Project breakdown combines each project's repository totals, with server-side search, sorting, pagination, and CSV export. Exports include every matching row across all pages. Click a project name to inspect its PRs while retaining the date range and other filters. Project membership also appears in the PR table.

A repository may belong to multiple projects. It contributes once to each matching project row, but only once to the page totals. Project rows therefore need not sum to the overall total when projects overlap. Unassigned project contains repositories outside all configured projects. A configured project with no repositories or matching work stays empty.

Project and repository filters do not apply to session linkage coverage: an unlinked session has no PR repository from which to establish project membership. The Coverage tab explains this exception. Identity mapping remains organization-wide.

Project productivity reports

The administrator Project report captures a fixed set of canonical repository identities. Current, prior, and trend periods use that same set. The report shows four cards—productivity points, Gateway requests, five-minute peak sessions and merged PRs—plus independently ordered and paged contributor/repository productivity lists. Four stacked charts use the selected dates, followed by the repository table. Contributor details, output rankings, score/work mix, review/session evidence and membership history open on demand. See View Project Productivity for the workflow.

While AI data is rebuilding, independently valid productivity output remains available. Gateway requests and peak sessions stay unavailable rather than showing zero. The report explains this state; Refresh after recovery captures a new report. Recovery never adds new AI data to an older report.

Points use stored native scores. PR and contributor totals count distinct records across the selected repository union. Average PR points divides the pooled points by scored PRs; it does not average repository averages. Pending PRs remain in PR counts without becoming scored zeroes. Missing person mappings withhold complete-person ratios. Quiet repositories remain in the table, and searching or paging that table does not change Project totals.

The backend retains spending calculations while the Project UI hides costs. Accepted Project spending is the union of accepted exclusive repository allocations. Costs shared by multiple repositories remain excluded even when all those repositories belong to the Project. Overlapping Projects are not additive. Model and provider breakdowns describe the same total and must not be added together. Unknown usage remains unavailable; an observed accepted free request can support a zero estimate. Gateway estimates, Observer estimates, and imported lifetime hints remain separate sources.

Output rankings describe linked contributors with qualified retained output. Ties remain marked; these rankings do not establish an industry benchmark or productivity band.

Review evidence distinguishes reviews received on the selected merged PRs from reviews submitted during the period in the selected repositories. The latter does not inherit PR-author or work-type filters, and historical person filtering is unavailable when the review evidence cannot support it. Missing human review or ready timestamps do not imply zero waiting time. PR/session links describe evidence and do not allocate a session's lifetime cost to each linked PR.

Reports expire and become unavailable when their captured scope or evidence is no longer valid. Refresh to capture a new report. Membership history begins at its disclosed observed baseline; reporting does not invent earlier membership.

Efficiency metrics

Efficiency isn't a single panel — it's a set of outcome comparisons (not just volume) across witnessed, self-declared, and manual work, surfaced in the places on the page where each one is most useful:

• Cycle time and cost per AI PR are stat cards in the top card row, so they're visible without opening a tab.
• Review rounds (median) appears as a column in the Breakdown tab's Team grouping, and as part of the tooltip on individual rows in the Pull requests tab.
• Revert rate and abandon rate are the "quality parity" strip on the Adoption tab.

Metric	What it measures	Compared across
Cycle time (median hours)	Time from PR open to merge	Witnessed · Self-declared · Manual
Review comments (median)	Reviewer comment count on the merged PR	Witnessed · Self-declared · Manual — API only, not surfaced in the UI
Review rounds (median)	1 + count(CHANGES_REQUESTED), or 0 if the PR was never reviewed	Witnessed · Self-declared · Manual
AI-reviewed share	Fraction of merged, human-driven PRs that got at least one Copilot review	Single rate — see AI-reviewed share below
Cost per witnessed PR	Linked AI session cost ÷ number of merged witnessed PRs	Witnessed only
Revert rate	Fraction of merged PRs later reverted	AI (witnessed + self-declared) vs. manual
Abandon rate	Fraction of opened PRs closed without merging	AI vs. manual
Sample sizes	Merged PR counts backing every median above	Witnessed · Self-declared · Manual · Automated

All medians are computed per range and filter selection, exactly like every other number on the page — narrow the scope bar and the medians recompute.

note

Small sample sizes produce misleading medians, so every AI-vs-manual comparison (cycle time, revert rate, abandon rate) checks both sides' sample size before rendering a number. If either side has fewer than 5 merged PRs in scope, the cell shows — with a "not enough data" tooltip instead of a number that would just be noise. Widen the time range or clear a filter to get past this.

Cost per witnessed PR inherits the same limitation as linked cost anywhere else on this page: only witnessed PRs have cost data, because cost is tracked per AI session and only witnessed attribution links back to a session. A self-declared marker PR has no session to charge cost against, so it never appears in this metric's denominator — a self-declared-heavy team's "cost per AI PR" will look artificially cheap if you mentally include those PRs; the metric never does.

note

A revert stamp is one-way: once a PR is marked Reverted, editing its reverting PR's body to remove the "Reverts …" line — or even reverting the revert itself — does not clear the original PR's Reverted mark. Treat it as a durable historical flag, not a live state that tracks the current branch contents.

note

Revert detection only recognizes a same-repo reference: a "Reverts owner/repo#N" line only marks a target PR when owner/repo is the same repository the revert PR itself merged into, matching what GitHub's revert button actually generates. A PR body naming a target in a different repository is ignored.

Revert detection is refreshed during eligible repository collection. Collection runs as resumable per-repository work; rate limits postpone work until provider capacity is available. If a repository is skipped, inaccessible, or outside scope, its historical record is retained but no new revert evidence is collected until eligibility returns. Inspect collection health and use Sync selected from Settings → Productivity → Repositories to request a refresh.

AI-reviewed share

AI-reviewed share answers a different question from everything else on this page: not "did AI write this code?" but "did AI review it?" The two are independent — a fully human-written PR can get an AI review, and a witnessed AI-authored PR can be reviewed only by humans.

The signal is a review from GitHub's Copilot code-review bot (copilot-pull-request-reviewer[bot]) on the PR. Any state of that review — approval, change request, or a comment — counts; the share is the fraction of merged, human-driven PRs (witnessed, self-declared, and manual — automated PRs are excluded, same as everywhere else) that got at least one such review.

warning

Don't confuse this with the Co-authored-by: Copilot commit trailer covered above — that trailer is generation-adjacent authorship noise, not review data. AI-reviewed share only counts an actual review event from the Copilot reviewer bot; it has nothing to do with who wrote the code being reviewed.

Teams

The Team grouping (in the Breakdown tab's group-by toggle, and the Adoption tab's team table) rolls PRs up by the developer's team in AIControls — the same team assignment used for cost and policy attribution elsewhere in the product, sourced from each user's teams field, not anything read from GitHub.

A developer whose AIControls user account has no team assigned — or whose PR author identity has no linked AIControls user at all — is bucketed under Unassigned rather than dropped. Unassigned always sorts last in the team table, and it isn't a real team: there's no team ID behind it, and it can't be picked as a filter value, only observed as a rollup bucket.

Team assignment is one-to-one: a user belongs to exactly one team at a time (AIControls enforces this invariant when teams are managed), so a PR's author contributes to exactly one row of the team rollup, never split across two.

Linkage coverage

Linkage coverage is a descriptive metric, not a compliance score: of the AI sessions your developers ran, what fraction ended up linked to a merged PR? A low number doesn't necessarily mean waste — a session might have been exploratory, feed into a PR that hasn't merged yet, or produce a change too small to be its own PR. Read it alongside PR volume, not as a standalone "efficiency" figure. Coverage is scoped by developer, not by repository — a session belongs to the developer who ran it, not to any one repo.

Reporting identity mappings

Settings → Users → Identity mappings is the central place to associate GitHub authors with gateway users. The Users table shows each user's external identities, including multiple GitHub accounts. Unmapped accounts and bots can be reviewed separately. Identity mappings apply organization-wide rather than following a report's date, team, or project filters.

Productivity reports link unresolved authors to their mapping in Settings. Changing a mapping updates existing PR attribution and refreshes live report data; it does not rewrite an already published report. Original GitHub logins remain part of the PR evidence. Mapping an identity does not change its authentication or access permissions. See Map GitHub accounts to gateway users for the administrator workflow.

Page anatomy

The AI attribution view within Productivity ▸ Outcomes retains one shared scope for its PR-based cards, chart, and tables. Its default is trailing 12 weeks when no explicit dates are provided; dates carried from Overview remain selected. Leaderboards has its own weekly scope.

• Scope bar — a time-range picker (presets: 4 weeks, 12 weeks, this quarter, last quarter, or a custom range; default is trailing 12 weeks) plus project, repository, and developer multi-select filters and a team selector. PR-based cards, charts, and tables recompute under the same scope. Coverage retains its developer/time scope and identity mapping remains organization-wide. Active filters render as removable chips, and the full scope — time range, projects, repos, developers, active tab, chart detail — is encoded in the URL, so a filtered view is shareable as a link (a Slack message, a QBR deck) and restores exactly on load.

• Four stat cards — AI share of merged PRs (with a witnessed/self-declared/manual/automated subline), AI share of merged lines of code, cost per AI PR (witnessed only, with an inline weekly trend sparkline showing which way it's moving — directional only, not gated by the n<5 sample-size check since it isn't a point-in-time comparison), and cycle time (AI vs. manual, hidden behind the n<5 honesty check like every other comparison on the page).

• Weekly trend chart — defaults to two stacked series, AI and Manual. AI combines automated, self-declared, and witnessed PRs. Use AI breakdown to reveal those three categories alongside Manual, and Overview to collapse them again. The control is saved in the URL. Clicking a segment focuses the selected filters on that week, Monday through Sunday; choose a wider date range to zoom back out.

• Breakdown / Pull requests / Coverage / Adoption / Identities tabs:

  • Breakdown — one table, toggled between grouping by project, repository, developer, or team, with the AI-managed percentage, and the witnessed/self-declared split, per row. An Export CSV button downloads whichever grouping is currently active (project, repository, developer, or team) as a CSV file scoped to the current filters.
  • Pull requests — the full ingested PR list, searchable, with project membership and an "AI evidence" column (e.g. "Claude Code · witnessed (2 sessions)" or "Cursor · self-declared"), a Reverted tag on rows that were later reverted, a dedicated Reviews column showing the review-round count and a Copilot tag (showing "Copilot ×N" when Copilot reviewed more than once — it commonly re-reviews after every push, and each submission counts separately from review rounds), and filters for repo and evidence kind.
  • Coverage — the session-to-PR linkage view described above. Project and repository filters do not apply here; the table uses the selected developers and time range.
  • Adoption — AI-reviewed share, a per-team adoption table (weekly AI-vs-total sparkline plus member breakdown), a "not yet using AI" list of developers with zero AI-assisted merged PRs in scope, and the quality-parity revert/abandon rate comparison from the efficiency metrics above. Admin and viewer accounts are excluded from the "not yet using AI" list even when mapped to a team — they're typically managers or read-only accounts, not developers — though one who genuinely authored a merged PR still appears with real numbers. When a project or repository is selected, only contributors with merged work in that scope enter the adoption list. An Export CSV button downloads every team's member rows (AI PRs, total PRs, AI share, last AI PR date) as raw numeric values, not pre-formatted percentages or strings.
  • Identities — links to the organization-wide mapping configuration in Settings → Users → Identity mappings. Mapping and unlinking are managed there rather than inside the report.

• Drill-down clicks — in Project, Repository, Developer, and Team breakdowns, each metric opens its matching merged PRs: AI % opens AI-assisted PRs, Manual PRs opens manual PRs, and Witnessed or Self-declared opens that category. The two LOC values are separate links to AI or manual PRs. Clicking the entity name opens all of its merged PRs. The date range and filters in other dimensions are preserved; clicking a row within a dimension narrows that selection to the row. Active filters appear above the PR list and can be changed or removed. Counts and pagination cover the complete matching result. Back to breakdown restores the original scope, grouping, search, sort, and page; the browser Back button also returns to the preceding view.

  Open a PR row to inspect its declared AI marker, linked sessions, and recorded AI reviews. Manual means no AI authoring evidence was detected, not proof that AI was never used. A PR with a recorded Copilot review but no authoring marker or linked session still belongs to the Manual authoring category.

Every CSV export follows RFC 4180 quoting and is safe to open directly in Excel or Sheets: any text field that would otherwise be read as a spreadsheet formula (starting with =, +, -, or @) is escaped so it opens as plain text instead of executing.

See also

• Configure GitHub Delivery Attribution — set up the integration
• Adoption Analytics — a different, session-based adoption view (Active Users, Adoption Rate, New Adopters, Churned) on the standalone Adoption page, not to be confused with this page's PR-based Adoption tab

Repository agent readiness

Agent readiness measures the repository context available to coding agents. It has its own configuration and collection history. It does not change productivity points, AI effectiveness, rankings, or published reports.

The five default criteria cover agent instructions (30), project purpose (10), architecture context (20), setup guidance (20), and validation guidance (20). Administrators can change weights, file paths, repository selectors, and optional text patterns. Each criterion awards its weight once, even when several files match. The score is the percentage of applicable weight earned, from 0 to 100. Disabled rules and rules for other repositories do not contribute to that repository's denominator.

A complete score of zero means the scan found no qualifying evidence. An incomplete scan has no score: missing access, unsupported content, or an exhausted collection limit cannot establish that documentation is absent. Historical results retain their original rules and dates after configuration changes.

Collection is disabled by default and requires administrator enablement, repository onboarding, allowed-owner scope, verified GitHub.com identity, and GitHub Contents read access. It reads the default branch at a pinned commit. Only configured candidate files and their permitted in-repository symlink targets are fetched. Repository content is treated as data; no code runs and no LLM reviews it. Stored evidence contains paths, commit/blob identifiers, and check results, without source bodies or snippets.

These checks establish structural preparation signals. They do not establish that instructions are accurate, that an agent loaded them, or that the repository will yield higher productivity. Comparing productivity with readiness is a separate analysis.

Scans refresh daily when capacity and provider limits permit. A result becomes stale after 24 hours or a relevant configuration, identity, or branch change. Two scan slots are shared across the deployment, and PR collection takes precedence. Large inventories can remain overdue. Manual refresh uses the same queue and limits. Disabling collection preserves the 365-day assessment history.

See Repository collection troubleshooting for readiness-specific limits and recovery.

Shared Investment detail contracts distinguish native requests per PR, estimated cost per PR, points per estimated dollar, cost attributable to active contributors per active contributor, and the share of active contributors with qualified AI activity. Each product supplies compatible pooled facts and eligibility rules. Unknown or zero denominators stay unavailable; sources are never combined. Points per estimated dollar is a descriptive ratio, not a billing, ROI or causal claim.

A report based on discovered repositories keeps its captured repository set when new PRs arrive, including backdated PRs. Refresh discovers new matches. Current membership, eligibility, and access changes still invalidate affected reports.

Shared aggregate reporting semantics

Team productivity and spending

The Team productivity API reference describes report requests, retained roots, and signed evidence pages.

The Team overview describes the activity of current primary members over the selected period. It preserves the whole roster, including quiet, AI-only and review-only members. Active contributors are distinct members with merged PRs; authors awaiting a score still count. Points per active contributor divides the pooled stored points by that active count, rather than averaging member scores. The roster count provides context and is not the denominator of that measure.

Four compact cards show the selected period's cumulative productivity points, Gateway requests, peak concurrent sessions, and merged PRs, each with its own selected-period trend thumbnail. The session value is the largest observed five-minute active-session union, a proxy for concurrency; peaks are not added. The overview uses Gateway activity and all PR work types. Its reporting period comes from the scope bar; there is no separate source, work-type or trend-period selector. PR scope filters affect delivery metrics only, because requests are not classified by PR work type.

Beside the cards, four … by developer panels show recorded values for the full roster. Each panel has a metric selector for Productivity points, Gateway requests, Peak concurrent sessions, or Merged PRs, with independent Highest first / Lowest first controls and ten-member pages. Ordering covers all members before pagination; missing evidence stays unknown. These descriptive charts do not assign personal performance bands. Qualified Output and Spending rankings remain available in detail. Points/person, active contributors, and roster size appear together beneath the overview. Select a user name or bar to open the global Developer view in a new tab, with that trusted roster identity and the same reporting dates. The original Team view stays open with its chart positions. Compatible PR filters and a return link are preserved; the Developer view authorizes and refreshes its own evidence.

Sorting and paging retain the captured report. Refresh explicitly captures new evidence. Four full-width charts stack productivity points, merged PRs, Gateway requests, and peak concurrent sessions over the same dates and timezone. Each has its own units, interval evidence and expanded view. Comparing their changes can reveal associations; it does not establish that more AI activity caused higher productivity. Missing evidence remains a gap.

Highlights appear as each finishes, so a slower chart does not delay the others. For a small team, a matching complete report supplies the productivity highlight without loading the same evidence again. Larger teams keep independent chart pagination.

If one overview highlight temporarily fails, other successful cards, member charts, time series, and the roster stay visible. Retry failed highlights loads only missing highlights from the same captured report. Refresh starts a new capture. Access loss, expired evidence, or a changed report basis removes the protected report instead of retaining its highlights.

Start with the team's own history. Team peer standing uses a separate proposed policy: at least 20 eligible Teams, with each qualifying Team having at least three active contributors, five fully scored merged PRs and seven completed days. Incomplete collection or identity evidence suppresses a percentile and band. The peer list explains exclusions. These Team rules do not change Developer bands.

Output and Spending detail preserve highest and lowest qualified member lists. The main roster table is descriptive and assigns no individual band. Team cost includes supported activity from the full roster; cost per active contributor uses only the PR-active members' cost. A missing price is not a free event. Gateway recorded estimates and Observer current-rate estimates remain separate, and neither establishes an invoice or a causal productivity benefit.

Gateway requests count each successful native logical request once, including requests with multiple pool attempts. Costs retain the supported costs of those attempts. Team peak sessions use the shared five-minute session union across members; adding individual peaks does not produce the Team peak.

Team source reads use the captured roster across the selected, prior, and trend periods. Activity from other teams does not consume the selected team's event limit. The report does not measure source-wide unattributed costs or requests; those totals remain unavailable. Observed member totals stay visible, while cost ratios and participation percentages that require complete identity evidence remain unavailable.

Source participation has a separate qualification gate from spending ratios and PR scoring. A percentage requires complete selected-source collection without gaps or a rebuild, complete traversal of the captured roster, and trusted person bindings for every in-scope candidate. The PR-active row also requires complete merged-PR collection and author mapping. Missing prices or pending PR scores do not, by themselves, suppress participation. Source-wide unattributed totals stay unavailable and do not substitute for this selected-roster proof.

Source participation distinguishes activity across the whole Team from activity among PR-active contributors. The whole-Team denominator includes quiet, AI-only, and review-only members. Both rows retain their observed participant counts and denominators when incomplete evidence prevents a percentage. An empty roster has no percentage; a fully qualified roster with no observed activity has zero participation.

Organization outcomes and scoped comparisons

Productivity → Outcomes provides Overview, Compare, and Evidence for the organization and its teams, projects, repositories, and developers. The default reporting period is the last seven complete days in your saved reporting timezone. The scope, entity, reporting-period, and timezone controls share an aligned row with matching heights. The scope selector no longer includes a PR filter button. If a restored report contains PR filters, you can clear them from its active-filter notice. Developer Overview retains its PR filter controls. When you choose another scope type, the current report stays applied until you select an entity.

Organization Overview pairs four aggregate cards—productivity points, Gateway requests, five-minute peak sessions, and merged PRs—with four Top 5 rankings for developers, projects, teams, and repositories in a 2×2 grid. The metric selector beside the navigation tabs controls all four rankings. KPI cards show percentage changes only when a comparable previous period is available. Evidence details remain available through the information icons, ranking-value tooltips, and data coverage section. Overview and ranking values appear without asterisk markers. The aggregate cards use independently calculated organization values; rankings do not partition the organization, and their totals may overlap. Overview metric cards share the organization design across Team, Project, Repository, and Developer scopes: an icon, metric value, and available timeline preview. Partial-coverage explanations stay in information tooltips and evidence details rather than appearing as card badges or repeated helper text. Developer productivity points appear in their own card, separate from band and percentile. The card's information tooltip retains PR scoring and classification progress.

Use the two-arrow expand icon on time-series charts and metric previews to inspect a larger chart. Compare, head-to-head, work-type, and Developer timelines use the same icon; expansion retains the selected data and interval inspection. Four time series retain the selected dates and distinguish missing evidence from observed values. A five-minute peak counts distinct trusted account/session identities in each original five-minute window, then takes the maximum for the selected interval. Daily peaks are never added together.

Organization totals and rankings can finish independently. If a ranking fails, use its Retry button. Project and Repository reports retain the same current, prior, and trend periods when sharing their underlying output reads.

Compare stays inside the selected scope: Team compares its developers, Project compares its configured repositories, and Repository compares developers' output in that repository. Developer comparisons use only that developer's PR output across repositories or projects. At organization level, choose any supported entity kind. Comparisons involving repository or project contribution scopes show PR-derived measures and omit person-level session and request telemetry that cannot be uniquely attributed. Team and Project overview reports retain their existing presentation and evidence rules.

See Explore engineering outcomes for scope selection, comparison controls, timezone search, and evidence drilldowns.

Common report behavior

The shared reporting foundation supplies common semantics for Team, Repository, Project, and Organization reports. Each product enables its own views and release scope; this foundation does not add a new navigation destination.

The default aggregate overview shows four headline measures—productivity points, merged PRs, active contributors, and a named source of estimated spending—plus one selected trend and one primary table. Points per active contributor accompanies the contributor measure. Score explanation, investment, review evidence, session evidence, and full rankings are loaded when requested.

A report keeps its reporting timezone, civil dates, source, filters, and captured population together. Sorting, search, paging, and detail use the accepted capture. Explicit Refresh creates a new capture. Access revocation clears protected results, and a missing root or invalid scope clears the affected root. Stale or expired context keeps the accepted report visible and read-only until you select Refresh. An ordinary temporary read error can retain the last coherent result while offering a retry.

Opening a recorded session does not add a gateway request or spending to its team report. System events, such as session replay views, stay outside these member activity and spending totals.

If a view cannot load, refresh the page to try again. If it takes too long, try a shorter reporting period. If the error continues, contact your administrator with the selected team, project, repository, or developer and reporting period.

Background AI activity repair progress alone does not invalidate your report. Activity metrics remain unavailable during a correction. A new evidence correction, an access change, or completed repair can require a refresh.

Gateway recorded estimates and Observer estimates at current rates are separate sources. Unknown pricing, incomplete identity mapping, and missing collection remain explicit; they are not zero spending or zero activity. Provider handles are retained as evidence without becoming verified people or granting Developer access. Complete-person averages remain unavailable when any included author cannot be mapped to a proven person. Reports that count safe contributor identities instead label that measure Active contributor identities and pair it with Points per active contributor identity. An external provider account is an identity; this measure does not claim that every account is a distinct person.

Native productivity scores retain their stored weights, versions, and exclusions. Reviews performed during the interval differ from reviews received on the selected merged-PR cohort. Team performed evidence counts submitted review events and distinct reviewed PRs across the retained eligible repository catalog, including open PRs and PRs authored outside the Team. PR-output filters do not narrow this reviewer cohort. The full Team roster remains visible, including members with zero observed attributed reviews.

Named counts cover only current confirmed public GitHub OAuth reviewers with matching active account, email claim and self-service mapping history. Events before the latest qualifying confirmation are not backfilled. Historical or reassigned ownership, other hosts, administrator overrides and unsupported identities remain unresolved; account or mapping changes can revoke retained evidence. Review collection completeness is unavailable, so zero observed reviews does not prove that no reviews were performed. Repository-wide source diagnostics are shown separately and are not attributed to Team members. Performed evidence does not add productivity points or authored PR output.

A session linked to several PRs does not multiply its expense, and five-minute peak session activity is an activity proxy rather than measured concurrency or hours worked. Report evidence does not establish invoices, saved labor, ROI, or causation.

Shared report tables can show a repository's share of selected PRs and points, plus its change from the selected previous period. A zero or unknown denominator does not become a zero share. When the previous value is zero, the report can show the absolute change without inventing a percentage. On-demand evidence tables can open the exact retained PR explanation and return to the same report. Eligible highest/lowest views remain separate from all observed contributors.

Each report offers the trend choices relevant to that view. Additional table metrics can remain available without appearing in the trend selector. Detail tables show sort controls only for columns the report supports sorting.

Focused evidence can offer section-specific modes, such as pull requests and work mix, or attribution, models and providers. Changing mode keeps the same report and starts a new detail page. Ranking previews show the highest and lowest three qualified entries together. A cohort with fewer than six entries appears once in one ordered list. Ties and excluded-population counts remain visible; View all opens the full retained table. These controls stay inside focused detail.

Rows can disclose provider-only identity, PR-only or AI-only activity beneath the name. When trusted mappings are available, evidence can link to the native Developer, PR or session destination. Missing mappings remain unlinked; opening a link does not grant access to its destination.

Shared aggregate reports keep a bounded overview and a paged population table. A product can present stacked timelines instead of a selected trend. Detail modes stay in the page link and survive Refresh. Pending and failed evidence are labeled separately from observed zero; partial ratios and subtotals retain their evidence labels. Trend interval data exposes each interval's status. Optional investment and table metrics appear in their relevant details unless a product explicitly offers them as a trend choice.

Shared Investment detail contracts distinguish native requests per PR, estimated cost per PR, points per estimated dollar, cost attributable to active contributors per active contributor, and the share of active contributors with qualified AI activity. Each product supplies compatible pooled facts and eligibility rules. Unknown or zero denominators stay unavailable; sources are never combined. Points per estimated dollar is a descriptive ratio, not a billing, ROI or causal claim.

A report based on discovered repositories keeps its captured repository set when new PRs arrive, including backdated PRs. Refresh discovers new matches. Current membership, eligibility, and access changes still invalidate affected reports.

A product can focus its overview on fewer summary measures while keeping the shared report controls, primary table, and on-demand details. Repository links in a report title use confirmed destinations from the captured report and disappear when report access is lost.

AI ROI scenarios

Administrators can open Productivity → AI ROI to compare company output with an industry, open source, or company baseline. Use the AI ROI tab for reports and the Baselines tab to browse the baseline library. Both tabs require administrator access and persistent product storage (storage.enabled: true). Stateless deployments do not expose the workspace. If the workspace is unavailable, the page reports that AI ROI is not enabled in this instance.

Open and revisit a report

AI ROI prepares company evidence in the background after an administrator signs in. The report layout opens immediately. If preparation is still running, cards and charts show loading placeholders with an inline preparation status. Prepared evidence and your current report settings remain available when you leave and return during the same signed-in browser session. When you return, evidence older than five minutes or from the previous Pacific date refreshes; the previous report remains visible during the update. If a background refresh fails, the report shows the failure and offers Retry while retaining the previous evidence. Last prepared shows the evidence timestamp. Signing out or switching accounts clears this cache. Use Save defaults for me to retain settings across sign-ins.

Reporting periods use Pacific time and contain completed measures only:

Reporting period	Chart interval
Last 7 complete days	Daily, through yesterday
Last complete week	Daily, Monday–Sunday of the previous week
Last 30 complete days	Daily, through yesterday
Last 4 complete weeks	Weekly, through the previous completed week
Last 3 complete months	Weekly, 12–13 points within the previous three calendar months
Last 6 complete months	Monthly, through the previous completed month
Last 12 complete months	Monthly, through the previous completed month

Weekly charts exclude partial weeks at both boundaries. Hover over a point to see its exact date range. The headline covers the entire selected reporting period, including boundary dates excluded from weekly charts. Headline effort counts weekdays, prorated from the annual net working-day allowance and development allocation. Daily charts distribute that existing effort evenly across calendar dates, including weekends. Contribution-based comparisons distribute each selected contributor’s assumed time across their first-to-last PR window. This preserves the headline’s total assumed effort and includes weekend output at both ends of the series. A date outside all selected contribution windows still has no capacity estimate; confirmed zero output with assumed effort has a capacity multiplier of zero. Saved one-day selections use the seven-day view. Periods outside the available evidence are disabled. Large captures retain the existing 50,000-PR limit and may offer fewer reporting periods.

Create a baseline

Choose an Open source or Organization baseline from the library. Organization baselines reuse verified tenant PR history. If the selected period has missing history or LOC, choose Collect missing GitHub history. Collection runs in the background with progress and resumable checkpoints; only missing intervals are requested. Modeling and saving remain unavailable until coverage is verified. The default 90-day collection lookback is not a boundary for historical baselines: use Calendar year to select an earlier year, such as 2024 or 2025. Choose the whole organization or teams, projects, or users, then include all members or select specific members. Team and project scopes also support exclusions: projects, repositories, and users for teams; repositories and users for projects. Exclusions remove matching PRs and whole attributed sessions. Team membership and project repository assignments reflect the current directory. Organization and project scopes include historical PR authors, including former employees; team and user scopes use current directory membership. Contributor counts describe observed PR authors, not historical employee headcount. Assumed contribution windows and full-period developer-months do not establish employment dates or include employees with no observed PRs.

Choose a reporting period and timezone, inspect the evidence, then adjust the contributor cohort, output measure, additions cap, assumed effort, and financial assumptions. Summary cards show daily trends across the full period. Expand a contributor card to see its chart and a searchable table of usernames, PRs, added LOC, and capped LOC. When only some PRs have LOC evidence, cards and user tables show recorded subtotals marked as partial, alongside the number of PRs covered. LOC charts show these daily subtotals with hollow points for partial coverage; days with no LOC evidence remain gaps. Days without PRs are zero. LOC-based output rates and rankings require complete LOC evidence; partial subtotals are not used to estimate missing output.

Reporting dates include the year in both the picker and confirmation. Previous month selects the complete preceding calendar month in the reporting timezone. If a period has no merged PRs, check the selected year, dates, and scope.

AI spend can be Unknown, an Estimate per developer / month, or, for organization baselines, Recorded Gateway session estimates. Unknown spend does not prevent saving productivity metrics. An explicit monthly value of 0 means an assumed zero cost; an empty value remains unknown.

Both baseline types accept USD per developer per month. The estimate uses the selected contributor count multiplied by calendar months and the monthly amount. A complete calendar year is 12 months; partial months are prorated by the number of calendar days in that month. Older saved evidence retains its original calendar-days-divided-by-30.4375 calculation; effort allocation does not reduce this cost. Organization baselines can instead use lifetime spend estimates for sessions created during the selected period and matched to the selected contributors. Those estimates are captured subtotals, not complete company spend or daily billing records. Periods outside configured session retention display a coverage notice. Missing days remain gaps rather than measured zero. A monthly estimate applies to the whole period and replaces recorded spend; the two sources are not combined or automatically extrapolated. Sessions with missing or ambiguous repository attribution are omitted when they cannot be assigned to the selected scope or exclusions. Save the evidence and assumptions together; editing a saved baseline creates a new version. Reopening saved evidence does not collect new GitHub data. Refresh data explicitly recollects the selected period; save the result as a new version. Coverage, collection date, scope, and metric definitions remain attached to saved evidence.

Compare scenarios

The AI ROI page opens its report layout immediately and fills in results as company evidence loads. Shipped settings use the last 7 complete days in Pacific time, observed human contributors, all repositories, $100,000 annual salary, 225 working days per year, and an estimated $1,000 AI cost per developer per month. The default reference is Pragmatic Engineer · Amazon, with a daily rate of 280 LOC. Industry comparisons use uncapped added LOC for capacity and financial metrics. The Amazon source reports changed lines in an individual retrospective; its published scope and limitations remain available with the reference.

Edit assumptions expands Global parameters, My company assumptions, and Baseline assumptions on the same report. Changes recalculate the report without a separate generation step. A saved baseline retains its own source period. Baseline overrides change this report without modifying that saved version. Comparison at a glance highlights differences using the calculated contributor counts.

Administrators can save the current settings, baseline, and filters as personal or tenant defaults. Personal defaults override tenant defaults, which override the shipped settings. Defaults are shared across browser sessions and server replicas. Monthly AI costs are scenario estimates rather than measured spending. You can choose estimates for all developers, Gateway data only, or Gateway costs with estimates for developers whose Gateway costs are missing or incomplete. The combined mode is available for live company evidence, including comparisons against saved baselines. Legacy research captures retain their original cost modes. In the combined mode, a developer with observed, fully priced and verified Gateway activity uses their recorded costs. Otherwise, the monthly estimate replaces that developer's entire period cost, including any partial recorded cost, so it is counted once. Known-free Gateway requests count as valid evidence. The report shows the Gateway and estimated amounts and contributor counts separately. Its daily, weekly, or monthly chart keeps each developer's cost source fixed across the selected reporting period. Estimates use the same calendar-day proration and contributor windows as the estimate-only mode. Source selection uses the full report period, even for requests outside a contributor's PR window; only the costs allocated to that window enter cohort comparisons. Industry hybrid spend uses the retained developer identities. Editing scenario headcount changes capacity and salary assumptions, not the identities included in hybrid spend. When collection covers a shorter period, the report uses that available timeframe for both output and financial calculations, including after restoring defaults. Empty evidence and zero denominators remain unavailable rather than producing invented results.

The report pairs two large-number metric cards on the left with their capacity trends on the right. The capacity card shows the multiplier and added FTEs relative to the baseline; the spending card maps $1,000/month of AI spend to modeled added FTEs. Blue identifies capacity; green identifies spend-normalized capacity, with lightly tinted cards, identifying icons, and shaded chart areas. Each card explains how to read its number. The capacity explanation relates output per assumed full-time developer to the baseline and translates the difference into additional or fewer full-time developers for your selected team. Use each card’s information button for its definition or its expand button for a larger view with bigger text and icons that retains the card’s blue or green tint. An output chart follows these rows. Charts show daily values for day-based periods, weekly values for the 4-week and 3-month periods, and monthly values for the 6- and 12-month periods. Intervals without assumed developer working time have no capacity estimate, including days outside selected contributors’ activity windows. If no intervals have assumed working time, compact and expanded charts explain why no capacity estimate is available. Each capacity chart offers an optional comparison metric with its own axis. Hover over a point for its value, expand a chart for a larger view, or expand Accessible trend values for exact numbers.

• Estimated capacity multiplier compares observed output with expected output under the selected reference and assumed development time. Added FTEs describe modeled capacity above that reference.
• AI spend → capacity expresses added FTEs per $1,000/month of included AI spend. Current monthly spending is the selected period's included spending multiplied by 30.4375 and divided by its calendar days. For example, six added FTEs at $5,000/month correspond to 1.2 added FTEs per $1,000/month.

Daily, weekly, and monthly spending use the same average-month conversion; interval FTEs use each interval's average capacity. The headline pools the selected period's evidence, so do not average or sum interval ratios. Missing spending and zero-spend ratios remain unavailable. Negative capacity remains visible.

These are baseline-dependent scenarios, not measured time saved, actual hires, cash savings, or proof of AI impact. The spending ratio describes observed modeled efficiency; it does not predict the return from spending another $1,000/month. When you choose Gateway data only, live company views use recorded Gateway cost estimates from the current tenant. Costs follow the selected developers across all repositories; selecting a repository does not allocate a request's cost to that repository. Explicit product identity mappings combine GitHub aliases without multiplying cost. Unmapped accounts and requests outside the captured tenant remain excluded. This view does not combine production and staging costs or include unobserved AI subscriptions.

Choose Estimates for all developers under My company assumptions → AI cost basis. Enter a monthly USD amount (zero is allowed). The report uses this assumption instead of Gateway costs; it does not add the two together. Industry comparisons multiply the rate by the scenario headcount over the full period. Contributor-based comparisons use the selected people within their first-to-last PR windows. Development-time allocation does not reduce the cost per person. Both prorate calendar days using the same 365.25/12-day average month as the monthly KPI. Cards, weekly tables and scenario exports identify this as an estimate. Weekly spending uses a constant assumed rate, so its changes reflect the selected people and their contribution windows, not measured changes in model usage or pricing. The estimate carries across baseline selections within this page.

The following strict coverage requirements apply in Gateway data only mode. For a period or week to have a spending ratio, every selected contributor must have observed requests with accepted pricing evidence in that interval. Unpriced requests or missing developer evidence make the ratio unavailable. A recorded free request can support zero estimated spending; absence of requests cannot. Zero spending still has no defined capacity-per-dollar ratio. Historical and saved-baseline comparisons also restrict costs to each contributor's PR window.

Live company views identify incomplete PR metadata separately from cost coverage. Retained session spending and live report generation remain unavailable. Saved research captures retain their original cost sources and report workflow.

Compact summaries and expandable rankings

Summary cards place the value beside its timeline thumbnail, with comparison text in its own space. You can expand a thumbnail or ranking card for a larger view. The Team overview shows four fixed developer rankings: productivity points, Gateway requests, peak concurrent sessions, and merged PRs. Use the sort control beside each title to show the highest or lowest values first.

In Developer Outcomes and the Builder portal, Compare with others also lets you select merged PRs, Gateway requests, or peak concurrent sessions. Ranking and pagination use the selected metric across the eligible comparison group. PR filters apply to merged PRs; Gateway activity uses the full reporting period. Peak concurrent sessions uses each developer's maximum five-minute count; peaks are never added. Missing activity remains unavailable. Existing name privacy and administrator comparison policies still apply. Productivity bands and percentiles continue to describe productivity points.

Project PR evidence displays the captured author's name or provider login. Select a linked PR title to open its source PR on GitHub.

Organization rankings also provide independent sort and Previous/Next controls. Each card shows five entries; expand it to browse ten entries at a time.