How is each task classified?

By the first authority that can reach it, in strict precedence: a human override, then the board’s own CAPEX/OPEX field, then a classification inherited from the nearest classified ancestor row, then a keyword rule, then the model. The widget shows how many tasks each authority decided.

Why is that the precedence order?

It ranks by accountability. A human override is a person taking responsibility for the call. CAPEX is a finance-audited field someone already maintains. An inherited classification is still a human decision, one level up. A rule is deterministic and cheap. The model is the fallback for what nothing else could reach.

Does the OPEX flag override the model completely?

Only on the question it can answer. OPEX rules roadmap out and beats both the rule and the model on that, because promoting OPEX work to roadmap contradicts the flag rather than refining it. It cannot separate a customer defect from a refactor, so it defers to them to refine OPEX into internal technical, and settles for OPEX if both decline.

What does "not classified" mean?

No authority could reach the task. It is a fact about the pipeline, not a judgement about the work — and it is deliberately not something the model is allowed to answer, because "I could not tell" is not a classification the model gets to assign to its own output.

How work is classified: CAPEX, a rule, the model, or a person

Every class-based figure on the Team Focus view rests on a classification, and this widget is the one that says who decided it. When someone challenges a roadmap-share number, this is the widget that answers before you defend the number itself.

deckgauge · Board · Team Focus

Decided by	Tasks
CAPEX set on the board row	31
Matched a rule	18
Judged by the model	54
Set by hand	3
Not classified	16

Counts by deciding authority, over issues.

Only 31 of 122 (25%) carry a CAPEX/OPEX value, so the model is doing work the field would do for free — and more defensibly. Classify rows on the board and this shifts left on the next sync.

What it measures, and where the data comes from

The population is issues — not features. Each issue's class was decided by exactly one authority, and this widget counts them.

The classes themselves are A — Roadmap / CAPEX, B — OPEX, C — Internal technical and Unclassified. The vocabulary is the board's own: costClassification is two-valued, so CAPEX means A and OPEX means B.

How the number is calculated

The precedence chain

Classification precedence

#	Authority	Why it ranks here
1	Human override	A person taking responsibility for the call.
2	The task's own CAPEX/OPEX field	A finance-audited field someone already maintains.
3	Inherited from nearest classified ancestor	Still a human decision, one level up — and above a rule, because classifying a board row is a decision and a regex is a guess.
4	Keyword rule	Deterministic and cheap.
5	The model	The fallback for everything nothing else could reach.

First authority that can decide, wins.

Inheritance exists because a roadmap lives at epic level: people classify the epic, not the forty tasks under it. On the board that surfaced this, 27 classified epics covered 482 tasks while only 19 were being matched, because only the epics themselves carried a classification. The classifier now walks the parent chain — and it matches board rows with no type filter, because most CAPEX rows on a real board are tasks rather than epics.

A task explicitly marked OPEX under a CAPEX-marked epic is a deliberate exception, and rank 2 above rank 3 is what makes it win.

Two subtleties that change what the counts mean

OPEX rules roadmap out, and on that question it beats the rule and the model. It cannot separate a customer-visible defect from a refactor, so it defers to them to refine B into C — which asserts strictly more — and settles for B if both decline. But it discards an A verdict from either, because promoting OPEX work to roadmap contradicts the flag rather than refining it. So a task can be counted here as decided by CAPEX while its final class came from a rule.

CAPEX decides the class but not the epic. Only a rule or the model knows which epic a task advances, so the epic attribution is carried through even when the board's field set the class — otherwise the task would silently drop out of roadmap coverage.

"Someone said this is not roadmap" and "nobody has looked at this" stay distinguishableBoard-OPEX work is class B with provenance CAPEX; the residue is Unclassified with no provenance at all. That distinction used to live on a fourth class, D, which was never storable — the database enum has only A, B, C and Unclassified — so a hand-set or model-set D could not persist. Moving it onto provenance is what lets this widget render the difference.

Worked example

deckgauge · Every Task, and Why

Task	Board field	Rule	Model	Class	Decided by
PLAT-118	CAPEX	—	A	A	CAPEX
PLAT-141	— (ancestor CAPEX)	—	B	A	CAPEX (inherited)
SUP-991	OPEX	C	A	C	CAPEX
INF-77	—	—	C	C	MODEL

Four tasks, four different deciding authorities.

SUP-991 is the interesting row. The board says OPEX, a rule says internal technical, and the model says roadmap. OPEX discards the model's A. The rule's C refines B into something more specific, so the final class is C — while the authority credited is CAPEX, because the flag is what ruled A out. The class and the provenance come from different places, and that is correct.

How to read it

Read the CAPEX bar against the total. It is a data-quality measure disguised as a provenance chart: the higher it is, the more of your roadmap reporting rests on a field a human maintains rather than on inference.

Read a large model segment as a softness warning. Those classes are inferred, so any figure resting on them is weaker than one resting on CAPEX — not wrong, but harder to defend to someone who did not want the answer.

Read a large not-classified segment as the explanation for other widgets behaving oddly. It is what makes Roadmap Focus refuse to print a percentage once it passes half the population.

Do not compare this widget's total to the delivery funnel's. This one counts issues; the funnel counts features.

What it tells you over time

The mix should shift left as the board gets marked up. That is the trend to drive, and it is unusually cheap to move: marking a single epic CAPEX reclassifies every task beneath it through inheritance.

A model segment growing while the total holds steady means new work is arriving unclassified faster than anyone is marking it. That is worth a habit change rather than a tooling one.

Check the raw data Every number here is reproducible. Add Every Task, and Why — the ledger — to the same board and the same period. It lists every task with its raw state from Jira or Azure DevOps sitting beside the delivery stage it was mapped to, its class, the reason the classifier gave, its owner, its source system and its move count, and it filters by person, class and stage.

For this widget: each row prints the reason its class was given, and a class set by a person carries a Set by hand badge in the row text — not only a coloured glyph, because that row asserts a person overruled the board's own CAPEX flag. A provenance segment is read task by task there rather than trusted in aggregate.

The raw state sits next to the mapped stage deliberately: that is what lets you see how a state was interpreted and argue with it, rather than being handed a stage and asked to trust it. See the ledger reference for the full column list, or Ledger & caveats for the method behind it.

Example situations

1. The roadmap figure is mostly inferred

deckgauge · How Work Was Classified

Decided by	Tasks	Share
CAPEX set on the board row	9	7%
Matched a rule	11	9%
Judged by the model	88	72%
Set by hand	0	0%
Not classified	14	11%

The model deciding most of the population.

What you're seeing: 72% of the classification is model inference and 7% is a maintained field. The roadmap share elsewhere on the view is arithmetically sound and rests almost entirely on a language model's reading of ticket titles. That is fine for a directional read and weak for anything a finance or audit function will question.

How to react: the fix is upstream and cheap, and inheritance is the lever — you do not need to classify 88 tasks, you need to classify the handful of epics above them.

Managerial playMark the roadmap epics CAPEX once and let inheritance reclassify everything beneath them; on the reference board that single change moved 482 tasks. Frame it to the team as cheaper than the alternative rather than as extra process: the field is two clicks, someone often maintains it for finance already, and it replaces an inference nobody can defend in a review with a decision someone owns. Then re-read this widget after the next sync — the bar should visibly shift left, and if it does not, the epics were marked below the level the tasks actually hang from.

2. A challenged number, answered by provenance

deckgauge · How Work Was Classified

Decided by	Tasks	Share
CAPEX set on the board row	83	68%
Matched a rule	21	17%
Judged by the model	12	10%
Set by hand	4	3%
Not classified	2	2%

A strong provenance mix.

What you're seeing: 68% of the classification comes from a field a human maintains, 17% from deterministic rules, and only 10% from the model. A roadmap-share figure built on this is defensible in a way the previous example's is not — and the four hand-set overrides are visible rather than hidden, which is what makes the whole chain auditable.

How to react: this is the state to protect. It is also the state in which you can quote class-based figures to a finance function without qualification.

Managerial playWhen a class-based number is challenged, lead with this widget rather than with the number — "68% of this comes from the CAPEX field your team maintains, 10% is inferred" changes the conversation from a dispute about a percentage to a review of a method. Keep the four hand-set overrides visible rather than tidying them away; an override that is recorded and attributable is a strength, and the ledger badges each one so anyone can see who overruled what. If the mix ever drifts back toward the model, treat it as a data-quality regression with a named owner, because recovering it costs far less than defending a figure built on inference.

Frequently asked

How is each task classified?: By the first authority that can reach it, in strict precedence: a human override, then the board’s own CAPEX/OPEX field, then a classification inherited from the nearest classified ancestor row, then a keyword rule, then the model. The widget shows how many tasks each authority decided.
Why is that the precedence order?: It ranks by accountability. A human override is a person taking responsibility for the call. CAPEX is a finance-audited field someone already maintains. An inherited classification is still a human decision, one level up. A rule is deterministic and cheap. The model is the fallback for what nothing else could reach.
Does the OPEX flag override the model completely?: Only on the question it can answer. OPEX rules roadmap out and beats both the rule and the model on that, because promoting OPEX work to roadmap contradicts the flag rather than refining it. It cannot separate a customer defect from a refactor, so it defers to them to refine OPEX into internal technical, and settles for OPEX if both decline.
What does "not classified" mean?: No authority could reach the task. It is a fact about the pipeline, not a judgement about the work — and it is deliberately not something the model is allowed to answer, because "I could not tell" is not a classification the model gets to assign to its own output.

Related widgets

Roadmap Focus — the figure that depends most directly on this provenance mix.
Every Task, and Why — the per-task reason and the hand-set badge.
Roadmap Epics Touched — what marking epics CAPEX buys you beyond the class itself.
Method & Caveats — reports the unclassified count as a caveat on the window.
Method: Classifying work.
Back to the widget reference.

Last updated 10 September 2026