---
title: "Allocation"
canonical_url: "https://docs.getdx.com/reports/allocation/"
md_url: "https://docs.getdx.com/reports/allocation.md"
last_updated: "2026-06-18"
---

# Allocation
The Allocation report uses AI-powered classification and weighting of pull requests to break down how engineering effort is being spent across Features, Maintenance, Fixes, and Other. Instead of relying on self-reported survey answers, it uses system data from your code host to estimate where engineering effort is going.

## When to use the Allocation report

DX Snapshots ask engineers to self-report how they split their time between **New capabilities** and **KTLO and maintenance**. The Allocation report provides a system-based view of the same concept, using PR data instead of survey answers:

- Use it to understand what percentage of delivered work is Feature vs Maintenance vs Fixes, at the team or org level.
- Use the time series to see how Allocation is shifting over time in response to initiatives or changes in priorities.

## How categorization works

### 1. Categories

Each merged pull request is categorized into one of the following groups:

| **Category** | **Description**                                                                                            |
| ------------ | ---------------------------------------------------------------------------------------------------------- |
| Features     | Work that introduces new capabilities, product enhancements, or user-facing changes.                       |
| Maintenance  | Work that maintains existing systems, such as security upgrades, tech debt, refactoring, or documentation. |
| Fixes        | Work that addresses bugs, production issues, or incidents.                                                 |
| Other        | PRs with insufficient or ambiguous information to be confidently classified.                               |

These categories align with those used in self-reported allocation data collected in DX Snapshots, where work is broadly grouped into _New capabilities_ and _KTLO and maintenance_. In the Allocation report, KTLO/maintenance work is further divided into **Maintenance** and **Fixes** to provide more granularity.

### 2. Rule-based heuristics

If a pull request's **title** or **branch name** starts with certain keywords, DX will auto-categorize it using simple, transparent rules:

- **Features**: title or branch starts with `"feature"` or `"feat"`
- **Maintenance**: title or branch starts with `"maintenance"`, `"maint"`, `"chore"`, `"refactor"`, or `"docs"`
- **Fixes**: title or branch starts with `"fix"`, `"bug"`, `"bugfix"`, or `"hotfix"`

> Note: In the case of a conflict, the category based on the pull request's title will be prioritized.

These rules provide a strong, interpretable signal when teams have consistent naming conventions.

### 3. AI classification

If **no keyword rule applies**, DX AI classifies the PR based on its content. The model considers signals such as:

- The **branch name** and **PR description**
- Linked ticket metadata (when available), including:
  - Ticket title or summary
  - Labels
  - Type (e.g., for Jira `Task`, `Bug`, etc.)
  - Custom field values (e.g., for Jira `category` or `type`)
- Structural characteristics of the PR (e.g., size of the diff)

The output is one of the four categories above, stored as `Feature`, `Maintenance`, `Bug`, or `Other`. In the UI, `Bug` is displayed as **“Fix/Fixes”** for readability, but the underlying category is the same.

Finally, to estimate engineering effort more accurately, allocation percentages are adjusted using DX's [TrueThroughput®](https://docs.getdx.com/reports/truethroughput/) model, which accounts for the complexity of each pull request.
---

## Sitemap

[Overview of all docs pages](/llms.txt)