Type Reclassification Flows

When an issue's type is changed after it was created, it means the initial categorization was wrong. Sometimes this is routine — a Task that turned out to be a Bug. But a consistent pattern of reclassifications from one type to another can reveal a gap in how your team categorizes work at intake, or a compliance risk if issues are being reclassified to avoid formal incident reporting obligations.

For NIS2 incident categorization audits, this view provides the evidence trail of how issues moved between types.

What you can conclude

• A high volume of reclassifications from Task to Bug suggests that bugs are being underreported at creation — the team is categorizing them as tasks to avoid escalation.
• Reclassifications that consistently happen in the same direction may indicate a categorization training gap.
• A low reclassification count overall is a positive signal — the team is categorizing work correctly at intake.

How this chart works

Flow chart showing reclassification events between issue types, with source and destination type, count of events, and timing. Use the project and date filters to focus on specific teams or periods.