Risk Signal Decomposition(4.2.6)

The same composite risk score can be produced by very different underlying signals. One project may be driving risk through frequent workflow bypasses. Another may be driven by reopen surges. A third may have stuck issues and configuration drift. Knowing which signal is dominant shows where to look first.

What you can conclude

• A project where bypass events dominate the risk score is moving issues from a to-do status straight into a done one — worth asking whether its workflow allows that by design, or why the defined path is being skipped.
• A project dominated by reopen events is recording issues that come back after closure, which a reviewer would read alongside how that project defines done.
• A project where stuck issues dominate is holding open issues that have recorded no activity for 14 days — a reviewer could ask whether that work is waiting on something, or whether the project is still in use.
• A project where configuration drift dominates had its configuration changed that week (its settings, its components, its board, or the field contexts and issue types that apply to it); the question it raises is whether each change was planned and recorded.

How this chart works

Stacked bar chart showing weekly risk signal contributions per project: bypass events, reopen events, stuck issues, and configuration drift. Each segment's size shows its proportional contribution to the total score. Select a project to see its weekly timeline; leave unfiltered to compare each project's latest complete week.

Configuration drift counts the configuration changes recorded for the project: a change to its settings, a component added, changed or removed, a change to its board's configuration, and a field context or issue type that applies to it. Edits to issues, such as field changes and comments, are not configuration changes and are not counted. Changes made for the whole site, such as a global field or issue type, name no single project and are not counted here. Changes to workflows are not counted here either, including a workflow that belongs to a single project.

An issue counts as stuck in a week when, at that week's end, its latest recorded status is in Jira's To Do or In Progress category and it has recorded no activity for 14 days; deleted issues, issues in a project that was moved to the trash or permanently deleted, issues whose latest recorded status is in the Done category (including issues closed before MetaFrazo began receiving events), and issues with no recorded status are not counted, and an issue that moved to another project counts once, under the project it belongs to at that week's end. A project restored from the trash counts its issues again from the week it was restored.

A project appears for every week in which it recorded an event, held a stuck issue or had a configuration change recorded, through the most recent complete week in which MetaFrazo received events from the site, so a project that has gone quiet still shows the stuck issues it holds. A project that never held an issue does not appear, and the project's own creation, archiving, unarchiving, trash, restore or deletion does not by itself add a week.

This chart reads each project's latest complete week and does not count the week in progress. Projects report in different weeks, so the chart names no single week.