Classification rules and categories

Classification answers two questions about every piece of work: is it capitalisable (the financial dimension) and what kind of work is it (the work-type dimension). The answers travel with each effort entry into every report, and they're what makes a defensible capitalisable-versus- expensed split possible.

The two dimensions

Work can also be excluded entirely: ticket types you never want in the ledger (say, an "Ops request" type) can be excluded at the organisation level, and their effort is kept out of the split rather than misclassified.

Rules

A classification rule pairs a set of conditions with an output: the financial and work-type categories to apply. Rules are evaluated in priority order and the first matching rule wins. All conditions on a rule must match (they're ANDed). Use several rules for OR-style logic.

Conditions test ticket fields: issue key, issue type, status, summary, priority, story points, labels, components, assignee, reporter, sprint and provider, plus Jira custom fields. Operators fit the field type: text fields support equals/contains/starts with/ends with and list membership; numbers support comparisons; labels and components support inclusion checks; dates support before/after/between.

There are two separate rule scopes:

• Ticket rules (under Classification → Ticket Rules) classify tickets. Effort derived from a ticket's worklogs and commit sessions inherits the ticket's classification.
• Commit rules (under Classification → Commit Rules) classify commits directly, testing branch name, commit message or changed file paths. They apply to commits that aren't linked to any ticket: a linked commit inherits its ticket's classification first.

What happens without rules

New organisations start with sensible type-based defaults (stories classify as capitalisable feature work; bugs, tasks and spikes as non-capitalisable) so the ledger is never empty while you refine rules. Work nothing matches falls back to your organisation's default classification, and the entry records that it was a fallback.

That record matters: classification carries a source (manual, rule, inherited from ticket, or fallback), and the Confidence Report scores effort by it. Rule-classified work scores high; fallback-classified work is flagged as the "grey zone" to review before you rely on the split. The report shows the true state of your rule coverage rather than hiding thin spots.

Reviewing and overriding

The review screens (Classification → Ticket Review, and Commit Review) list classified work for a human pass. Overriding a ticket's classification takes precedence over every rule, and each change is written to an immutable history (previous values, new values, who changed it) so an auditor can trace any number back through its classification changes.

Once a reporting period is closed and locked, classification changes for work in that period are blocked. Reclassifying history under an auditor's feet is the failure mode the lock exists to prevent.

Where classification lands

Every effort entry stores its classification, source and the rule that matched. Reports split cost and hours by these fields. See the effort model for how entries are built, the R&D capitalisation guide for the period-close workflow, and the ledger overview for the product view of the same numbers.