Visual reference

Active Actors(4.5.1)

How many distinct contributors took at least one tracked action in the window. Useful for spotting growth (more active actors) or attrition (fewer than expected). The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills. The count is split by the type of account Jira reports: people's accounts form the headline, and apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside it, never inside it.

Active custom fields(5.10.3)

How many of the custom fields in your declared catalog have actually been written to in the last twelve months, and how large that catalog is against the platform ceiling. The gap between the two is the point: fields that were created once and forgotten are clutter that quietly slows down screens, search, and audits.

Active users(8.2)

How many of your teammates have actually signed in and used the dashboard recently. The gap between this number and Total Members points at unused seats or teammates who never finished onboarding.

Activity by Project(2.1.11)

Time-series of activity per project—each line represents one project's daily activity over the window. A project that suddenly goes quiet mid-sprint is worth checking; activity peaks misaligned with planned sprints often indicate reactive firefighting rather than planned delivery. Consistent regular activity across a project is a strong signal of a well-run, predictable team. Use Deep Analysis to get an AI-generated read on which projects' rhythm looks intentional and which look reactive.

Actor × Project Coverage Matrix(5.6.8)

Matrix showing which actors have been active in which projects during the selected window—direct evidence of what each person is doing versus what their role permits. An actor active in every project at once, especially a new one, is an anomalous access pattern worth investigating; an actor in only one or two projects is operating within an expected scope. Each row is labeled with the type of account Jira reports for the actor (a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type), so an app account's coverage is read apart from people's. Use Deep Analysis for an AI read on which cross-project actors warrant a role check and which patterns look consistent with intended access.

Actor Activity Consistency Score(4.5.10)

A multi-line chart of each actor's weekly event count, with a table rating how steady that count is across all of the actor's projects. The rating is a MetaFrazo measurement of the coefficient of variation in four levels, from highly consistent to irregular: it describes the rhythm of recorded activity, not the quality or amount of anyone's work, and many roles are bursty by nature. For example, someone who alternates between two projects week by week can rate highly consistent overall while each project on its own looks irregular. Apps such as Automation for Jira and service-desk customers are left out of the chart and the table, as Jira reports the account type; an account Jira returned no type for stays in, labeled unknown. Use Deep Analysis to see which patterns follow role or project cadence. An actor with only one complete week of recorded activity has no measurable variation and shows no rating rather than a perfect score.

Actor Bypass Fingerprint(3.1.10)

A per-actor risk score combining bypass count and reopen contribution. For an actor at the top with a high bypass count, a reviewer could ask how they use the workflow; where Jira reports the account as an app (an integration or automation, such as Automation for Jira), the question is what that process is allowed to do. Each actor is labeled with the type of account Jira reports for it: a person, an app, a service-desk customer, or unknown. A broad spread across many actors points to how the workflow is designed rather than to any one person. Use Deep Analysis for a read on which actors' signals stand out and which reflect process design. Counts cover the selected date range only. The score shown per actor is that actor's weighted deviating transitions as a share of the transitions they made in the range, aggregated across the range rather than read off any single day; actors with fewer than five transitions in the range show no score rather than a score computed off one or two events.

Actor Event-Type Specialization(4.5.6)

A heatmap of actors against event types, where each cell is the percentage of that actor's events of that type. It reveals natural specialization and surfaces actors whose visible mix undersells their real value, such as a developer whose dominant activity is reviewing rather than throughput. An unusual mix for a role often signals that role definitions have drifted. Apps such as Automation for Jira and service-desk customers are left out, as Jira reports each account's type; accounts Jira returned no type for stay in, labeled unknown. Use Deep Analysis for a read on whose mix warrants a role-design conversation. The mix is measured over the full retained event history, so it is an all-time specialization profile: the page's date range does not narrow this visual; the project and actor filters do.

Actor Lead Time Profile(2.7.10)

A per-actor profile showing average time to delivery and total tickets delivered, counted under your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); an appended abandoned count gives fairness context, since an actor doing backlog cleanup is not slow — a useful input for one-on-ones, workload balancing, and spotting members carrying disproportionate complex work. The dashed reference line is the median of the actors shown, so roughly half the team sits either side of it. Issues credited to an account Jira reports as an app or a service-desk customer are left out, and the line is taken over people's accounts only; an account Jira returned no type for keeps its bar, labeled unknown, but does not move the line. For an actor well above that line with a high ticket count, a reviewer could ask what kind of work they carry; compare issue types before drawing conclusions, and a cluster near the line means delivery speed is similar across the team. Use Deep Analysis to get an AI-generated read on the team-balance picture and which actors sit furthest from the line.

Actor Ownership Churn Ranking(2.5.9)

Ranks actors by a weighted ownership churn score that weighs unassignments most, reassignments next and initial assignments least. It's a pattern surfacer, not a performance judgment: a manager's score is naturally high on initial assignments, but a contributor with many unassignments cleared the assignee on many issues, whoever held them, and when churn is concentrated in one or two actors, most ownership changes pass through them. Each actor is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to get an AI-generated read on each top actor's specific pattern and the questions it raises. Counts cover the selected date range only.

Actor Project Spread(4.5.8)

Per-actor project count, color-coded by spread: specialist (1 project, green), dual-project (2, blue), broad (3-5, amber), cross-portfolio (6+, red). An actor whose recorded activity carries no project at all—site-level events only—has a project count of 0 and is not classified. A project that relies on a cross-portfolio actor shares that person with five or more other projects, and a reviewer could ask which projects rely on a single specialist; the events show each actor's spread, not whether it is a problem. A team where most actors are amber or red records each person's activity across three or more projects; a team where most are green records each person on a single project. Apps such as Automation for Jira and service-desk customers are left out, as Jira reports each account's type; accounts Jira returned no type for stay in, labeled unknown. Use Deep Analysis to get an AI-generated read on whether your spread distribution supports your operating model.

Actor Risk Profile(2.6.9)

Ranks accounts by the count and type of admin-level events they trigger. The "who" view for permission drift—a reviewer can ask whether each account near the top holds only the access its purpose needs. The events Jira sends for field, project and user-account changes, deletions among them, do not name the account that made them, so they are not ranked here. For an account with no recognized name or unclear purpose, a reviewer could ask who owns it and why it holds admin-level access. Each account is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to get an AI-generated read on which accounts a reviewer would ask about first and which match routine administration.

Actors tracked(5.6.1)

How many actors are currently in scope for the activity-mapping analysis. The denominator for several of the rates below. The count is split by the type of account Jira reports: people's accounts form the headline, and apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside it, never inside it.

Actors with PII events(5.4.4)

How many distinct contributors have generated detected events, counting both detection arms (email pattern and phone-shaped digit run). Useful for spotting structural training needs (many actors with isolated events) versus targeted ones (a few actors with many events). Read it next to the per-actor chart, which shows which arm each actor's count came from. The count is split by the type of account Jira reports: people's accounts form the headline, and apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside it, never inside it.

Admin-Level Change Events Over Time(2.6.6)

Weekly timeline of admin-level configuration activity. A burst in a single week that doesn't correspond to a known deployment or migration is the kind a reviewer asks about; consistent low-level activity spread across weeks is routine housekeeping. A spike dominated by deletion events (field deletions, user removals) removes configuration rather than adding it, and is usually the first spike a reviewer opens. Pair with the change-window calendar to verify each spike has an authorizing event. Use Deep Analysis to get an AI-generated read on which spikes correspond to planned events versus which need explanation.

Admins & owners(8.4)

The count of people with elevated permissions in your organization. Good housekeeping: keep this number small, and review it whenever someone changes role or leaves the company.

Anomaly Weeks(4.2.3)

How many weeks in the selected period sat outside the portfolio-wide control limits—unusually high, or unusually low, against a baseline drawn from every complete week the workspace has sent events. Movement here often points to a shared external event rather than to independent project issues. Where two standard deviations below the mean falls at or below zero there is no lower limit, and only high weeks can be counted. The limits themselves need more than one complete week of portfolio activity to exist at all: with a single complete week there is no standard deviation, so there is no band for any week to sit outside of. A zero on this card is a real reading—the limits exist, and no week crossed them. Where no week could be judged, or the selected period holds no weeks of activity at all, the card shows a dash instead, because a zero would claim an all-clear that was never measured. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Assignee Churn per Issue(5.3.9)

Heatmap of projects against issue types showing where assignee churn per ticket is highest. Frequent ownership changes can reflect genuine confusion, but they also obscure who was ultimately accountable. A dark cell at one project-and-type combination means issues of that type in that project change hands more often than elsewhere; a project dark across all types shows churn on every kind of work in it. Use Deep Analysis to see which cells matter most and the questions they raise.

Assignment Surge Timeline(2.5.10)

A daily timeline breaking assignment activity into initial assignments, reassignments, and unassignments. Simultaneous reassignment and unassignment spikes mark an ownership-handover wave, a reassignment surge alone indicates bulk triage, and days where unassignments far exceed reassignments are most concerning — work is being dropped faster than picked up. Use Deep Analysis to get an AI-generated read on which surge days were planned reshuffles versus emergent disruptions.

Audit Trail Coverage by Event Type(4.4.9)

Stacked bar showing the proportion of events with full changelog entries (green) versus those without (red), broken down per event type. Shows which event types are producing the most audit gaps. A gap concentrated in one event type (often field updates or comments) is the targeted intervention point; gaps spread across all types point to how changelog data is produced for every type. Use Deep Analysis to get an AI-generated read on which event-type gaps say the most about where the changelog record is incomplete. Coverage is counted over the full retained event history, so each event type carries one all-time figure: the page's date range does not narrow this visual, and the project filter does.

Average Time in Status(2.7.5)

Per-project bar chart of average time issues spend in each workflow status. A status with disproportionately high average time is where work waits longest—worth directing improvement effort there rather than at execution speed. If the same stage (e.g. In Review) is slow across all projects, the constraint is shared rather than local; a project where To Do dominates is holding work before it starts, not while it runs. Statuses in Jira's Done category are kept in the chart—the dwell is real and worth seeing—but are not eligible for the Top bottleneck ranking, and their dwell is measured only for issues that later left the status, so it is a sample of departures rather than time since completion. Use Deep Analysis to get an AI-generated read on whether your bottleneck is project-specific or organizational. Waits are reported at their full length with no upper limit applied, so read the average alongside the median: where the two diverge sharply, a few long waits are driving that stage rather than the typical case. The median and the 90th percentile are published only for a project, status and day with at least five departures; below that they are left blank, and the count of measurements says why.

Avg alert density(5.7.4)

Average share of each project's active issues that raised a compliance alert in the week, an issue counting once however many alerts it raised. High alert density without scoring improvements usually means alerts are firing but not acted on—a process bottleneck rather than a detection problem. This card reads the latest complete week and names the week it read. A density of 0.0 is a measurement and reads green—issues were raised and none of them triggered an alert; a dash means no project carried issues to measure.

Avg backward rate(5.1.2)

Average backward-transition rate across your projects. Useful as a single trend line; if it doubles over a quarter, a reviewer could ask whether acceptance criteria have changed. This rate covers every week in the selected range, including the week in progress.

Avg control coverage(5.7.2)

Average control coverage across the portfolio: of the issues resolved in the week, what share passed every control check the compliance monitor applies. A high share means resolutions are going through the control path; whether those controls are the right ones for the organization is a separate question. This card reads the latest complete week and names the week it read. The week in progress is left out rather than averaged, because a part-finished week reports a different, self-selected set of resolutions and its share can sit either above or below where the week finishes. If the only week in the selected range is still in progress, no share is shown. The chart below still covers every week in the range. A coverage of 0.0% is a measurement and reads red—the week resolved issues and none passed every control check; a dash means the week resolved nothing to check.

Avg governance score (Continuous control)(5.7.1)

The average MetaFrazo Governance Score across all projects in the most recent week, on a 0-100 scale — a single read across workflow discipline and control coverage. Green at or above 80, amber 60-79, red below 60. How it's calculated: MetaFrazo Governance Score. This card reads the latest complete week and names the week it read. A score of 0.0 is a measurement and reads red; a dash means no project in that week could be scored, and an unscored project is left out of the average rather than counted as a zero.

Avg Governance Score (Portfolio heatmaps)(4.1.3)

Portfolio-wide average MetaFrazo Governance Score on a 0-100 scale — the single best read on whether your team's governance (workflow discipline and control coverage) is holding up across projects. How it's calculated: MetaFrazo Governance Score. This card reads each project's latest complete week and does not count the week in progress. Projects report in different weeks, so the card names no single week. A week holding only the project's own creation, change, archiving, unarchiving, trash, restore or deletion is not counted as one of its weeks: the card reads the latest complete week in which the project recorded other activity.

Avg Lead Time (Forecasting)(4.3.4)

Average time from ticket creation to delivery across the portfolio, counted under your organization's terminal-status settings (a MetaFrazo default applies until configured); issues closed as abandoned or duplicate are excluded. Tickets created before MetaFrazo was installed, or whose creation MetaFrazo did not record, are left out rather than timed from a later event. Pair with backlog change: rising lead time plus growing backlog is the classic "we need more capacity" pattern. This card reads the latest complete week and names the week it read. The week in progress is left out rather than averaged: it covers only the issues delivered so far, which is a different, self-selected set rather than an early reading of the same one, and the average over it can sit far from where the week finishes. If the only week in the selected range is still in progress, no number is shown. The chart below still plots the week in progress.

Avg lead time (SLA patterns)(2.7.2)

The average lead time — creation to delivery — in the most recent complete week, weighted by each project's delivered issues, which makes it exact for the week as a whole. Only tickets whose closing status counts as delivered under your organization's terminal-status settings enter the average (a MetaFrazo default reading of the status name applies until configured); discarded and canceled work is counted separately, not as delivery. An average follows the long tail by design, so a handful of very slow tickets pulls it up. A true cross-project median is not derivable from per-project statistics, which is why this card reports the average. This card reads the latest complete week and names the week it read.

Avg Portfolio Risk Score(4.2.1)

The single portfolio-wide average risk score. A useful month-over-month trend line for executive scorecards; sustained increases are the leading indicator that more granular review is needed. This card reads each project's latest complete week and does not count the week in progress. Projects report in different weeks, so the card names no single week.

Avg Quality Score(4.1.2)

Portfolio-wide average quality score, derived from the reopen rate: the share of issue updates that move an issue back out of a terminal status classified as delivered under your terminal-status settings (a MetaFrazo default reading of the status name applies until configured); revivals of issues closed as abandoned or duplicate are not counted. Helps reviewers ask "is the team recording more progress but reopening more of it" rather than reading velocity in isolation. Weeks carrying too few updates to support a rate are left out of the average rather than counted as a perfect score. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Avg recurrence rate(3.4.2)

Portfolio-wide average recurrence rate. Useful as a single trend line: if the average is creeping up over six weeks, more resolved issues are coming back, and a reviewer could ask what the recurring issues have in common.

Avg sprint still-open share(2.4.2)

The average of each sprint's share of issues still open now, over every sprint Sprint Scope Still Open reads for the selected project and sprint filters (the date range does not apply), including sprints older than the 40 the chart draws, where each issue counts in the sprint it was most recently assigned to and issues deleted in Jira, in a trashed or deleted project, or whose events record no status that maps to a Jira status category are left out. Each sprint weighs the same in the average whatever its size, so read it beside the per-sprint bars rather than as one sprint's figure.

Avg Velocity Score(4.1.1)

Portfolio-wide average velocity score: the share of each project's recorded activity that is issue creates and updates, rather than views, comments, and administrative changes. Useful as a single headline trend; pair with the Portfolio Health Score Matrix below to spot which projects pull the average up or down. Projects whose latest complete week carried too few events to support a score are left out of the average rather than counted as zero. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Avg volatility index(2.5.2)

The share of assignment changes that are reassignments, meaning work handed to someone new after it already had an owner, measured per project per week on a 0 to 100 scale and then averaged across the projects active in each week and across the complete weeks in the selected period. The denominator is assignment changes, not all recorded events. Higher values mean the same tickets keep changing hands; lower values mean ownership tends to stick once assigned. Every project week counts equally, so one project with a single assignment change weighs as much as one with fifty: read this alongside Total assignment changes rather than on its own. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Avg Weekly Hours Logged(4.5.3)

Average weekly hours logged by contributors. Useful as a sanity check rather than a performance metric; a sustained increase over months is a pattern worth discussing with the team. Each contributor's hours in the selected range are divided by the complete weeks in which they logged time, and the card shows the mean of those per-contributor averages: the same weekly averages the worklog chart plots. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Avg Weekly Resolution(4.3.1)

Average number of tickets your team delivers per week across the portfolio, counted under your terminal-status settings (a MetaFrazo default applies until configured). The headline throughput number for capacity planning. This card reads the latest complete week and names the week it read. The week in progress is left out rather than counted: this is a raw count, so a part-finished week always reports a smaller number, which would read as delivery slowing down when only the week is short. If the only week in the selected range is still in progress, no number is shown. The chart below still plots the week in progress.

Avg Workflow Adherence(4.4.3)

Of the completions that delivered work in the most recent complete week (counted under your terminal-status settings; discarded or canceled outcomes are excluded), the share that passed through a work-in-progress status on the way to done rather than jumping straight from a new status, averaged across projects. Weeks with no completions do not contribute. A low value means completions are frequently skipping the working states your workflow defines. This card reads the latest complete week and names the week it read. The week in progress is left out rather than averaged: it covers only the completions recorded so far, which is a different, self-selected set rather than an early reading of the same one, and the share it reports can sit either above or below where the week finishes. If the only week in the selected range is still in progress, no score is shown. The chart below still plots the week in progress.

Backlog Age Distribution(2.4.5)

Stacked bar chart grouping the open tickets in a To Do-category status by how long they have gone without a status change, across four buckets: fresh (0-7 days), aging (8-14), stale (15-30), frozen (30+). Age runs from the ticket's latest captured status change, or from the creation time Jira records for it when no status change was captured. When frozen issues exceed 50 percent of open issues in any project, an amber banner is shown. A large frozen bucket means many to-do tickets have not changed status in over a month; a reviewer could ask which of them are still wanted. Use Deep Analysis for a read on which projects hold the most frozen work and the questions it raises. The page's start date does not narrow this chart: each project carries a single recency date, and a lower bound on it would delete precisely the projects whose backlog has gone longest without a status change, the population the frozen bucket is about. The end date still applies.

Backlog Arrival vs Resolution Rate(2.4.8)

Tracks weekly arrivals (tickets entering the backlog) against weekly resolutions (tickets pulled out). The area between the two lines is your net backlog change. A widening gap over multiple weeks is the definition of backlog acceleration—requires either reducing arrivals (scope control) or increasing resolutions (capacity); weeks where resolutions exceed arrivals are healthy debt-clearing. A consistently balanced chart means stable backlog size. Use Deep Analysis to get an AI-generated read on which structural interventions match your current gap shape.

Backlog Inflow Calendar Heatmap(3.2.9)

A calendar heatmap of daily backlog inflow intensity across all weeks, revealing whether spikes follow predictable patterns or are real anomalies. Consistent Monday peaks usually reflect planning events; random spikes with no calendar correlation more likely need root-cause investigation. Use Deep Analysis for a read on which patterns are calendar-driven and which are anomalies worth investigating.

Backlog Net Growth Trajectory(4.3.6)

Multi-line area chart of weekly net backlog change per project. A consistently positive line signals accumulating backlog; a negative line indicates a debt-clearing phase. Sustained upward slope is the structural signal that current capacity cannot meet current intake—a conversation about scope or staffing, not effort. The view is the most direct evidence of whether each team is catching up or falling behind. Use Deep Analysis to get an AI-generated read on which projects' backlog trajectories are most concerning and what intervention they call for.

Backward Transition Actor Ranking(5.1.6)

Horizontal bar chart ranking actors by how many backward transitions they triggered. A high count is not proof of wrongdoing; it shows who most often moves work back out of a done status, which is where a reviewer would start. A spread across many actors points to how the workflow is set up rather than to individuals; the same name recurring across compliance visuals is the stronger reason for a conversation. Each actor is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to see which actors stand out and which questions their transitions raise.

Backward Transition Rate Over Time(5.1.5)

Grouped bar chart of weekly forward transitions, meaning every status change that starts from a status that is not done, alongside backward ones (Done or Closed reopened into a status that is not done). When backward transitions make up more than a small share of each week's forward and backward transitions, week after week, a reviewer could ask whether requirements, handovers, or the definition of done are clear. Use Deep Analysis to see whether rework concentrates in specific projects or periods, and which question to ask first.

Backward transitions(5.1.1)

How many times a ticket moved out of a status in Jira's Done category into one outside it (for example, from Done back to In Progress). A backward move records that work left a done status, not why; a reviewer could ask what reopened it. This total covers every week in the selected range, including the week in progress.

Batch Close Detection(5.5.6)

Detects events where one actor closed two or more distinct tickets within a 30-minute window. At low volumes this can be efficient review work; at high volumes, especially for Critical or High priority tickets, it suggests individual tickets aren't getting the attention they need. A clean log means tickets are being closed individually. Each batch carries the type of account Jira reports for its actor (a person, an app, a service-desk customer, or unknown), so an automation rule closing several issues at once shows as app activity rather than as a person's batch. Use Deep Analysis for an AI read on which batch closes look like routine cleanup and which warrant a closer look.

Batch close events(5.5.2)

How many batch-close events were detected (multiple tickets resolved in quick succession by the same actor). Sometimes legitimate (quarterly cleanup); often a sign that "let's empty the backlog" took priority over real resolution. Counts batches by people; batches by apps such as Automation for Jira, by service-desk customers and by accounts Jira returned no type for are shown beside it.

Breach Acceleration Trend(3.5.9)

Per-project week-over-week change in the breach rate among delivered tickets; the direction of change matters as much as the current state. Abandoned closures never move the rate and are carried as their own count in the same row. A project at 40 percent that improved from 60 percent is a different situation from the same 40 percent that deteriorated from 20 percent. The chart immediately distinguishes improving teams from deteriorating ones, even when they share an absolute breach rate. Use Deep Analysis to get an AI-generated read on which improvements look durable versus which deteriorations are accelerating. Each ticket is measured against a target resolved from your organization's configured SLA policy by issue type where set, and a MetaFrazo default otherwise; the target never depends on priority.

Burst actors(5.3.2)

Number of actors who have suddenly started producing tickets and events after a period of inactivity (or zero history). For example, a new account that produces 200 events in its first day deserves an authentication check. The burst threshold is set by people's debut weeks only, at their mean plus two standard deviations; an erased account is not a person. With fewer than three people, or when every person debuts with the same count, no threshold is set, nothing is flagged and the figure shows "—" rather than 0. The count is split by the type of account Jira reports: people's accounts form the headline, and apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside it, never inside it.

Bypass Risk Score per Project(3.1.5)

A 0 to 100 gauge per project, computed over the trailing 90 days from two measures of that project's own status transitions: how many went straight from a not-started status into a done one (what MetaFrazo calls a bypass), and how many moved back out of done (a reopen). The bands (Healthy, Warning, Critical) sit below 40, at 40 to 70, and at 70 and above. A project with fewer than 10 transitions in the window shows no score at all rather than a low one, because that few transitions cannot separate a pattern from an accident. Use Deep Analysis for a read on which projects to look at first and what the two measures suggest asking about.

Change Lead Time(4.3.11)

Change lead time: days from issue creation to delivery across the portfolio, week by week. Only delivered issues count, under your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); a discarded issue never shipped and is excluded. The headline delivery-performance metric, alongside deployment frequency, change failure rate, and time to restore. Lower is faster delivery; a falling trend is the goal during a delivery improvement program. A stable lead time with rising change failure rates is a sign that speed is being bought with quality. Useful in delivery-performance dashboards alongside deployment frequency, change failure rate, and time to restore.

Chronic incident issues(3.4.4)

Tickets that have been opened, closed, and re-opened repeatedly—the long-running chronic issues. Usually one or two of these account for an outsized share of your team's frustration; addressing them changes the team's day-to-day quality of life.

Compliance Alert Density(5.7.10)

Per-project rate of compliance alerts, normalized by activity volume: the share of a week's active issues that raised at least one alert, so a busy project's 10 flagged issues read differently from a quiet one's. Density is more meaningful than raw counts when comparing projects of different sizes or tracking improvement over time. High density alongside falling compliance scores is the worst combination—many alerts, but they aren't driving action. Use Deep Analysis for an AI read on which projects' alert density is informative versus noise.

Compliance Event Canvas(5.8.1)

An interactive, zoomable canvas of every compliance-relevant event in your project history, filterable by actor, type, time, and category. Built for live review sessions: pick an audit window and surface what stands out—notable spikes, unusual actor patterns, or gaps versus a control standard. Useful for confirming consistent control coverage across a quarter or focusing on a single flagged project. Each event carries the type of account Jira reports for its actor (a person, an app such as Automation for Jira, a service-desk customer, or unknown), so an app account's events can be read apart from people's.

Composite Deviation Score(5.5.8)

Per-project composite score combining all individual control deviations—unlogged resolutions, batch closes, direct skips, and post-creation priority changes—into a single number. A high score means several deviation types are elevated at once, not a single exception. It's most useful for executive reporting and for prioritizing which projects to investigate first. Use Deep Analysis for an AI read on which composite scores are most actionable and which signals are doing the heavy lifting.

Composite Risk Score Ranking(3.3.5)

A ranked list of every open ticket scored across five risk dimensions: priority, inactivity, reopen history, priority escalation history, and a single-observation flag. A ticket counts as open when the latest status its events record is in Jira's To Do or In Progress category, including a ticket that has not changed status since MetaFrazo was installed; a ticket deleted in Jira, or in a project moved to the trash or deleted, is not listed, and a ticket moved to another project is listed once, under its current key. Priority is the latest one the event stream records; for an open ticket whose events record none, it is the priority MetaFrazo read from Jira, as it stood on the day it was read. A ticket with neither shows Unknown and carries no priority points. This measures governance risk, not complexity: high-scoring tickets carry several of the risk signals the score counts at once. Use Deep Analysis for a read on each top ticket's risk shape and the questions it raises. The page's date range selects the issues that were alive in it—created on or before the end date, with their most recent event on or after the start date—rather than the issues created inside it, so an older ticket that is still moving stays in the ranking. An issue that already existed when MetaFrazo was installed has no ingested creation event, so its Created column shows the creation time Jira records on the issue's events; a dash means neither a captured creation event nor a Jira creation time exists, and that issue is still ranked. The window places issues with no ingested creation event by the date MetaFrazo first observed them, which is an observation date and not a creation date, so a backlog that predates the install is visible instead of silently absent.

Config Change Volume(4.4.2)

Configuration changes observed across your Jira site in the most recent complete week: issue types, fields and field contexts, project structure, boards, and workflow definitions. Configuration in Jira is site-scoped, so this is one number for the whole site rather than a per-project average. A spike usually corresponds to a planned admin session; an unexplained one is worth a look at the Configuration Change Volume chart below. This card reads the latest complete week and names the week it read. The week in progress is left out rather than counted: this is a raw count, so a part-finished week always reports a smaller number, which would read as configuration activity slowing down when only the week is short. If the only week in the selected range is still in progress, no number is shown. The chart below still plots the week in progress, so its final bar is that partial week rather than the week this card reads.

Configuration Change Event Audit Log(2.2.11)

A filterable audit table of configuration events ordered by time, with date, event type, project, issue key, and triggering actor, each actor labeled as a person, an app, a service-desk customer, unknown or erased, or system where the event names no actor. This is the primary tool for forensic investigation and compliance review: filter by actor for an access review, by event type to isolate destructive actions, or by date range to scope an audit period. Use Deep Analysis to get an AI-generated read on suspicious patterns in your filtered set and what investigation steps to take next.

Configuration Change Volume Over Time(4.4.6)

Weekly count of configuration changes across your Jira site: issue types created, changed or deleted, fields and field contexts added, changed or removed, project structure, boards, and workflow definitions. Configuration in Jira is site-scoped, so this is one series for the site, with a 4-week moving average for trend. A week with activity but no configuration changes shows a true zero. Spikes usually correspond to planned admin sessions; use Deep Analysis to get an AI-generated read on whether the change cadence looks planned or accumulating.

Configuration Changes Over Time(2.2.6)

Stacked bar chart of daily configuration event volume, split between additive actions (created, updated, restored) and destructive ones (deleted, moved to the trash, archived). A sudden deletion spike on a single day warrants investigation—accidental removal of configurations still in use is one of the most common causes. Activity that aligns with sprint starts is normal planned setup; deletions approaching creation volume over time signal schema instability. Use Deep Analysis to get an AI-generated read on whether your recent destructive spike is planned or unauthorized.

Configuration Event Type Distribution(2.2.5)

A bar chart of admin-level configuration events grouped into one bar per domain (Field, Field Context, Issue Type, Project, Component, Filter, Board, Workflow, User). Most activity is legitimate, but spikes in field creation or user changes can signal unplanned schema growth, permission creep, or changes outside an approved window; a balanced, low-volume spread means few configuration changes were recorded and none of them concentrate in one category. Use Deep Analysis to get an AI-generated read on which category spike looks unplanned and what change-window verification it argues for. Bar heights cover each event type's whole recorded history: this chart is not bound to the date filter, so it can total more events than the date-filtered cards on the same page.

Consistent Actors(4.5.4)

The share of rated actors whose weekly activity across all of their projects rates consistent or highly consistent, meaning a coefficient of variation under 40% (with a project selected, their activity in that project). The levels are MetaFrazo measurements of how steady a weekly event count is, not assessments of anyone's work. Actors without enough history to measure (fewer than two complete weeks of activity) are excluded from the count, not assumed consistent. This card reads each actor's latest complete week and does not count the week in progress. Actors report in different weeks, so the card names no single week. Only people's accounts are rated in this share, as Jira reports the account type: apps such as Automation for Jira and service-desk customers are left out, and the number of accounts Jira returned no type for is shown in the sub line.

Contributor Acceleration Index(2.4.10)

A per-actor index comparing the issues each person advances against the issues they create; above 1.0 means they clear more than they add, below 1.0 the reverse. An actor who advanced work but created none at all has no finite index and counts as a net reducer; the chart draws their bar to the end of the axis, labeled "no new items". This isn't a performance ranking, but when low-index contributors coincide with backlog growth it's worth a targeted conversation. Apps such as Automation for Jira and service-desk customers are left out, as Jira reports the account type, and an account Jira returned no type for is listed as unknown. Use Deep Analysis to get an AI-generated read on the balance picture and which conversations would be most useful. The page's date range selects who is listed—contributors whose most recent activity falls inside it—while each index shown is computed over that contributor's full recorded history.

Control Coverage Rate(5.7.6)

Percentage of each project's resolutions that passed both of MetaFrazo's control checks: a worklog was recorded on the issue, and the issue never jumped from a To Do status straight to a Done status in one step. A resolution that misses either check counts as uncontrolled, so a project at 88% had 12% of its resolutions miss at least one check. Use Deep Analysis for an AI read on which projects stand apart and where to look to see which check they miss.

Control Deviation Trend(5.7.7)

Total compliance deviations across all signal types, tracked over 12 rolling weeks. The rolling total reveals the overall trajectory that individual signals can obscure—three or more consecutive weeks of rising deviations is the pattern least likely to correct itself. A flat or declining trend with steady activity volume means deviations are not growing with the work. Use Deep Analysis for an AI read on which signals contribute most to the recent trend and what to address first.

Controlled vs. Uncontrolled Resolutions(5.7.8)

Weekly ratio of resolutions that passed the configured control checks versus those that did not, across the portfolio. It makes immediately visible whether the controlled share is rising or falling; a falling share is an early warning worth a question about which check is being missed. A stable ratio just below target often means policy is enforced inconsistently across teams. Use Deep Analysis for an AI read on which teams drive the current ratio and what targeted enforcement should look like.

Creation Composition(2.1.15)

Mix of ticket types (bugs, stories, tasks, etc.) created in the window. A sudden shift—a six-week stretch where bugs jump from 20 percent to 45 percent of intake—usually signals either a quality regression or a deliberate cleanup effort. Different mix shapes argue for different team responses: bug-heavy mixes need quality investment, feature-heavy mixes need scope discipline. A stable mix is consistent with mature delivery operating in steady state.

Critical alerts(3.2.2)

Of those spikes, how many crossed the critical-severity threshold. Helps separate background noise from the few events that genuinely affected delivery. The day in progress is shown at its count so far. Because the day is not yet complete, it is not compared against the rolling baseline and is not evaluated for a spike. While no day in the window has a baseline yet, the card shows "Collecting data" rather than 0.

Critical count(3.3.2)

Of those scored, how many cross the critical-risk threshold. Usually a small number; if it grows steadily week over week, the rise is spread across the portfolio rather than confined to a few outlier tickets.

Critical issues(5.4.2)

How many of the detected events crossed the critical-severity threshold.

Critical issues (severity tile)(5.4.11)

Current count of tickets in the Critical severity tier of the sensitive-data detector. The same number as the Critical issues KPI, broken out as its own card for the severity-breakdown row on the page.

Critical stuck issues(3.1.2)

How many open tickets, open by the latest status their events record, have sat in their current status more than 5× the reference stay for that same status: the survival median of every stay recorded in that workflow status in your workspace, never shorter than one day, or the workspace-wide reference where the status has too little history, where that same status means the same workflow status matched on Jira's own status ID rather than on the status name. The Stuck-in-Status Detector below lists everything past 2.5× the median and this counts only the far tail of it, so the table can hold rows while this reads zero. Each ticket is counted once, followed by the issue itself rather than by the key it carries, so a ticket that moved to another project and took a new key there is counted under the key it has today and not a second time under the old one. A ticket whose move into its current status was never captured is not counted, because its time in that status is unknown. The severity classification (Warning, Critical) is the view's own, not a second calculation on the page.

Cross-Project Incident Timing Correlation(3.4.10)

Quantifies the timing correlation between project pairs, after the portfolio's own week-to-week rhythm has been removed. Each project's weekly incident count is measured against that week's average across all projects, and the coefficient compares those deviations—so a pair scores highly only when it moves together beyond whatever the portfolio as a whole was doing that week. Shared deployment pipelines, infrastructure components, or dependencies can cause correlated failures across multiple projects simultaneously. A pair standing well above the rest of the matrix is a candidate for a shared timing driver, worth investigating together rather than separately. The week in progress is not counted: every coefficient is measured over complete weeks only, so it does not shift as the current week fills. Use Deep Analysis to get an AI-generated read on which pairs stand out and what shared dependency is worth checking.

Cross-Project Spread(5.3.7)

Flags actors who became newly active across three or more projects within the selected date range. Sudden multi-project activity may reflect a role change; a reviewer could ask whether that access was granted on purpose. A chart with no flagged actors means no actor crossed that threshold in the range. Each actor is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to see each flagged actor's expansion shape and which ones a reviewer could check against role-change records.

Cross-Team Collaboration Index(4.5.7)

Matrix of shared-issue overlap: for each pair of actors, the share of the less active actor's issues that both generated events on—pooled across every project the pair shares, or within one project when the project filter is set. Any two events on the same issue count, a status change as much as a comment or a field edit, so the figure is co-occurrence on issues—the closest proxy Jira events offer for joint working—and not a record of communication; a triage pass that touches many issues raises every pair it shares. A pair is rated only when that base is at least ten issues; below it the cell is blank rather than a percentage, and a blank is not evidence of no collaboration. Higher values mean the pair's issues overlap more; low overlap with high specialization is normal in expert teams, low both is worth asking about. The matrix is most useful for spotting unexpected pairs and absent expected pairs; what either means is a question for the team, not a finding the events can settle. Pairs that include an app such as Automation for Jira or a service-desk customer are left out, as Jira reports each account's type, so an app that touches every issue does not appear as everyone's closest collaborator; accounts Jira returned no type for stay in, labeled unknown. Use Deep Analysis to get an AI-generated read on which collaboration shapes argue for team-design changes. The percentages count every issue in the full retained event history, so this is an all-time collaboration profile: the page's date range does not narrow this visual, and the project filter does.

Cumulative Flow Diagram(2.1.14)

Stacked-area chart showing how many tickets sit in each workflow status over time—the classic cumulative-flow visualization. Widening bands near the top indicate build-up in that status; bottlenecks become visually obvious before they show up in cycle-time numbers. A balanced flow with similar-width bands across statuses is the healthy steady state. The view is the most diagnostic chart for "where is work actually getting stuck".

Cycle multiplier(2.3.4)

How much longer a reopened ticket takes to reach final delivery, compared to a ticket delivered on the first try. Both cohorts cover issues whose last terminal status counts as delivered under your organization's terminal-status settings (a MetaFrazo default applies until configured); issues whose last closure is a discard are excluded and counted separately. A multiplier of 2x or 3x is common; values above 4x signal that reopens are essentially restarts.

Cycle Time Control Chart(2.7.12)

Statistical-process-control view of cycle time for delivered issues. The average and the control limits are properties of a single project's distribution, so they are drawn only when one project is in view — select a project to see them. Across several projects the points are still plotted and still colored by each project's own limits; only the lines are withheld, because one line cannot describe several projects. A lower control limit drawn only where one exists: two standard deviations below the average is below zero for most delivery data, and a cycle time can never go there. A project with fewer than five delivered cycles has no limits, and its points are shown in gray as unrated rather than as in control. Points are issues that reached a delivered status under your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); discarded work is not plotted and does not move the control limits. Points outside the bands are the cycles worth investigating individually. A tight, stable band indicates mature delivery; a widening band is the early warning that process variance is increasing.

Cycle Time Histogram(2.7.13)

Histogram of cycle times across delivered tickets in the window, counted under your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); discarded work is excluded from the distribution. Shape tells the story: a tight single peak is a predictable process; a long right tail means a handful of outliers are dragging the average; a bimodal distribution often reflects two different work classes (small bugs versus features) being mixed in the same flow.

Daily Backlog Inflow (Control Chart)(3.2.5)

A statistical control chart of backlog inflow with a rolling 14-day baseline and control bands, separating routine day-to-day variation from days that stand out against it. With no project selected the chart plots the portfolio as one series: the day's total intake across every project, with the baseline recomputed over that total. Selecting a project switches to that project's own series and its own baseline. The spike counters above and the alert log below stay per project, so a day can pass the portfolio limit with no single project passing its own, and a project can pass its own while the portfolio absorbs it — the row tells you how many projects contributed and how many of them passed their own limit. Days with fewer than six observed days behind them carry no baseline and no band and are not evaluated for a spike: the bar is drawn in gray and the lines stop, rather than a baseline built from almost nothing. Use Deep Analysis for a read on which days sit outside the baseline and which look like routine variation.

Daily Governance Score(3.1.7)

A day-by-day time series of the MetaFrazo Governance Score (0-100), averaged across all projects that reported each day, blending workflow discipline and control coverage. A sustained downward trend, and the day it began, are the first things to read. How it's calculated: MetaFrazo Governance Score.

Delivery Velocity(2.1.8)

Dual-line chart of issues created vs issues resolved over time—the gap is the net change in backlog size. When creation consistently outpaces resolution, backlog pressure is building even if no one has noticed; this is a leading indicator, not a lagging one. A persistent gap where creation exceeds resolution means the backlog has been growing for that whole stretch; convergence over time means arrivals and resolutions are running at a similar pace. Use Deep Analysis to get an AI-generated read on whether your current gap looks recoverable or structural.

Deviation actors(5.5.4)

How many distinct actors are contributing to control deviations. A small number indicates targeted coaching can fix the pattern; a large number indicates structural process issues. The count is split by the type of account Jira reports: people's accounts form the headline, and apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside it, never inside it.

Deviation Rate by Issue Type(5.5.9)

Heatmap of control deviation rate by project and issue type. Deviations aren't evenly distributed: a dark cell at one project-and-type combination points to how that one type of work is handled in that project, while a project dark across all types points to something the whole project shares. A uniformly light heatmap means few deviations were recorded on any type of work. Use Deep Analysis for an AI read on which cells matter most and what question each raises.

Direct Open-to-Done Skip(5.2.7)

Weekly bar chart of tickets that moved straight from an initial status to a terminal one in a single step, bypassing every intermediate stage. A high rate means more delivered tickets passed through no intermediate stage, and a reviewer could ask whether that work went through review outside Jira. Counted over skips landing on delivered statuses only, under your organization's terminal-status settings (a MetaFrazo default applies until configured); skips into discard statuses are backlog hygiene and are not counted. Week spikes often track sprint ends; a steady decline means fewer tickets are skipping the intermediate stages. Each skip is attributed to the type of account that made it, as Jira reports it: the count covers skips by people, and skips made by apps such as Automation for Jira, by service-desk customers, by accounts Jira returned no type for, by erased accounts or with no recorded actor are shown beside it. Use Deep Analysis to see which projects, issue types, and weeks drove the recent skip rate.

Direct open→done(5.2.3)

Count of tickets that went directly from an open status to Done with no intermediate steps. The count covers skips made by people; skips by apps such as Automation for Jira, by service-desk customers, by accounts Jira returned no type for, by erased accounts or with no recorded actor are shown beside it. Counted over skips landing on delivered statuses only, under your organization's terminal-status settings (a MetaFrazo default applies until configured): a skip into a discard status is backlog hygiene and is not counted, so what remains claims delivered work with no intermediate stages. Persistent rates point at a workflow that doesn't reflect actual practice. This total covers every week in the selected range, including the week in progress. Weeks are counted whole: a week that falls only partly inside the selected range is not included, so this total covers the same weeks as the Direct Open-to-Done Skip chart below it.

Elevated / Critical Projects(4.2.2)

How many of your projects are currently scoring Elevated or Critical on the composite risk score — a score of 50 or above, on a 0-100 scale measuring the bypass-weighted share of status transitions that deviated. Useful as a board-readiness number: "we have three projects in critical risk this month, here's the picture." This card reads each project's latest complete week and does not count the week in progress. Projects report in different weeks, so the card names no single week. A project whose latest complete week carries fewer than 10 status transitions is not scored, and is counted in neither direction — neither as elevated nor as safe; when no project clears that floor the card shows a dash rather than a zero, because a zero would claim an all-clear the evidence does not carry.

Email-Pattern Issues Log(5.4.9)

Truncated log of specific tickets containing email-pattern PII—the most common and highest-risk type. Truncation avoids re-exposing the full data; the log is structured for data-protection teams to remediate case by case. A long list in a short period may point to a workflow or integration generating exposure; a log that clears over time means older entries are no longer listed and new ones are not appearing. Each entry is labeled with the type of account Jira reports for the account that recorded it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to see patterns across entries and the most likely structural source to address.

Escalation Run Duration(3.6.9)

How many consecutive weeks each project has spent above the escalation threshold—a project sitting above it for many weeks running becomes impossible to overlook. A one-week spike may be temporary; a six-week run is structural and requires leadership intervention, not another sprint of "we'll get to it". Short runs are usually recoverable with focused attention; runs above three weeks should trigger an executive conversation. Use Deep Analysis to get an AI-generated read on which long-running escalations look stuck versus on a path to recovery. A week with too little evidence to score does not count as an escalating week, so it interrupts a run rather than extending it.

Escalation Score Timeline(3.6.5)

Longitudinal view: composite risk score per project plotted over time. Rather than showing where projects stand today, shows whether they're trending toward escalation, stabilizing, or continuing to deteriorate. For executives reviewing governance trends, this is the primary evidence of whether risk management is improving or getting worse over time. Use Deep Analysis to get an AI-generated read on which projects' trajectories are rising fastest and which have changed direction. Weeks measuring fewer than two of the three signals are left unscored and appear as a gap in the line rather than as a low score.

Escalation Trigger Attribution(3.6.7)

Per-project breakdown of which underlying signals are driving the composite escalation score. The score combines three measured signals: how much of the resolved work took longer than its target, how much of the week's status activity was work returning from a delivered state, and how much of the week's work stopped moving for longer than that status usually takes. A project driven mainly by the stuck signal points to a different conversation than one driven mainly by the target-date signal, so the split is often more actionable than the score itself. Each bar shows a signal's contribution normalized by the signals actually measurable that week, so weeks with too little activity to measure a signal are not scored as if it were zero. The component rates are still shown for a week whose composite score could not be computed, so you can see which signal was missing.

Event Density Anomaly Detector(4.2.9)

Control chart of portfolio-wide weekly event count with the mean and plus-or-minus two-standard-deviation control limits computed over every complete week the workspace has sent events. A week outside either limit is highlighted red, and where two standard deviations below the mean falls at or below zero there is no lower limit to draw, because no event count could cross it. Shows portfolio-level event volume that sits outside the range the rest of its history sets, which may reflect a shared external event (a major release, an incident, a process change) rather than independent per-project issues. The band is built from absolute event counts, so it also moves when the portfolio itself changes size. Use Deep Analysis to get an AI-generated read on which flagged weeks correspond to known events and which need explanation.

Event Seasonality (DOW × Week-of-Month)(4.3.7)

Heatmap of average event volume by day-of-week and week-of-month. Reveals seasonal patterns in workflow events; useful for sprint timing decisions. A hot vertical band on every Monday usually means weekend processes (deploys, automation) are the actual driver of weekly volume, not human work. End-of-month spikes often coincide with release pressure or quarterly close. Use Deep Analysis to get an AI-generated read on which seasonal patterns suggest planning changes and which are accepted realities. The heatmap averages every occurrence of each slot across the full retained event history, so it is an all-time seasonal profile: the page's date range does not narrow this visual, and the project filter does.

Event Volume by Actor(5.6.5)

Per-actor activity profile showing each actor's status transitions, assignee changes, priority changes and comments as one stacked bar, ordered by total event count, with each Jira change counted once even where Jira reports it through more than one event. The breakdown makes role-versus-action mismatches visible—an actor whose bar is mostly assignee and priority changes is routing work rather than executing it, which may fit a coordinator or an admin, or may point to access the role was not meant to cover. Volume outliers in both directions stand out, from very high volume to accounts with almost no activity, and each actor is labeled with the type of account Jira reports for it (a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type). Use Deep Analysis for an AI read on which actors look unusual for their role and where an access review should focus first.

Event-Type Specialization by Actor(5.6.10)

Per-actor table showing each actor's dominant event type alongside a derived segregation-of-duties risk label, built for role-based access reviews. It compares what people actually do against what their assigned role should permit—a developer whose activity is almost entirely status transitions is worth a second look against what the role is meant to cover. Actors with fewer than 20 workflow actions (status transitions, comments and assignment changes) are listed below the ranked ones without a share or a risk label, because a share over a handful of actions says little. Aligned actors are operating as expected. Each actor is labeled with the type of account Jira reports for it (a person, an app such as Automation for Jira, a service-desk customer, or unknown), so an automation account's specialization is not read as a person's role. Use Deep Analysis for an AI read on each mismatch and what an access adjustment should look like.

Executive Portfolio Escalation Summary(3.6.8)

Board-ready one-page summary: number of projects in escalation, number approaching the threshold, portfolio average risk score, week-over-week change. No charts, no detail—just the numbers executives need to assess whether the portfolio requires attention. Pairs naturally with monthly review decks; the format is designed to translate directly into an executive update without further trimming. Use Deep Analysis to get an AI-generated narrative that complements the numbers and frames the leadership conversation. Weeks measuring fewer than two of the three signals are left unscored. The project count covers every tracked project, scored or not.

Fast-Close Distribution(5.2.8)

Histogram of the time between ticket creation and closure across buckets from under five minutes to over a day. Tickets closed as delivered within minutes of being created spent almost no time open in Jira; MetaFrazo flags those under five minutes as rubber-stamp closures, a name for the timing, not for anyone's intent. Closures into statuses your organization counts as abandoned (a MetaFrazo default reading of the status name applies until you configure one) are backlog hygiene, a duplicate discarded at triage; they appear in the histogram with their own disposition and are not flagged. A heavy under-five-minute bucket raises the question of where that work was done and reviewed; a distribution skewed toward longer lifecycles shows work recorded over time. Every bucket is also split by the type of account that closed the issue, as Jira reports it, so an automation rule that closes issues within seconds of creating them shows as app activity rather than as people's rubber-stamp closures; closures by service-desk customers and by accounts Jira returned no type for are shown apart as well. Use Deep Analysis to see which projects and actors drive the fastest closures and where to focus an investigation.

Field events (Admin & permission activity)(2.6.2)

Events affecting custom fields and their contexts: a field added, changed, deleted, moved to the trash or restored, and a field context added, changed or removed. Often the most subtle category and the one auditors ask about most.

Field events (Configuration changes)(2.2.2)

Configuration events specifically affecting custom fields and their contexts: fields added, changed, deleted, moved to trash or restored, plus field contexts added, removed, or reconfigured. Often the noisiest category in a healthy admin practice. Counts the selected date range in whole weeks: a week is included when it falls entirely inside the range, and the week in progress is included when the range reaches it.

First Response Time(2.7.11)

How long new issues wait before someone first responds: a comment by anyone other than the issue's reporter, or the issue's first move out of the opening status, whichever comes first. A comment or a status move by an app such as Automation for Jira or by a service-desk customer is not counted on either arm, and the number of issues that received one is shown beside each project on the panel; responses by accounts Jira returned no type for still count. A leading indicator of responsiveness that is separate from how long the work then takes to finish. Projects with too few measured responses are listed with their response count and no figures, rather than with a value a handful of observations cannot support. Typical response and tail response are drawn on two separate charts: the first carries the median, the second the 90th percentile. The average and the 99th percentile are measured but not drawn. The average is set by the same slow responses the tail chart already shows, so beside the median it took the axis and left it flat on the floor; hover a bar on the typical chart for the project's average. The 99th percentile tracks how long the project has been recorded rather than how quickly anyone answered, and beside the other bars it did the same. A long tail usually points at intake and triage rather than at execution: the question it raises is who is expected to pick up a newly created issue, and within what time.

Flow Performance & Variant Explorer(5.11.1)

An interactive map of your real workflow with timing laid over it: each move between steps is shaded from green to red by how long work typically waited before it, the most visited steps are drawn larger, and a list below the map ranks the distinct routes work takes end to end, each labeled by the steps it passes through — click one to trace it on the map. A date slider replays the workflow as it looked at any point in time, and median-to-85th-percentile figures show both the typical case and the slow tail. The end-to-end cycle figures cover delivered issues only, counted under your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); discarded work does not enter them. A side panel ranks the statuses where work waits longest over the project's whole history; statuses in Jira's Done category are grayed and listed last, because work there has finished. Use it to find the steps and routes that quietly stretch out delivery. It builds on the workflow shown in Workflow Discovery — configure your status and actor groupings there. Step timings use the full length of every recorded wait with no upper limit applied, and a wait is counted only once work has moved on, so a step currently holding parked work can appear faster than it is.

Governance Maturity Score by Project(4.4.5)

Grouped horizontal bar chart per project across the governance dimensions that can be measured per project: Workflow Adherence and Control Coverage (0-100 each, latest complete week). Configuration stability is site-scoped, so it is shown as its own site-wide chart rather than a per-project bar. A project low on Workflow Adherence is completing work that skips the working states its workflow defines; low on Control Coverage means delivered resolutions are landing without worklogs or via skipped states (abandoned outcomes are not resolutions). Use Deep Analysis to get an AI-generated read on which projects' dimension gaps argue for targeted versus broad governance investments. Both dimensions are read from the same completions, so a project with no completions in the week draws no bars at all and is counted in the note above the chart rather than shown at zero.

Governance Maturity Trend(4.4.10)

Multi-line time series of weekly composite governance maturity score per project, with a dashed red line at 60 marking the minimum-maturity threshold. Below the line requires intervention; above the line is in steady state. The single line for "are we maturing or backsliding"—rising during a maturity program, flat in established practice. Use Deep Analysis to get an AI-generated read on which trajectories signal genuine maturity gains versus tactical fixes that may regress. Weeks that cannot measure both dimensions are left unscored and appear as a gap in the line rather than as a low score.

Growing weeks(2.4.4)

How many complete weeks in the selected range the backlog grew, with arrivals outpacing resolutions. Three or more is a useful trigger for planning-room conversations about capacity versus scope. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

High issues (severity tile)(5.4.12)

Current count of tickets in the High severity tier of the sensitive-data detector. High items are still meaningful and worth review, even if Critical takes immediate priority.

High SoD risk actors(5.6.4)

Contributors whose work is most concentrated in moving issues through the workflow—at least 60% of their status transitions, comments and assignment changes are transitions, counted only for contributors with at least 20 such actions. The count covers people's accounts; app accounts such as Automation for Jira, service-desk customers and accounts Jira returned no type for are shown beside it, never counted as people. Usually a small number; their patterns are the ones an access review looks at first. A zero here is a measured zero, not an absence of data: the table below lists every actor, with the share behind each one that has at least 20 workflow actions. The card shows a dash when no contributor reaches 20.

High-drift actors(5.3.3)

Actors with the highest composite permission-drift scores—those whose recent activity pattern includes the most permission-altering events. Usually small in number; the list is a useful daily check for compliance reviewers. The count is split by the type of account Jira reports: people's accounts form the headline, and apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside it, never inside it.

High-Risk Issue Forensic Event Timeline(3.3.10)

For a selected high-risk ticket, a chronological timeline of every significant event in its lifecycle—creation, status changes, priority changes, assignee changes. Shows exactly how the ticket accumulated its current risk profile and which intervention opportunities were missed along the way. For compliance audits, this is the record demonstrating due diligence on high-risk tickets. Use Deep Analysis to get an AI-generated narrative of the timeline—what likely happened, what the warning signs were, and what to prevent next time.

High-risk projects(3.1.1)

How many of your projects scored 70 or above on the bypass risk gauge over the trailing 90 days. That is the band where most of a project's recent status transitions either skipped straight to done or came back out of it. Projects with fewer than 10 transitions in the window carry no score and are not counted here, and neither are projects with no bypasses at all. A non-zero count is your weekly "go look here first" signal.

Highest peak ratio(3.2.3)

The biggest spike-to-baseline ratio observed over each project's whole recorded history—for example, "5.2x the recent average". A useful at-a-glance read on the most extreme outlier. The average covers complete days only. The day in progress is shown in the totals but does not enter the average. This card is deliberately not bound to the date filter: it is a lifetime worst-case, so an extreme spike stays on the record after it leaves the selected range. The other cards beside it do follow the filter.

Highest project score(3.6.4)

The single highest project-level risk score in your portfolio right now. If the same project tops the list for three or more weeks, structural intervention beats incremental fixes. Weeks measuring fewer than two of the three signals are left unscored and cannot appear here. A value shown as "—" means the read returned nothing or the figure could not be measured. It is never to be read as a zero: a measured zero is printed as a zero, and a card with no figure also carries no accent color, because a tint is a judgment about a number and there is no number to judge. The date range selects whether the portfolio snapshot appears at all, while the figures themselves are still taken from each project's latest complete scored week. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Highest risk score(3.3.3)

The single highest current risk score in your portfolio. Look at the ticket behind it; if it's been holding the top slot for weeks, it deserves a dedicated work session, not another sprint of "we'll get to it". A reading of 0 is a measurement—the highest-scoring open ticket scored zero—while a dash means there was no scored open ticket to take a maximum of.

Hourly Activity Density(5.6.9)

Heatmap of activity volume by day-of-week and hour-of-day in the organization's time zone—establishes the team's normal working rhythm so anomalies become visible. A team working 9-to-5 weekdays shows a very different shape from a globally distributed team, and both are valid; understanding the normal pattern is the prerequisite for spotting deviations. Each cell's count is split by the type of account Jira reports: people's events form the headline, and events by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside them, never inside them, so a bright cell outside the dominant pattern can be read by the kind of account that recorded it. Use Deep Analysis to get an AI-generated read on your team's working pattern and which deviations look most worth following up.

In warning zone(3.5.2)

How many open tickets have used 80 to 100 percent of their SLA target: close to breaching, with some of the target still left. A ticket counts as open when the latest status MetaFrazo recorded for it is in a to-do or in-progress category; tickets whose deletion was recorded, and tickets in a project moved to the trash or deleted, are left out. Age runs from the creation time Jira records for each ticket. Tickets whose recorded events carry no creation time cannot be aged and are not counted here; the SLA Breach Clock shows them in its age-unknown segment, so while that segment is not empty read this number as a floor.

Inactive count(3.3.4)

How many High- or Highest-priority open tickets have gone seven days or more without a recorded event, as listed by the Inactive High-Priority Issue Detector. The most expensive category: high consequence and no one moving on it.

Inactive High-Priority Issue Detector(3.3.8)

Surfaces high-priority tickets that have not had a single event in seven days—the silent risk pool. A ticket counts as open when the latest status its events record is in Jira's To Do or In Progress category, including one that has not changed status since MetaFrazo was installed; a ticket deleted in Jira or in a trashed project is not listed. Inactive doesn't mean forgotten by accident; it could also be blocked or parked. But in any of those cases, the ticket represents unacknowledged risk that needs explicit acknowledgment. Each ticket here should pair with a standup answer: why is this not moving, and what's the next step? Use Deep Analysis to get an AI-generated read on which inactive tickets look blocked versus forgotten, and what to follow up first.

Inactive Project Bucket Distribution(5.10.4)

Bar chart splitting the project portfolio into activity buckets: active, slowing, dormant, abandoned, archived, and deleted. When dormant, abandoned, and archived together exceed roughly a third of the portfolio, project pickers and filters are returning stale results, and a cleanup cycle usually pays back quickly. If dormant projects are sitting in abandoned rather than archived, the tenant isn't closing projects out properly. Use Deep Analysis for an AI read on which projects to retire first and where cleanup has the biggest impact.

Inactive project ratio(5.10.1)

Of the projects that have ever emitted activity, the share that have gone silent or are formally archived—split across active, slowing, dormant, abandoned, and archived. A high dormancy share usually means the project list is hiding work that should be wrapped up or closed.

Incident Resolution Time (MTTR)(3.4.8)

Distribution of resolution times split into two cohorts: tickets resolved without reopening, and tickets reopened at least once before final resolution. A resolution here is the first closing status classified as delivered under your organization's terminal-status settings (a MetaFrazo default applies until configured); issues discarded or canceled without delivery carry their own disposition and are excluded from the resolution stats. Mean time to recovery is usually quoted as one average; this view shows the whole distribution behind it, with the median and the 90th percentile marked for each cohort. A long right tail in either cohort means a minority of issues took far longer than the rest. Use Deep Analysis for a read on the slow end of the distribution and the questions it raises.

Incident Temporal Heatmap(3.4.7)

Calendar heatmap of when incidents happen by day-of-week and week-of-month. Reveals temporal patterns the team often hasn't noticed—always Monday after deploys, end of month under release pressure, every quarter-end. Understanding the temporal pattern is the first step to breaking it; a flat heatmap suggests incidents are randomly distributed rather than driven by predictable triggers. Use Deep Analysis to get an AI-generated read on which calendar patterns stand out and what process change would attack them.

Inflow Source Attribution(3.2.7)

Per-week breakdown of backlog inflow by source—newly created tickets, tickets returned from active states, reopened terminal tickets. Knowing why a spike happened is what lets you respond correctly. A spike dominated by new creations signals unexpected demand (scope creep, external trigger, planning failure); a spike dominated by returned-from-active is WIP instability; a spike dominated by reopens is a quality signal. Use Deep Analysis to get an AI-generated read on the most likely source of your recent spike and what response it actually warrants.

Intake vs Outflow Trend(2.1.13)

Compares the rate of new ticket arrivals against ticket resolution, day by day. When the resolution line dips below the arrival line for several weeks, the backlog grows even if individual sprints feel healthy. A widening trend over multiple weeks is the structural signal that capacity does not match intake; consistent convergence is the healthiest pattern. The view exposes asymmetries that average aggregates would mask.

Issue Age at Backlog Entry During Spikes(3.2.8)

Breaks down each spike's tickets by age at the moment they entered the backlog—distinguishing genuine new demand from delayed-triage backlog dumps. A spike dominated by same-day issues is a real demand surge that may require a capacity response; a spike dominated by older issues is a triage event (the work isn't actually new, just newly visible). A mix of ages indicates a combined event needing both responses. Use Deep Analysis to get an AI-generated read on the composition of your recent spike and what response shape it argues for.

Issue Reassignment Hotspot Leaderboard(2.5.8)

A ranked list of tickets with the highest reassignment counts, flagging those handed off three or more times. Tickets with no current owner are the highest priority since they're stuck with no responsible party, and a ticket bounced five or six times usually points to unclear requirements or a task no one wants; clustering within one epic signals a scoping problem. Use Deep Analysis to get an AI-generated read on which hotspots share a root cause and what clarification work would resolve them.

Issue type events(2.6.3)

Events affecting issue types: an issue type added, changed or deleted. Each change touches every ticket of that type.

Issue Type Reclassification Flow(3.4.9)

Tracks how often tickets are reclassified between types after creation, such as a Bug becoming a Task. Some reclassification is routine, but a consistent pattern reveals a gap in how work is categorized at intake. Use Deep Analysis for a read on whether your reclassification flows look routine or structural, and whether any pattern points to an intake-process design problem.

Issue-Level Field Change Heatmap(2.2.7)

A heatmap of daily change counts for governance-sensitive fields (assignee, priority, issue type, reporter, project, due date). Persistent assignee churn suggests ownership isn't clearly defined; frequent priority changes indicate scope isn't well understood at planning. Unexpected reporter or project changes should be rare and warrant investigation. Use Deep Analysis to get an AI-generated read on which field's churn is most diagnostic and what it points at.

Issues in breach(3.5.1)

How many open tickets are past their SLA target right now. A ticket counts as open when the latest status MetaFrazo recorded for it is in a to-do or in-progress category; tickets whose deletion was recorded, and tickets in a project moved to the trash or deleted, are left out. Age runs from the creation time Jira records for each ticket, so a ticket created before MetaFrazo started recording is aged too. Read it with the SLA Breach Probability per Open Issue table to decide which tickets to escalate first. Tickets whose recorded events carry no creation time cannot be aged and are not counted here; the SLA Breach Clock shows them in its age-unknown segment, so while that segment is not empty read this number as a floor.

Latest governance score(3.1.3)

The most recent MetaFrazo Governance Score, averaged across all projects that reported that day, on a 0-100 scale — a single read across workflow discipline and control coverage. A sustained drop of more than ~5 points is worth a look. How it's calculated: MetaFrazo Governance Score. This card reads the latest complete day that produced a measurement, and names the day it read. A day with no delivered completions carries no score, so the card looks back past it rather than showing nothing.

Latest spike date(3.2.4)

When the most recent spike happened. If "yesterday" you may still be processing the surge; if "three weeks ago" you can safely assume the system has rebalanced. The day in progress is not evaluated until it is complete, so the earliest date this can show is yesterday. While no day in the window has a baseline yet, the card shows "Collecting data" rather than a dash.

Lead Time by Priority(2.7.6)

Average lead time and the worst single-day project P90 per priority level, measured from creation to first delivered transition under your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); issues closed as discarded or canceled are excluded from the timing and shown in the abandoned count. Priority is read at delivery: the value recorded when the issue was created, updated by the last recorded priority change before delivery; issues whose priority was never recorded appear as None. A large gap between Highest and Low average lead times is what working priority triage looks like; similar averages between High and Medium suggest these two levels aren't being treated differently and one is redundant. A worst-day P90 far above the average for any priority means delivery is inconsistent—some tickets in that category take much longer than others for unclear reasons. Use Deep Analysis to get an AI-generated read on whether your priority scheme is functioning as designed.

Lead Time Impact: Reopened vs Direct-to-Done(2.3.9)

A grouped bar chart comparing average time to final delivered resolution for tickets delivered without reopening versus those reopened at least once, putting a concrete day count on what rework costs. Issues whose last terminal transition is a discard never reached final delivery; they are excluded from both cohorts and counted separately (your organization's terminal-status settings decide what counts as delivered, with a MetaFrazo default until configured). A large multiplier is a strong case for better acceptance criteria, clearer requirements, or earlier testing; a small gap means reopens are handled efficiently. Use Deep Analysis to get an AI-generated read on what the multiplier implies for your team's process investments.

Lead Time Trend by Issue Type(4.3.10)

Multi-line chart of weekly average lead time (days from the creation MetaFrazo recorded to the first delivered resolution; an issue created before MetaFrazo was installed, or whose creation MetaFrazo did not record, is left out) broken down by issue type, averaged across every project in scope and weighted by the number of issues each project delivered, so a project delivering one issue does not move the line as far as one delivering fifty; whether a terminal status means delivered follows your organization's terminal-status settings (a MetaFrazo default applies until configured), and weeks whose closures were all discards show zero delivered issues with a nonzero abandoned count. Diverging trends between issue types show where the time to deliver moved for one kind of work and not another: if Bug lead time held steady while Feature lead time doubled in the last quarter, features took twice as long to deliver while bugs did not, and a reviewer could ask what changed for that work. Use Deep Analysis to get an AI-generated read on which type's lead time moved most and the questions it raises.

Low issues (severity tile)(5.4.14)

Current count of tickets in the Low severity tier of the sensitive-data detector. A ticket lands here when neither the email pattern nor the phone-shaped-digit pattern matched it, so its only match is a standalone run of 6 to 12 digits. Digits that are part of an Atlassian account id, such as the one behind a mention of a colleague, or of an identifier in the standard UUID format, such as the id of a file embedded in a comment, do not count. Nor do the digits Jira writes into a comment's own formatting, such as the file name of a pasted screenshot; digits in a link address do. That is the weakest of the three patterns: a run of digits is a candidate for personal data, not a finding of it, and many turn out to be internal reference or ticket numbers. This tier grew when the phone-shaped-digit pattern was tightened, because entries that no longer band higher fall through to here. Read a rising count as a prompt to sample a few entries, not as a remediation backlog.

Lowest MTBI(3.4.3)

The smallest mean time between incidents seen across any of your projects. A low MTBI on a single project surfaces it as the natural candidate for a focused reliability investment. A 0.0d reading is the lowest this metric goes — two or more incidents averaging under about 72 minutes apart — while an em-dash means the gap is not measurable, because a single-incident project has no pair to measure between.

Medium issues (severity tile)(5.4.13)

Current count of tickets in the Medium severity tier of the sensitive-data detector. Often the largest tier; cleaning here is the structural fix rather than the urgent one.

Mined Petri Net(5.9.1)

An automatically discovered map of how work actually moves through your statuses, inferred from thousands of observed transitions rather than the workflow you documented. Unexpected shortcuts and dead-end states stand out: a direct path your documented workflow does not include is a route work actually takes, and a reviewer could ask whether it is a routine workaround. A map that matches your documentation shows the recorded transitions follow the documented routes. This is the structure view; for how long work waits at each step and which routes are slowest, use Flow Performance, which lays timing over the same map.

Missing Approval Heatmap(5.2.9)

Heatmap of projects against issue types, where each cell shows the share of delivered closures that were both zero-comment and single-actor: no comment other than one posted by an app or a service-desk customer appears in the issue's recorded Jira history, and the person who closed it also created it. MetaFrazo calls this share the missing-approval rate; it shows what Jira recorded, not whether a review happened elsewhere. Closures into abandoned-classified statuses are backlog hygiene and are not counted (a MetaFrazo default applies until configured). A dark cell shows where the pattern concentrates, for example Bugs in one project, and a reviewer could ask how review is recorded for that kind of work there. Each closure is attributed to the type of account that closed it, as Jira reports it: the rate covers closures made by people, and closures by apps such as Automation for Jira, by service-desk customers, by accounts Jira returned no type for and by erased accounts are shown beside it, never counted as a person's. A comment posted by an app or a service-desk customer does not clear a closure; a comment by any other account does, including one by an account Jira returned no type for and one by an erased account. Use Deep Analysis to see which cells stand out and the questions they raise.

Most-Reopened Issues Leaderboard(2.3.8)

A ranked table of tickets with the highest reopen counts, including project, issue key, summary, reopen count, and a risk badge (High at two or more reopens). Several high-risk tickets in the same project mean the reopens concentrate there; the events do not say whether requirements, design or execution explain them. Use Deep Analysis to get an AI-generated read on which repeat reopens stand out and the questions they raise.

Net Backlog Change(4.3.2)

Net change in backlog size in the latest complete week—positive means the backlog is growing, negative means shrinking. The single number that says whether you're catching up or falling behind. This card reads the latest complete week and names the week it read. The week in progress is left out rather than counted: new issues are recorded the moment they arrive while closures accumulate across the week, so a part-finished week overstates backlog growth every week of the year rather than only sometimes. If the only week in the selected range is still in progress, no number is shown. The chart below still plots the week in progress.

New Actor Burst Detection(5.3.6)

Flags new actors whose first-week activity far exceeds the typical debut of people's new accounts; debuts by apps, service-desk customers, erased accounts and accounts with no type do not move that burst threshold. A moderate first week is normal onboarding; an unusually high one may indicate account takeover, improper access provisioning, or an app account given broad access. Multiple burst actors in the same period often signal a systematic provisioning gap. Each new actor is labeled with the type of account Jira reports for it, so people's debuts are counted apart from new apps such as Automation for Jira and service-desk customers, and an account with no type is shown as unknown. Use Deep Analysis to see each flagged actor's activity shape and whether the access pattern justifies an immediate review.

Off-hours actors flagged(5.6.3)

Number of contributors whose off-hours activity exceeds the threshold, with off-hours measured in the organization's time zone. Apps such as Automation for Jira and service-desk customers keep no working hours, so they are excluded from this count and their number is shown beside it; accounts Jira returned no type for are still rated, because they may be people. Sustained off-hours work is a pattern worth raising with the team, in addition to being a review signal.

Off-Hours Events by Actor(5.6.7)

Per-actor share of total events that occurred outside business hours, measured in the organization's time zone. Some off-hours activity is expected, but an actor well above roughly a quarter warrants explanation—it may indicate automation running under their credentials, work timed outside the hours colleagues are active, or simply unusual personal hours. Combined with other signals, high off-hours actors become a stronger investigation target. Each actor is labeled with the type of account Jira reports for it: apps such as Automation for Jira and service-desk customers keep no working hours, so they are shown apart from people and never flagged; accounts Jira returned no type for are rated like people, because they may be people. Use Deep Analysis for an AI read on which off-hours patterns look role-driven or worth a conversation.

Off-Hours Transitions(5.1.8)

Calendar heatmap of status transitions happening outside business hours—early, late, or on weekends, measured in the organization's time zone. Off-hours activity alone is not suspicious, but recurring volume is, and combined with rapid or backward transitions it becomes a stronger signal. Each transition is attributed to the type of account Jira reports for it, so transitions by apps such as Automation for Jira, by service-desk customers, by accounts with no type, by erased accounts or with no recorded actor are counted apart from people's. Use Deep Analysis to see whether the pattern comes from apps, from people's after-hours work, or is something to review.

Open Issue Age Distribution(4.2.7)

Heatmap of issue counts per project across four age buckets: 0-7 days, 8-30, 31-90, 90+. Darker cells mean more open issues in that age band. Age runs from the creation time Jira records for each issue. An issue created more than 90 days ago that is open now lands in the 90+ band however recently it last changed, because age runs from creation, not from the latest update. Concentrations in the 0-7 day band are recent intake; concentrations in 90+ are issues created months ago that are open now. Use Deep Analysis to get an AI-generated read on which projects hold the most old open work and the questions it raises.

Overall compliance(2.7.1)

Overall percentage of delivered tickets that met their SLA target in the window, counted under your organization's terminal-status settings (a MetaFrazo default applies until configured). Tickets that ended in a status classified as abandoned are not counted either way: abandoning a ticket is a scope decision, not an SLA outcome. The percentage is shown only once at least five tickets were delivered in the window; below that the card shows the delivered count instead, because a rate over one to four tickets is a coin flip rendered as a measurement. The headline number for "how well is the team hitting commitments"; the visuals below explain where any miss is coming from.

Overall reopen rate(2.3.1)

The share of completion events in the selected window that were followed by a reopen, across your selected projects. Both sides are counted inside the window, so the figure moves with the range you pick. A sustained value above 10-15 percent is usually where teams start looking at their definition of done or their acceptance testing.

Ownership Gap Detector(2.5.7)

A per-project breakdown of OPEN unowned tickets by workflow status, separating unowned-in-backlog from unowned-in-progress. A ticket counts as unowned whether it was never assigned to anyone or lost the assignee it had; closed tickets, deleted tickets, tickets in a project moved to the trash or deleted, and tickets whose events record no status that maps to a Jira status category are excluded, and a ticket that moved between projects counts once, under its current project. Unowned in-progress work is work in flight with no assignee on record; a large unowned backlog count means issues are being created without being assigned. Use Deep Analysis to get an AI-generated read on which ownership gaps sit in progress and which come from intake that was never assigned.

Pending invites(8.3)

How many invitations you've sent that haven't been accepted yet. A consistently high number is usually a sign that invites are landing in spam filters or that recipients need a nudge.

Period start(3.6.12)

The starting date of the rolling window the escalation scores cover. Helps reviewers understand whether they're looking at last week's snapshot or a quarterly summary. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Permission Drift — Category Breakdown (mini)(1.10)

Splits recent admin-level events into four buckets: user, field, issue type, and project. A sudden field-level spike without related user changes means custom fields or their contexts were reworked rather than people added or changed, making this a useful daily compliance touchpoint.

Permission drift events(1.3)

How many admin-level changes have occurred over the recent window: user accounts added, changed or removed, and changes to fields and field contexts, issue types, projects, components and filters. Spikes are worth a quick second look from a compliance perspective.

Permission Drift Score by Actor(5.3.10)

Per-actor composite score that rolls three permission-drift signals—reporter changes, how many projects the actor was active in, and their self-assignment rate—into one value, so investigators don't have to correlate them by hand. High scores suggest a pattern rather than coincidence; mid-range scores warrant monitoring. Most actors sit safely low; the top few are where targeted investigation pays. Each actor is labeled with the type of account Jira reports for it (a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type), so an app account's score is read as the app account's, by Jira's own record. Use Deep Analysis to walk through each high-risk actor's signal mix and where to focus.

Permission-change score(2.6.5)

A volume score capturing how much your permission landscape moved in the window, counting user, field, issue type and project events equally: Low under 100 events, Medium 100 to 300, High above 300. Useful for setting an internal threshold for "review this week".

PII Detection Trend(5.4.7)

Weekly detected events as bars, with the detection rate (detections as a percentage of all events) as a line on its own axis. The rate is the more meaningful reading, since a busier portfolio naturally has more detections. A falling rate as activity grows means hygiene is improving; a rising rate signals that the share of work generating exposure is increasing. The detection count combines the email-pattern and phone-shaped-digit arms, which differ sharply in confidence, so check the type distribution above before reading a move as an email problem. Use Deep Analysis to see what's driving the direction and what to do about it.

PII Detections by Project(5.4.5)

Distribution of detected personal-data events across your projects, broken down by type (email pattern, phone-shaped digits, numeric ID). A project with a high count has a data hygiene question to answer: personal data may be landing in issue text that was probably not meant to hold it. The dominant type shows which pattern appears most. A project with zero detections may hold none of these patterns or simply be low on text, so context matters. Use Deep Analysis to see which projects carry the most detections and which pattern dominates.

PII Risk by Actor(5.4.8)

Per-actor count of events containing detected patterns, split into the email-pattern arm and the much looser phone-shaped-digit arm so the two are never read as the same finding. Meant to show where targeted awareness training will help most. Most people include personal data accidentally, often by copy-pasting from emails or support tickets, and this is not a disciplinary ranking. An actor whose bar is mostly digit runs is usually pasting build or reference numbers, not customer data. Declining counts on an actor show prior guidance landed. Each actor is labeled with the type of account Jira reports for it (a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type), so text recorded under an app account or a service-desk customer's account is read apart from people's. Use Deep Analysis to see which actors' counts stand out and which patterns are spread across the team.

PII Severity Score Distribution(5.4.10)

Distribution of detections across four severity tiers, from Critical down to Low. Not every detection carries the same weight: a phone-shaped digit run found while a ticket was closed differs from email-plus-digits found while it was active. Critical counts issues where an email pattern and phone-shaped digits appeared on the same event while the issue was open; a large Medium count matters too, because a pattern detected while an issue was closed can still sit in its text. Low is the numeric-ID-only tier and carries the highest false-positive rate. Use Deep Analysis to see which Critical entries stand out and the questions each tier raises.

PII Type Distribution(5.4.6)

Breakdown of all detected events by pattern across the portfolio. The three patterns carry very different confidence, so the mix tells you how much of the total to trust before it tells you where to remediate. A portfolio dominated by email matches usually points to copy-paste from customer communications. A portfolio dominated by phone-shaped digits or numeric IDs is more often long internal reference numbers, and warrants a sample review before anything else. Use Deep Analysis to see the likely sources of each type and the most leveraged remediation.

Portfolio Actor Coverage(4.1.10)

Bar chart of unique active actors per project per week plus an events-per-actor ratio. Shows which projects record activity from only a few people: in a project with one or two active actors, all of the attributed activity comes from those accounts. A very high events-per-actor ratio means many recorded events per active person; it is an average, so it does not show how the events split among those people. Where a project-week's events name no identifiable actor, active actors is a measured 0 and its bar is drawn, while the events-per-actor ratio has no divisor and is withheld—no ratio bar appears for that week, and the tooltip reads "not measured (no actor attributed this week)" instead of 0. Active actors and the ratio count people's accounts as Jira reports the account type: apps such as Automation for Jira and service-desk customers are left out, and accounts Jira returned no type for are shown beside the people's figure. Use Deep Analysis to get an AI-generated read on which projects record activity from the fewest people and the questions that raises.

Portfolio avg score(3.6.3)

The average risk score across all your tracked projects—a one-number portfolio health summary. Useful as the headline metric for monthly business reviews. Weeks measuring fewer than two of the three signals are left unscored and are excluded from the average. A value shown as "—" means the read returned nothing or the figure could not be measured. It is never to be read as a zero: a measured zero is printed as a zero, and a card with no figure also carries no accent color, because a tint is a judgment about a number and there is no number to judge. The date range selects whether the portfolio snapshot appears at all, while the figures themselves are still taken from each project's latest complete scored week. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Portfolio Composite Score(4.4.1)

A blended governance score across the portfolio: the average of the per-project dimensions that can be measured (workflow adherence and control coverage). The single number used to communicate governance posture to executives and external reviewers. Site-wide configuration change activity is shown separately, since configuration is site-scoped rather than per-project. This card reads the latest complete week and names the week it read. The week in progress is left out rather than averaged: only the projects that have already logged events appear in a part-finished week, so its value would be an average over a different set of projects rather than an early reading of the same one. If the only week in the selected range is still in progress, no score is shown. The charts further down the page are not all restricted this way; the Governance Maturity Score by Project and Workflow Adherence Score by Project charts read the same complete week as this card, and the others can still include the week in progress. Both dimensions are read from the same completions, so a project-week with no completions can measure neither and drops out of this average rather than being scored from a single dimension, and the card shows a dash when no project in the week clears the bar. The event counts behind every project-week are still recorded, rated or not.

Portfolio Health Score Matrix(4.1.5)

A project-by-dimension heatmap scoring every tracked project on velocity, quality, and workflow adherence on a 0-100 scale. Each cell is the average of that project's weekly scores across the complete weeks of the selected window, so it summarizes a period rather than a moment. A project critical (red) on all three is the one a reviewer would ask about first; a healthy velocity score beside a critical quality score often means a team recording plenty of issue progress while reopening a large share of it. A cell reads "—" where the underlying weeks carried too few events to support a score or, for workflow adherence, where the project moved no issue into a done status. Most useful as the opening visual in monthly business reviews. Use Deep Analysis for a read on which health patterns are most diagnostic and which conversations to prioritize.

Portfolio Issue Type Mix(4.1.7)

Stacked 100 percent bar chart showing the share of each issue type (Bug, Story, Task, etc.) per project, counting each issue once over the complete weeks of the selected range, under the type it carried at its latest activity in that range. A project dominated by Bugs is spending capacity on remediation rather than value delivery; a sudden shift in the mix usually signals either a quality regression or a deliberate cleanup cycle. Useful for executive scoping conversations—the mix tells you what each project's quarter is actually about. Use Deep Analysis to get an AI-generated read on which projects' mix shape argues for what kind of investment.

Portfolio Quality Index(4.1.8)

Weekly quality index per project (0-100, computed as 1 minus the reopen rate multiplied by 100, where the reopen rate is the week's reopens as a share of the work the project completed that week). A week is scored only when the project completed at least five issues that week: below that a single reopen moves the index by twenty points or more, so the week is left unscored rather than given a number the volume cannot support, and the line breaks instead of dipping or spiking. The completion count is always shown, so you can see why a week was not scored. A week can read below zero, because a reopen may undo a completion from an earlier week; that is reported as measured rather than raised to zero. A reopen is a transition out of a terminal status classified as delivered back into the workflow; reviving an issue that had been closed as abandoned or duplicate is not a reopen and is reported separately in the revived column. Whether a terminal status means delivered or abandoned is your organization's terminal-status setting where configured, and a MetaFrazo default read from the status name otherwise. Measuring reopens against completions rather than against all recorded activity keeps cross-project comparison apples-to-apples: a project cannot raise its score by editing more fields. A sustained downward trend on any single project is the leading indicator of structural quality drift; both lines climbing together is what successful quality interventions look like. Use Deep Analysis to get an AI-generated read on which projects' trajectories look durable versus tactical.

Portfolio Resolution Velocity(4.1.9)

Grouped bar chart of the weekly count of issues delivered per project, with week-over-week delta. An issue counts as delivered when it reaches a terminal status whose disposition is delivered under your organization's terminal-status settings; a MetaFrazo default reading of the status name applies until you configure one. Issues closed into an abandoned or duplicate status are reported separately in the abandoned column of the same row. Enables cross-portfolio execution comparison and surfaces acceleration or deceleration patterns at a glance. A project resolving more in its latest complete week than in the week before is healthy momentum; sustained deceleration usually points at a capacity, dependency, or scope issue worth investigating. Use Deep Analysis to get an AI-generated read on which projects' velocity shape is most diagnostic of an underlying constraint.

Portfolio Risk Composite Score Trend(4.2.5)

Multi-line time series of composite risk score per project per week, with a 70-point reference line marking the escalation boundary. The single most-watched line on the executive dashboard: a sustained downward trend means the scores behind it are falling, though the line does not show why. Projects crossing the 70-point line are the agenda for the next governance review; projects approaching it without crossing yet are where preventive attention has highest leverage. Use Deep Analysis to get an AI-generated read on which projects' trajectories are moving toward the 70-point line and which are moving away from it. Weeks measuring fewer than two of the three inputs are left unscored and appear as a gap in the line rather than as a low score. The score is expressed against the inputs that week could measure, so it runs from 0 to 100 in every scored week; a week without completions is scored on its reopen share and event volume alone. The reopen share counts reopens against the week's status transitions, not against every field edit, and is rated only in a week with at least five of them; the bypass share is rated only from five completions. A week that can rate neither share is left unscored rather than scored on its event volume alone.

Portfolio Workflow Anomaly Heatmap — Project × Week(3.1.11)

A color-coded grid of every project against every week in one executive view. A whole row of dark cells is a project scoring high week after week rather than in a single week; a whole dark column points to a portfolio-wide event such as a deployment or process change. Use Deep Analysis for a read on which patterns are chronic versus episodic and where leadership attention pays best.

Post-Creation Priority Changes(5.5.7)

Tracks priority changes after ticket creation, separating escalations from de-escalations. Some change is normal, but a steady pattern of de-escalations means priorities set at creation are being lowered later, and a reviewer could ask whether that reflects triage correcting itself or targets moving after the fact. A balanced, low-volume distribution indicates stable, accurate initial prioritization. Use Deep Analysis for an AI read on which projects change priorities most after creation, and in which direction.

Priority and Assignee Drift by Project(2.2.10)

A grouped bar chart per project showing counts of assignee and priority changes, ranked by a composite drift score. High assignee drift often means ownership is unclear at planning; high priority drift suggests priorities aren't well-calibrated at sprint planning, while low scores mark well-planned, well-owned projects. Use Deep Analysis to get an AI-generated read on which projects' drift is structural and what planning intervention it argues for. Counts cover the selected date range only.

Priority deviations(5.5.3)

Number of priority field changes that happened after ticket creation. Some are inherent to triage; persistent changes raise the question of whether priority is tracking urgency or something else, such as the SLA clock a priority sets. This total covers every week in the selected range, including the week in progress.

Priority Escalation Tracker(3.3.7)

Tracks tickets whose priority has been escalated after creation—a signal that something was underestimated when the ticket was opened. Frequent escalations on a single ticket usually mean the team is using priority changes to express urgency the original spec missed. Tickets that escalate often go through more reopens and reassignments than the average—the priority change rarely solves the underlying scope problem. Use Deep Analysis to get an AI-generated read on which escalations are catching real urgency versus papering over a scoping miss.

Priority-Adjusted Breach Heatmap(3.5.7)

Heatmap of SLA breach rate by priority, measured over delivered tickets only under your organization's terminal-status settings (a MetaFrazo default applies until configured). A cell whose endings were all abandonment shows no rate and carries its abandoned count instead. A cell with fewer than five delivered tickets shows no rate either: one breach among two deliveries is 50 percent by arithmetic and nothing by evidence, so the cell is left unrated and its delivered count is shown instead. Priority here is the priority in force when the ticket was delivered, taken from the creation baseline and any later change; tickets whose priority never appears in the event stream group under Unknown rather than an assumed tier. Each ticket is measured against a target resolved from your configured SLA policy by issue type where set, and a MetaFrazo default otherwise, so the target never depends on priority. SLA breaches are not uniformly distributed: a project meeting its SLA for Medium tickets but consistently breaching on High priority misses its targets at the top of the queue, not across its delivery. Where breach rates fall as priority rises (Highest breaches least), urgent work is moving fastest; where the pattern is inverted, a reviewer could ask whether raising a ticket's priority speeds it up. Use Deep Analysis to get an AI-generated read on which priority+project cells are most diagnostic and the questions they raise.

Project Compliance Leaderboard(5.7.9)

Leaderboard ranking every project by its governance score in its own most recent completed week, best first. Green is at or above 80 (on target), amber is 60-79 (watch), red is below 60 (immediate attention). Bars do not share a calendar week, and a project whose own latest completed week carries no score is left off the board rather than drawn at zero. Distinct from the Executive Portfolio Health Matrix in section 4—that is multi-dimensional health; this is a single-metric compliance ranking designed for the compliance team's weekly cadence. Use Deep Analysis to get an AI-generated read on which projects are on the move (up or down) and what's driving each direction.

Project Configuration Mutation Log(2.6.10)

A table of project configuration mutations — the "where" view of schema governance. Projects with disproportionately high field or issue-type change counts are candidates for a schema review, while the Global row typically reflects bulk migrations or system-level changes worth understanding. Use Deep Analysis to get an AI-generated read on which projects' mutation pattern looks healthy and which need cleanup.

Project events (Admin & permission activity)(2.6.4)

Events at the project level: a project created, its settings changed (such as its name or lead), moved to the trash, restored, archived or deleted, plus components and filters added, changed or removed. The biggest blast-radius category; each one is worth a quick look.

Project events (Configuration changes)(2.2.4)

Configuration events touching projects themselves: creating a project, changing its settings (such as its name or lead), moving it to the trash, restoring, archiving or deleting it. Less frequent but each event tends to have a bigger downstream effect on the dashboard.

Project Risk Ranking(4.2.8)

Ranked table of every tracked project by its most recent complete week's composite risk score. A project whose week carries fewer than 10 status transitions is shown as not scored rather than ranked: below that a single transition moves the score by more than half a tier band, so the position and the badge would report arithmetic rather than a measurement. The ranking covers the scored projects only, and a project that is not scored is placed in neither direction. Columns include project name, current score, week-over-week change, and risk tier (Low, Moderate, Elevated, Critical). The top of the list is where leadership attention pays best; the bottom often hides good practice worth sharing. Negative week-over-week changes flag positive momentum; large positive changes are the early warning signal before the trend chart shows it clearly. Use Deep Analysis to get an AI-generated read on which projects on the move warrant the most attention.

Projected Weekly Load per Project(4.3.9)

Grouped bar chart showing actual 4-week average weekly event load per project alongside a 2-week forward projection from the recent trend, damped and never lower than half the 4-week average; a project with events in fewer than 3 of its last 4 complete weeks shows no projection. Identifies projects growing their operational footprint and lets capacity planning prepare. A projected load significantly above current average is a "you'll need help" signal; one trending down may be intentional focus or quiet stalling. Use Deep Analysis to get an AI-generated read on which projected loads warrant staffing conversations and which are noise.

Projects below floor(5.7.3)

How many projects are currently scoring below the agreed compliance floor. The action-list for the next governance review. This card reads the latest complete week and names the week it read. A count of 0 is a measurement and reads green—every project the week scored met the floor; a dash means nothing could be scored, so there is nothing to count.

Projects Improving(4.2.4)

How many projects are showing meaningful risk-score improvement — a four-week decline in the composite risk score. The good-news counterpart to the Elevated / Critical KPI; the two together give a balanced executive picture. This card reads each project's latest complete week and does not count the week in progress. Projects report in different weeks, so the card names no single week. A project whose latest complete week carries fewer than 10 status transitions is not scored, and an unscored project is counted neither as improving nor as holding steady; when no project clears that evidence floor the card shows a dash rather than a zero, because a zero would read as an all-clear the evidence does not carry.

Projects in escalation(3.6.1)

How many of your projects are currently scoring above the escalation threshold. Zero is the goal; non-zero is the agenda for the next leadership review. A week measuring fewer than two of the three signals is left unscored, and a project whose latest scored week is unscored is not counted here. A value shown as "—" means the read returned nothing or the figure could not be measured. It is never to be read as a zero: a measured zero is printed as a zero, and a card with no figure also carries no accent color, because a tint is a judgment about a number and there is no number to judge. The date range selects whether the portfolio snapshot appears at all, while the figures themselves are still taken from each project's latest complete scored week. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Projects on board alert(3.6.2)

Of those escalating, how many have crossed into the higher "board alert" threshold. These are the projects that warrant explicit sponsor attention, not just team-level firefighting. A week measuring fewer than two of the three signals is left unscored and cannot be counted here. A value shown as "—" means the read returned nothing or the figure could not be measured. It is never to be read as a zero: a measured zero is printed as a zero, and a card with no figure also carries no accent color, because a tint is a judgment about a number and there is no number to judge. The date range selects whether the portfolio snapshot appears at all, while the figures themselves are still taken from each project's latest complete scored week. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Projects Tracked(4.1.4)

How many projects recorded activity in at least one complete week of the selected range: one per row of the Portfolio Health Score Matrix below. A week holding only the project's own creation, change, archiving, unarchiving, trash, restore or deletion is not activity, so those events alone, a deletion included, do not make the project count for that week. Sanity check before drawing portfolio-level conclusions. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Projects with PII(5.4.3)

Number of distinct projects where sensitive data has been detected. Useful as a scoping number—a finding in one project is contained, while the same finding across ten projects points to something the projects share.

Projects with recurrence(3.4.1)

How many of your projects show measurable incident recurrence in the window. Zero is exceptional; a small steady value is normal; growth indicates accumulated technical or process debt.

Rapid Multi-Transition Issues(5.1.7)

Weekly stacked bar chart of tickets that recorded two or more status transitions within an hour, bucketed by intensity. The pattern is hard to spot manually since each transition looks normal alone—it only shows in the gaps between events. High-intensity tickets rarely have a work history matching their state history, and clusters near deadlines reflect pressure to clear tickets. The bars count tickets, because one ticket's bursts can mix account types; each burst's transitions are listed beside them by the type of account Jira reports for whoever made them, people's first, then transitions by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for, each counted on its own. Use Deep Analysis to see which tickets to spot-check first and what question each cluster raises.

Rapid-transition issues(5.1.3)

Number of tickets with at least one rapid burst: a chain of two or more status changes whose consecutive gaps are each under an hour. A burst records how fast the statuses changed, not why; a reviewer could ask whether the chain matches how the work moved. This total covers every week in the selected range, including the week in progress. The ticket count stays the headline, because one ticket's bursts can mix account types. The transitions behind it are listed beside it by the type of account Jira reports for whoever made them, people's first, then transitions by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for, each counted on its own.

Reassignment Frequency Heatmap(2.5.5)

Heatmap of when true reassignments — work moving from one person to another — are concentrated, by day of week, week by week. Initial assignments and unassignments are shown alongside so triage days stay visible without inflating the reassignment signal. Consistent Monday peaks are normal sprint-planning activity and not a governance concern; spikes on unexpected days (mid-sprint, weekends) warrant a look, because something disrupted normal workflow. Use Deep Analysis to get an AI-generated read on which spikes are planning, which are firefighting, and which suggest structural ownership confusion.

Recurrence Rate & MTBI by Project(3.4.5)

Per-project recurrence rate (the share of a project's incidents that were reopened after reaching a done status) alongside mean time between incidents (the average gap between incident creations). High recurrence with a short time between incidents means many incidents came back after resolution and new ones arrive close together; high recurrence with long gaps means incidents are infrequent, but many came back. Use Deep Analysis for a read on which projects' recurrence stands out and the questions it raises.

Recurring Incident Signature Detector(3.4.6)

A list of tickets resolved and reopened at least twice: the chronic repeat offenders consuming disproportionate team capacity. A ticket reopened multiple times is direct evidence the underlying problem hasn't been permanently fixed. Investigating the top one or two often reveals a deeper quality or specification issue that, fixed at the root, prevents reopens elsewhere. Use Deep Analysis for a read on common patterns across the top offenders and the likely shared root cause.

Red signals(1.1)

How many of today's automatic checks are flagging immediate attention (e.g. high-priority tickets without an owner, SLA breaches, sprint carryover, reopen surges, or issues stuck in the same status more than twice as long as that status usually holds one, judged on the status's own history). A non-zero count is something to act on this morning. The week in progress is shown at its rate so far. Its week-over-week change compares that rate with last week's rate over the same portion of the week.

Release Cadence(2.1.16)

Trends how often releases or release-like events happen across your projects. Less about counting releases and more about spotting whether your delivery cadence is steady, accelerating, or has gone silent. Sustained slowing usually precedes a planning conversation; sudden acceleration may reflect a release-train change that the team is adjusting to. A steady cadence is the desired pattern for teams targeting elite delivery performance.

Reopen Destination Status Distribution(2.3.10)

Horizontal bar chart of where reopened tickets land: To Do (coral) means full restart, In Progress (teal) means picked up immediately. Bars labeled with absolute count and percentage; a warning banner appears when total reopens are under 20 (small samples should be directional only). 100 percent of reopens landing in To Do indicates full rework cycles with significant capacity implications; a mix suggests inconsistent rework handling across teams. Use Deep Analysis to get an AI-generated read on whether your destination pattern fits your team's intended rework strategy.

Reopen Rate by Project(2.3.6)

Horizontal bar chart ranking each project by reopen rate in the selected window—reopens counted against completions recorded over the same days. Projects above 15-20 percent are worth a direct process review; projects sitting at zero appear on the chart at 0.0 percent rather than dropping out, and may be genuinely clean or may be closing tickets that were never really finished, both worth a spot check. A large gap between projects on the same team points at process consistency rather than individual skill. Use Deep Analysis to get an AI-generated read on which project comparisons are most diagnostic and what to investigate.

Reopen Rate Momentum(4.3.3)

Whether the 4-week moving average of the reopen rate sits below, level with, or above the 8-week average in the latest complete week: Falling means the last four weeks carried a smaller share of reopens than the last eight, Rising a larger one. It describes the recent direction and is not a forecast; at the floor of ten transitions a single reopen is ten points, so read the direction together with the transition counts on the chart below. Reopens count issues moved back out of a terminal status classified as delivered under your terminal-status settings (a MetaFrazo default applies until configured); revivals of abandoned closures are not counted. A week is rated only when it recorded at least ten status transitions, because below that a single reopen swings the rate by more than ten points—further than any change in behavior would; unrated weeks are left out of the momentum averages rather than counted as zero-reopen weeks. This card reads the latest complete week and names the week it read. The week in progress is left out rather than read: the two moving averages this card compares are not published for a week that is still being filled, so reading that week left the card with nothing to compare and it showed no direction at all. If the only week in the selected range is still in progress, no direction is shown. The chart below still plots the week in progress. A project with fewer than eight complete weeks of history by the week read has no 8-week average yet, so it is left out of the comparison and the card says how many were; when every project is that new, the card shows "Collecting data" with the weeks in place so far instead of a direction.

Reopen Rate Momentum Indicator(4.3.8)

Multi-line chart of weekly reopen rate per project, where a reopen moves an issue back out of a terminal status classified as delivered under your organization's terminal-status settings (a MetaFrazo default applies until configured); revivals of issues closed as abandoned or duplicate are not reopens. A rising line means a larger share of the week's status transitions were reopens, a falling line a smaller share; the two moving averages smooth that line over four and eight weeks and describe its recent direction, they are not a forecast. The rate is the share of the week's status transitions that were reopens, so edits to other fields neither raise nor dilute it. A week is plotted only when it recorded at least ten status transitions: below that a single reopen moves the rate by more than ten points—one transition can read only 0 or 100—so the week plots as a gap and does not enter the moving averages. A gap therefore means too little status activity to rate, which is not the same as a week without reopens; the transition count is shown for every week so you can tell them apart. Most diagnostic on month-over-month timeframes—weekly noise tends to obscure underlying trend. Even at ten transitions one reopen is ten points, so the two averages crossing on thin weeks is ordinary movement rather than a signal; read them together with the transition counts. A project whose reopen rate doubles over a quarter is worth a look at scoping and the definition of done; the chart shows the trajectory, Deep Analysis helps identify which. Use Deep Analysis to get an AI-generated read on the underlying driver of your current trajectory and where to intervene.

Reopen Rate Over Time(2.3.5)

A line chart of weekly reopen rate, with each point sized by the number of completions that week. A rate rising over multiple weeks means reopens are growing relative to each week's completions, while spikes in specific weeks often line up with sprint ends or deadlines; a sustained decline means fewer completed tickets are coming back. Use Deep Analysis to get an AI-generated read on which weeks' rates are signal versus noise and what to address.

Reopen Rate Surge(1.7)

Detects projects whose reopen rate jumped significantly week-over-week. A project's weekly rate is published only for a week with at least five completions, and the change compares this week so far with the same portion of last week. A 35 percent rise in one project often points to a code change that shipped broken or a regression in a release candidate. Multiple projects surging at once usually indicates a systemic event, such as a deployment or process change, rather than independent issues.

Reopen Surge Detector(3.1.8)

Measures the acceleration of reopens, not just the count, so a project that doubled its reopen rate in two weeks stands apart from one steady for months. A week-over-week jump above 50 percent is high-priority; several projects accelerating at once usually signals a systemic event rather than isolated failures. Use Deep Analysis for a read on which projects' acceleration looks structural and what to investigate first.

Repeat Reopener Actor Fingerprint(2.3.7)

A donut of which actors triggered the reopen events: one slice per actor, sized by that actor's reopen count and labeled with the count and its share of all reopens. Reopening isn't inherently wrong, but when one actor accounts for most reopens it's worth investigating; a spread across many actors points to a process-wide problem instead. Each actor is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to get an AI-generated read on which actor patterns warrant a one-on-one and which suggest a team-level fix.

Reporter field changes(5.3.1)

How often the reporter field on tickets gets changed after the fact. Most legitimate cases involve handoffs (an assistant filing on behalf, an automation correcting itself); persistent activity by one actor is worth a closer look. This total covers every week in the selected range, including the week in progress. The count is split by the type of account Jira reports for whoever made each change: people's changes form the headline, and changes by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside them, never inside them.

Reporter Field Changes Over Time(5.3.5)

Time series of how often a ticket's reporter field is changed after creation. In normal workflows the reporter almost never changes—when it does, someone may be retroactively reassigning accountability for who identified a problem. Any significant volume is unusual and worth a closer look; spikes often track reviews, incidents, or bulk edits, and a reviewer could ask who made each change and why. Each change is counted by the type of account Jira reports for whoever made it: people's changes form the headline, and changes by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside them, never inside them. Use Deep Analysis to see whether the pattern looks like a bulk edit, a handoff, or worth a closer look.

Resolution Velocity & Projection(4.3.5)

Multi-line chart of the weekly count of issues delivered per project. An issue counts as delivered when it reaches a terminal status whose disposition is delivered under your organization's terminal-status settings; until a status is configured, MetaFrazo applies a default reading of its name. Issues closed as abandoned or duplicate are reported alongside in the same row, not counted as delivery. Reveals whether velocity is accelerating, stable, or declining across the portfolio at a glance. A project with consistently rising velocity is investing successfully; one with declining velocity is the natural candidate for a capacity or scope conversation. Use Deep Analysis to get an AI-generated read on whether the current trajectory supports next quarter's commitments.

Resolved-Without-Worklog by Project(5.5.5)

Per-project rate of tickets resolved without any worklog entry. A worklog is the primary evidence that work actually happened, so a high unlogged-resolution rate flags audit gaps where there's no documented effort behind a resolution. Consistently logged projects meet their time-tracking compliance requirements. Use Deep Analysis for an AI read on whether your gaps cluster around specific issue types, actors, or time pressures.

Risk Cluster by Issue Type(3.3.9)

Heatmap of average risk score by project-and-issue-type combination—reveals where governance risk concentrates. Each open ticket counts once, in the cell of its current project and type, where a ticket is open when the latest status its events record is in Jira's To Do or In Progress category; deleted tickets and tickets in trashed projects are not counted. In some projects Bugs carry the highest risk; in others it's Stories or Tasks. Bright cells show where scores are highest: in a project where Bug risk dominates, a reviewer could ask how bugs are triaged, and where Story risk dominates, how stories are scoped. Use Deep Analysis to get an AI-generated read on the most concentrated risk cells and the questions they raise. The page's end date bounds this heatmap through each issue's creation week; the start date does not narrow it, so older work still appears in its cell. Issues that already existed when MetaFrazo was installed carry no creation week; they are still placed in their project-and-type cell, grouped by the week MetaFrazo first observed them rather than collapsed into a single undated cell.

Risk Improvement Trajectory(4.2.10)

Diverging bar chart of four-week change in composite risk score per project: bars right (positive) mean risk increase, bars left (negative) mean improvement. Ordered by magnitude of change. A project whose latest complete week carries fewer than 10 status transitions is not scored and draws no bar: below that, a single transition moves the score by more than half a tier band, so the bar would report arithmetic rather than a measurement. Useful for both celebrating wins (the leftmost bars) and identifying interventions worth replicating; useful for spotting projects that quietly accumulated risk while no one was watching (the rightmost bars). Use Deep Analysis to get an AI-generated read on which improvements are durable versus tactical and which deteriorations look structural.

Risk Reduction Signals(3.6.10)

Detects weeks where multiple risk indicators improved at once, a pattern harder to explain as a temporary dip than a single improving signal. It is the counterpart to the escalation timeline: it shows where risk measures fell together. The reopen signal counts issues leaving a terminal status classified as delivered under your organization's terminal-status settings (a MetaFrazo default applies until configured); revivals of issues closed as abandoned are carried separately as abandoned exits, not counted as reopens. Use Deep Analysis for a read on which projects' improvements look durable versus which are tactical and may regress.

Risk Score Distribution by Project(3.3.6)

Distribution of risk scores across all open tickets per project. A ticket counts as open when the latest status its events record is in Jira's To Do or In Progress category, including one that has not changed status since MetaFrazo was installed; deleted tickets and tickets in trashed projects are not counted, and a ticket moved between projects counts once, in its current project. A few high-risk tickets are isolated cases; a project where most open tickets carry elevated scores is showing a portfolio-wide pattern rather than a handful of exceptions. Projects with a long right tail (a few very-high-risk tickets) need targeted intervention; projects with a wide spread need structural review. A tightly-clustered low-score distribution is healthy. Use Deep Analysis to get an AI-generated read on which projects' shape signals a localized problem versus a structural one. The page's end date bounds this visual through each row's creation week; the start date does not narrow it, so projects whose issues were created before the window still appear. Issues that already existed when MetaFrazo was installed carry no creation week; their rows show "First seen" and the week MetaFrazo first observed them in the Week column, one row per observation week rather than a single undated bucket per project.

Risk Signal Decomposition(4.2.6)

Stacked bar showing weekly risk signal contributions per project: bypass events, reopen events, stuck issues, and configuration drift (changes to the project's configuration, not to its issues). Each segment's size shows its proportional contribution to the total score, so a steady total can mask a shift in composition (delivery signals giving way to bypass signals, for example). Pick a single project to see its weekly timeline; unfiltered shows latest values across the portfolio. Use Deep Analysis to get an AI-generated read on which signal mix is doing the heavy lifting on the top projects.

Rubber-stamp issues(5.2.4)

Closures into a delivered status within five minutes of the issue being created, which MetaFrazo calls rubber-stamp closures; the name describes the timing, not anyone's intent or whether a review happened elsewhere. The count covers closures made by people; fast closures by apps such as Automation for Jira, by service-desk customers, by accounts Jira returned no type for, by erased accounts or with no recorded actor are shown beside it. Counted over closures into delivered statuses only, under your organization's terminal-status settings (a MetaFrazo default applies until configured); fast discards are backlog hygiene and are not counted. This total covers every week in the selected range, including the week in progress. Weeks are counted whole: a week that falls only partly inside the selected range is not included. The Fast-Close Distribution chart below it covers the same weeks.

Schema Change Category Breakdown(2.6.8)

A proportional split of permission-drift events by category (field and field context, issue type, user, project). If field changes dominate, focus on schema governance; if user events dominate, access management is the priority; a category above most of all drift is the period's primary focus, and a sudden shift in the dominant category signals changing admin behavior worth investigating. Use Deep Analysis to get an AI-generated read on what's likely driving your current category shift and where to direct review attention.

Segregation of Duties Violations(5.6.6)

Tracks the rate of segregation-of-duties violations over time—cases where the same actor created a ticket and was the sole contributor to its closure. A rising rate means more work is being closed by the person who created it, which is the first thing a separation-of-duties review asks about. A clean trend means two-actor closure is the norm. Each closure is attributed to the type of account that closed it, as Jira reports it: a person, an app such as Automation for Jira, a service-desk customer, or unknown. The rate counts closures made by people; an app that creates and closes its own issues is shown beside it as app activity, and closures by customers and by accounts Jira returned no type for are shown the same way, never counted as a person's. Use Deep Analysis for an AI read on whether your pattern is improving, deteriorating, or steady, and which projects or roles drive most violations.

Self-assign hotspots(5.3.4)

Projects where self-assignment (an actor picking up a ticket without it being explicitly assigned to them) happens disproportionately often. The rate counts only assignee changes made by people, so an automation rule that assigns issues does not pull it down; changes by apps, service-desk customers and accounts Jira returned no type for are shown beside it. Healthy in self-organizing teams; suspect in teams with formal assignment processes. Counts only projects that had at least one assignee change in the selected period; a project with no assignee changes is not counted either way.

Self-Assignment Rate by Project(5.3.8)

Per-project rate at which actors assign tickets to themselves rather than receiving an assignment. Self-assignment isn't inherently wrong, but a consistently high rate may mean formal allocation is being bypassed or access is too permissive, while a very low rate may mean managers over-control allocation. Comparing projects shows whether differences are cultural or come from how each project's approval steps are set up. The rate counts only assignee changes made by people's accounts, as Jira reports the account type; changes made by apps such as Automation for Jira, by service-desk customers and by accounts Jira returned no type for are counted beside each bar, never inside the rate. Use Deep Analysis to see what questions the variance between projects raises.

Self-chain actors(5.1.4)

How many contributors have moved one of their own tickets through multiple statuses without anyone else's involvement. Not always a problem, but a useful early signal of single-actor-completion concentration. Counts people's accounts; app accounts such as Automation for Jira, service-desk customers and accounts Jira returned no type for are shown beside it.

Self-Chain Detection(5.1.10)

Table of tickets where every status transition in a week came from a single actor, with two or more hops recorded—so no second actor appears in that ticket's status history that week. A reviewer would ask first about a high hop count over a short span, and about actors recurring across weeks. An empty log means no ticket in the selected range had two or more status changes in one week all made by the same account. Each self-chain carries the type of account Jira reports for its actor (a person, an app, a service-desk customer, or unknown): an app account such as Automation for Jira that moves an issue through its statuses is shown as app activity, not as a person. Use Deep Analysis to see which actors and tickets a reviewer would ask about first, and what question to bring.

Shared Contributor Overlap(3.6.6)

Matrix of how many contributors each pair of projects has in common. Overlap is counted across all recorded activity, not risk events alone. High overlap is expected for leads and platform teams that work across many projects, and is not itself a finding. Contributors are people's accounts as Jira reports the account type: apps such as Automation for Jira and service-desk customers are not counted, and accounts Jira returned no type for are shown separately. Use Deep Analysis to get an AI-generated read on where one group of contributors is carrying several projects at once.

Single-Actor Resolution Rate(5.2.6)

Weekly dual-line chart comparing solo closes, delivered closures where the person who closed the issue also created it, with closures by someone other than the creator. The measure compares those two people only: it does not show whether anyone else commented on or worked the issue in between, or whether a review was recorded outside Jira. The rate is computed over delivered closures only, under your organization's terminal-status settings (a MetaFrazo default applies until configured); discards are backlog hygiene and are not counted. A rising solo-close rate means more of the delivered work is closed by its own creator, and a reviewer could ask whether those closures belong to roles that routinely close their own work. The rate counts closures made by people's accounts, as Jira reports the account type; closures by apps such as Automation for Jira, by service-desk customers and by accounts Jira returned no type for are shown separately. Use Deep Analysis to see which weeks, projects and actors account for the solo closes.

SLA Breach Clock(3.5.8)

Aggregate exposure summary: distribution of open tickets across five SLA-consumed bands—on track, caution (50-80 percent), warning (80-100 percent), in breach (100 percent or more), and age unknown for tickets whose recorded events carry no creation time, which are drawn in their own segment rather than dropped. Age runs from the creation time Jira records for each ticket. A ticket counts as open when the latest status MetaFrazo recorded for it is in a to-do or in-progress category; tickets whose deletion was recorded and tickets in a project moved to the trash or deleted are left out, and a ticket moved between projects counts once, under its current project. Each ticket's budget is a target resolved from your configured SLA policy by the ticket's current issue type where set, and a MetaFrazo default otherwise; the target never depends on priority. The leadership-briefing version of the per-ticket triage table, counting the same tickets. A clean profile with most volume in "on track" and a small tail in "caution" is normal; a fat warning band means the next week will see a lot of breaches if nothing changes. Use Deep Analysis to get an AI-generated read on which warning-band tickets are most likely to breach and what to prioritize.

SLA Breach Escalation Alert Log(3.5.10)

Compliance audit log: every delivered ticket that exceeded its SLA target, with the breach multiplier (a ticket that took 2.8 days when the SLA was 1 day shows as 2.8x). Tickets ending in an abandoned-classified status are excluded: the events show work stopped by decision, and the log does not present that as a late delivery. For teams preparing a compliance review, this log shows which delivered tickets ran past their target and documents the severity. Useful for incident retrospectives and reviewer requests; pairs with the breach-clock for a complete past-and-present view. Use Deep Analysis to get an AI-generated read on the worst-multiplier breaches and what they have in common. Targets resolve from your organization's configured SLA policy by issue type where set, and MetaFrazo default targets otherwise (5 calendar days for bugs, 10 for stories, 30 for epics, 7 for anything else); default targets are ours, not a commitment your organization has made. The priority column shows the priority in force when the ticket was delivered, taken from the creation baseline and any later change; tickets whose priority never appears in the event stream read Unknown.

SLA Breach Log(1.5)

Counts open tickets that passed their SLA target in the last 24 hours, and those at risk: over 80 percent of their time budget used. A Highest-priority bug at 92 percent consumed shows amber, close to its target and not yet past it. Age is measured in calendar days from issue creation, against your organization's configured SLA targets where set, and MetaFrazo default targets otherwise (5 days for bugs, 10 for stories, 30 for epics, 7 for anything else). Default targets are ours, not a commitment your organization has made.

SLA Breach Probability per Open Issue(3.5.5)

Live triage view: every open ticket evaluated against its SLA target and labeled "on track", "warning" (80 to 100 percent of the target used) or "in breach" (the whole target used). A ticket counts as open when the latest status MetaFrazo recorded for it is in a to-do or in-progress category; tickets whose deletion was recorded and tickets in a project moved to the trash or deleted are not listed, and a ticket moved between projects is listed once, under its current key. Not a historical chart—a live exposure snapshot for prioritizing action. A ticket at 207 percent of its SLA target is well past it; where your organization has formal SLA commitments, a breach of that size is the kind a reviewer may ask about. Use Deep Analysis to get an AI-generated read on which open tickets need escalation versus which can be resolved with a single push today. Age is measured in calendar days from issue creation as Jira records it, against the target for the issue's current type: your organization's configured SLA targets where set, and MetaFrazo default targets otherwise (5 days for bugs, 10 for stories, 30 for epics, 7 for anything else). Default targets are ours, not a commitment your organization has made.

SLA Breach Rate Trend by Project(3.5.6)

Weekly SLA breach rate among delivered tickets trended per project, counted under your organization's terminal-status settings (a MetaFrazo default applies until configured). A week whose endings were all abandonment has no delivered tickets to measure: it keeps its place on the time axis but carries no point on any line, so the line breaks there rather than dropping to zero, and the abandoned count rides in the same row. The same holds for a week that delivered fewer than five tickets: a rate over one, two or three deliveries is a coin flip rendered as a measurement, so the week is not rated and the line breaks there too, with the delivered count in the row to tell the two cases apart. A measured 0 percent is the opposite case and still plots as a point—that week delivered tickets and none of them breached. A single high-breach week can be a one-off; a rise that holds across several measured weeks is a sustained pattern. A project trending up from 3 percent to 12 percent over two months is missing its target on a growing share of delivered tickets; the events do not say whether the workload or the targets themselves explain it. Use Deep Analysis to get an AI-generated read on which projects' rise is a single spike and which is sustained, and the questions each raises. Each ticket is measured against a target resolved from your organization's configured SLA policy by issue type where set, and a MetaFrazo default otherwise (5 calendar days for bugs, 10 for stories, 30 for epics, 7 for anything else); default targets are ours, not a commitment your organization has made. A week whose endings were all abandonment plots no rate rather than 0, and the abandoned count rides in the same row.

SLA Compliance Rate by Issue Type(2.7.8)

Compliance percentage per issue type against type-specific SLA targets, measured over delivered tickets only: whether a closing status counts as delivered follows your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured). Tickets that ended in an abandoned-classified status are reported as their own count, not for or against compliance: abandoning a ticket is a scope decision, not an SLA outcome. A day on which a project delivered fewer than five tickets of a type is not rated: one late ticket among two deliveries reads as 50 percent by arithmetic and nothing by evidence, so the row keeps its delivered, met and breached counts and shows no percentage. The percentages on this panel and on the Overall compliance card are pooled over every delivered ticket in the window, and are likewise shown only once at least five have been delivered. An 80 percent rate for Bugs means 1 in 5 bugs is taking longer than target—across a quarter, that accumulates into a backlog of overdue fixes that users are waiting on. Types below 80 percent miss their target on more than one issue in five, which is the pattern a reviewer would ask about; types above 90 percent stay within target on nearly all of them; a type above 90 percent whose breach trend is rising is worth watching before it crosses. Use Deep Analysis to get an AI-generated read on which type's compliance trajectory is most diagnostic.

SoD violation rate(5.6.2)

Share of closures made by people in which the person who closed the issue also created it, which MetaFrazo counts as an SoD violation (segregation of duties). Closures by apps such as Automation for Jira, by service-desk customers and by accounts Jira returned no type for are counted separately and never in this rate. Useful as a single headline compliance number for review meetings. This rate covers every week in the selected range, including the week in progress.

Solo-close rate(5.2.2)

Share of closures where the person who closed the ticket also created it (a solo close). The rate counts closures made by people; closures by apps such as Automation for Jira, by service-desk customers and by accounts Jira returned no type for are shown beside it and never counted in it. It compares those two people only, so it does not show whether anyone else took part in between, or whether a review was recorded outside Jira. Counted over closures into delivered statuses only, under your organization's terminal-status settings (a MetaFrazo default applies until configured); discards are backlog hygiene and are not counted, and closures whose creator cannot be attributed are excluded rather than counted as peer-reviewed. This rate covers every week in the selected range, including the week in progress. Weeks are counted whole: a week that falls only partly inside the selected range is not included, so this rate covers the same weeks as the Single-Actor Resolution Rate chart below it.

Spike Alert Log(3.2.10)

Chronological log of every statistically significant backlog spike with date, project, volume, baseline at the time, and severity (Critical above 3x baseline, High 2-3x). Useful for post-incident reviews and capacity-planning retrospectives; provides compliance evidence of when demand anomalies occurred and how they were classified. A log with no entries in a period whose days had a baseline indicates stable, predictable inflow—a positive governance signal; while no day in the period has a baseline yet, the panel shows "Collecting data" instead. Use Deep Analysis to get an AI-generated read on patterns across recent alerts and which alerts warrant a formal review write-up.

Spike Severity Ranking by Project(3.2.6)

Ranks projects by peak-to-baseline ratio so you compare apples to apples—a project handling 20/day getting 25 is fine, while a project handling 5 getting 25 is in crisis. A 3x or higher ratio indicates a genuinely extreme backlog event, not just a busy period. Projects with low ratios, even at high absolute volume, are managing demand predictably. Comparing ratios across the portfolio identifies which team needs immediate triage support. Use Deep Analysis to get an AI-generated read on which project's spike is structural versus situational.

Sprint Open Share(1.6)

Share of the active sprint's issues that are open by the latest status their events record, measured now, against the same share on up to six of the most recent closed sprints. The active sprint is the one Jira reports as active. The share starts high at sprint start and falls as the sprint runs; where it stays high late in the sprint, or sits well above the closed sprints' shares, a reviewer could ask whether the remaining scope still fits the time left.

Sprint Scope Still Open(2.4.6)

Per-sprint stacked bars of issues now in a done status versus issues still open, with badges for the latest sprint's open share, its trend and the number of sprints analyzed. Each issue counts in the sprint it was most recently assigned to, and the split is measured as of now, so an earlier sprint's open bar is the scope left in it that was never moved on. A rising open share across sprints is more telling than any single sprint's value. Use Deep Analysis for a read on the trend across sprints and the questions it raises.

State-Skip Detection(5.1.9)

Horizontal bar chart of tickets that jumped straight from an open state to a terminal state in one step, skipping every intermediate stage. State-skipping means an issue reached a delivered status without passing through the intermediate ones: either the work was never recorded, or its history does not show it. Persistently high projects need a workflow review; a single spike is often a bulk-close worth checking. Each skip is attributed to the type of account that made it, as Jira reports it: the chart counts skips by people, and skips made by apps such as Automation for Jira, by service-desk customers, by accounts Jira returned no type for, by erased accounts or with no recorded actor are shown beside it, never counted as a person's. Use Deep Analysis to see which projects to prioritize first.

Status Bottleneck Heatmap(2.7.7)

Portfolio-level heatmap with projects on rows and statuses on columns—cell color encodes the average time in that combination. A single dark cell is project-specific (something about how that team handles that stage); a dark column (same status slow across many projects) points to a shared process constraint; a dark row (all stages slow for one project) means that project is slower at every stage, and a reviewer could ask what is different about it. Use Deep Analysis to get an AI-generated read on which bottleneck shape your portfolio shows and where leverage is highest. Cell color reflects the full length of every recorded wait, with no upper limit applied, so a single very long wait can darken a cell on its own—check the number of measurements behind a cell before reading it as a persistent constraint.

Status Category Drift(5.10.7)

Table of the status-category conflicts observed across the tenant's workflows, of two kinds, with every row labeled by kind. A name collision is two or more different statuses sharing one display name while sitting in different categories: statusCategory = "Done" in JQL then returns one project's issues and silently omits another's, and category-pivoted reports quietly double-count or miss work. A category change is one status whose own category moved during the window; a renamed status is still one status, and the label shown is its most recently observed name. An empty table is the healthy state. Use Deep Analysis for an AI read on each finding, its human impact, and the most likely remediation.

Status Category Drift Matrix(5.10.8)

A status by project matrix for the name collisions listed by Status Category Drift—display names carried by two or more different statuses that do not all sit in the same status category. Each cell shows the category (To Do, In Progress, Done) that one project's workflow assigns, color-coded so disagreements stand out at a glance—and links straight to that project's workflow configuration. The other kind of finding, a category change, is listed in the table above and is not plotted here: a cell states what different projects say about one label, while a category change is one status disagreeing with itself over time. A renamed status is still one status, and the label shown is its most recently observed name. An empty matrix means no name collision was observed.

Status Transition Frequency(5.10.5)

Bar chart of the most-used status names across all transitions in the last 12 months, ranked by how often work actually lands in each. Near-duplicates differing only in casing or spacing are a textbook drift signal, and a crowd of Done-style statuses usually means status names are being used where resolution values should be. Obscure high-count statuses are often project-specific stages worth consolidating. Use Deep Analysis for an AI read on specific consolidations to recommend by name.

Status-vs-resolution sprawl(5.10.2)

How many distinct Done-bucket status names the team uses compared to how many distinct Resolution values are in play. A high ratio is a sign that status names are doing the work Resolution should be doing—different shades of "done" expressed as separate statuses—which makes reporting and JQL brittle.

Stuck Status Detector(1.8)

Lists tickets that have stayed in one status more than twice as long as that status usually holds a ticket, such as items waiting on review for days. For each entry, a reviewer could ask what the ticket is waiting on. The usual duration is read from the history of that same workflow status in your workspace, the time it has usually taken a ticket to leave it, so two statuses that share a name in different workflows are never compared with each other. Only open tickets are listed, and a ticket whose move into its current status was never captured is not, because its time in that status is unknown.

Stuck-in-Status Detector(3.1.6)

Open tickets that have sat in their current status well past the usual time for that status, ranked by how far past it they are. Transition counts do not show these tickets, because they are not moving. Several tickets stuck in one status put the wait at that stage; the list shows where tickets wait, not why. The last actor, the account that moved each ticket into its status, is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis for a read on where the stuck tickets cluster and the questions it raises.

Team Engagement & Activity Mix(2.1.9)

Breakdown of the Jira events recorded for your site over the whole recorded history, by event type—issue creations and updates, comments, worklog entries, assignments, others—with the number of distinct accounts behind each type; the page's date and project filters do not narrow it. A status change arrives as an issue update and is counted there; MetaFrazo's own instrumentation records are not Jira events and are not counted. A team can be very busy in Jira while tickets barely move; comparing the share of issue updates, which carry those status changes, with the comment and worklog shares shows where the recorded activity went. Where comments far outnumber issue updates, a reviewer could ask whether the scope is clear; where worklog entries are few beside many issue updates, whether time is logged for that work. Each type's actions are split by the type of account Jira reports: people's actions form the headline, and actions by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside them, never inside them; the account count shows people's accounts beside all accounts. Use Deep Analysis to get an AI-generated read on what the activity mix shows and which question to ask first.

Time-to-First-Move Distribution(2.4.9)

A histogram of time from ticket creation to first status transition, bucketed from under a day to over a week, with badges naming the band the median ticket and the 90th-percentile ticket fall in. When the median ticket sits in a band above two days, intake is taking longer than that to reach most tickets; a large long-tail bucket alongside a large fast bucket points to a bimodal pattern, where some tickets are picked up immediately and others wait much longer. Use Deep Analysis to get an AI-generated read on what's driving your long tail and how to compress it.

Top 10 Workflow Paths(2.1.7)

Ranked bar chart of the most-traveled full transition sequences—the actual journeys tickets take from creation to close. If your intended workflow is To Do -> In Progress -> Review -> Done but the top path skips Review, that's a process-compliance signal. Short or incomplete paths in high volume suggest tickets are being closed without proper progression; long or looping paths indicate rework. A top path matching your defined workflow means the process is well-followed. Use Deep Analysis to get an AI-generated read on the gap between your intended and actual paths.

Top Active Custom Fields(5.10.6)

Ranked list of the custom fields receiving the most write activity, with each field's type. Counts default to the last 12 months and can be windowed to the last 30 or 90 days. A few fields doing most of the work is normal; a long tail of barely-touched fields is clutter worth retiring, and generic or test-like names still seeing production edits are especially worth checking. Low-activity fields used by automations or integrations can still be load-bearing, so verify before deleting. Declared fields with no observed writes are listed separately, and the list can be sorted and filtered by project and by field type. Use Deep Analysis for an AI read on concrete retirement candidates by name.

Top Actor Concentration(4.5.2)

How much of the team's activity is driven by the top few contributors. High concentration is a key-person-risk signal; moderate concentration is healthy and reflects natural specialization. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills. Only people's accounts are counted, as Jira reports the account type: apps such as Automation for Jira and service-desk customers are left out, and the number of accounts Jira returned no type for is shown in the sub line.

Top bottleneck(2.7.4)

The workflow status where work waits longest before moving on. The figure is an average dwell taken across every day in the window and every project where the status is eligible, weighted by the number of issues that left the status, so it reports the window's typical wait rather than the worst single day of any one project. Statuses Jira places in its Done category are not eligible for this ranking: an issue that has reached one is not queued behind anything, so naming it would point improvement effort at a stage with no queue. Their dwell is still shown in Average Time in Status. Eligibility is decided project by project, because the same status name can be done in one project and still open in another; only the projects where it is not done count toward its figure. The status named here is typically a review, approval, or test step rather than active development. The ranking uses the full length of every recorded wait, with no upper limit applied, so a status where a few issues waited for months can top the ranking on those alone; Average Time in Status shows how many measurements sit behind it. A wait counts only once the issue has moved on, so work parked in a status right now does not yet contribute to it.

Top Deviation Actors(5.5.10)

Ranked table of actors with the highest aggregate control-deviation activity—unlogged resolutions, batch closes, direct skips, and other bypass signals combined—so compliance conversations can be directed appropriately. An actor high across multiple types records deviations in several ways at once; an actor high on one type points to a single practice worth asking about. A clean table means no actor recorded deviations above the threshold. Each actor is labeled with the type of account Jira reports for it (a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type), so an app account's deviations are read apart from people's. Use Deep Analysis for an AI read on each top actor's signal mix and what to address with them.

Top Reopened Issues (mini)(1.11)

Lists the tickets reopened most often recently, often the single most diagnostic signal about quality and specification problems. Investigating the top one or two usually reveals a deeper root cause that, once fixed, prevents reopens across many other tickets.

Top Solo-Close Actors(5.2.10)

Ranked table of actors with the highest solo-closure counts, their solo-close percentage, primary project, and a risk tier, computed over delivered closures only, under your organization's terminal-status settings (a MetaFrazo default applies until configured); discards are backlog hygiene and are not counted. A solo close is a delivered closure where the person who closed the issue also created it. A high count with a high percentage means most of that person's delivered closures are of issues they created themselves, and a reviewer could ask whether their role explains it; a high count with a low percentage may just be a very active person, so context matters. Each actor is labeled with the type of account Jira reports for it (a person, an app, a service-desk customer, or unknown); the ranking and tiers cover people, and an app account such as Automation for Jira that creates and closes its own issues is listed as app activity, not as a person's solo closes. Use Deep Analysis to walk through each top actor's pattern and the questions it raises.

Total assignment changes(2.5.1)

Total number of assignment changes recorded across your projects — each logical change counted once, whichever way Jira reported it. The raw volume baseline behind the more refined volatility signals below. This total covers every week in the selected range, including the week in progress.

Total breach events(3.5.3)

The total number of delivered tickets that exceeded their SLA target in the window, counted under your organization's terminal-status settings (a MetaFrazo default applies until configured). Tickets that were abandoned are not breach events: stopping work on a ticket is a scope decision, not a missed delivery. The historical count for retrospective conversations rather than today's count of open breaches. Each ticket is counted against a target resolved from your configured SLA policy by issue type where set, and a MetaFrazo default otherwise; never against an assumed priority.

Total completions(2.3.3)

How many completion transitions were recorded in the window—the denominator behind the reopen rate. This counts transitions into a completed status, not distinct tickets, so a ticket completed, reopened and completed again contributes twice. Worth a glance before drawing conclusions from the rate.

Total config events(2.2.1)

Total count of configuration-affecting events in the window across all categories: fields and field contexts, issue types, projects, components, filters, boards, workflows and user accounts. A single number useful for spotting unusually busy admin periods. This total covers every day in the selected range, including the day in progress.

Total members(8.1)

The total number of people in your organization with a MetaFrazo account, including owners, admins, and regular members. Useful for tracking team growth and reconciling your roster against your identity provider.

Total open(2.4.1)

The number of open tickets in a To Do-category status across your tracked projects, summed from the Backlog Age Distribution; tickets in an In Progress-category status are not counted, so this is the waiting backlog rather than all open work. A ticket counts by the latest status its events record, and deleted tickets, tickets in a project moved to the trash or deleted, and tickets whose events record no status that maps to a Jira status category are left out.

Total PII events(5.4.1)

Total count of detected sensitive-data events in the window, combining two signals of very different confidence: text matching an email address pattern, and text carrying a standalone run of 7 to 15 digits that is not a date, a timestamp, or part of an Atlassian account id or a UUID-format identifier. Digits Jira writes into a comment's own formatting, such as an embedded file's name or the editor's internal element ids, are not counted either; digits in a link address are. The card breaks the total into those two arms, because a digit run is far weaker evidence than an email address. The severity breakdown below grades them. This total covers every week in the selected range, including the week in progress.

Total projects tracked(3.6.11)

How many projects MetaFrazo is currently tracking for your organization. Useful as a sanity check before drawing portfolio-level conclusions: an average across three projects is anecdotal, across thirty is meaningful. The week in progress is not counted: only complete weeks enter this number, so it does not change as the current week fills.

Total reopens(2.3.2)

The absolute number of reopens recorded in the window. Pairs with the rate KPI—a 20 percent reopen rate over 50 completions is anecdotal, over 500 completions it is structural.

Total scored issues(3.3.1)

How many open tickets carry a risk score: a ticket counts as open when the latest status its events record is in Jira's To Do or In Progress category, and deleted tickets are not counted. The denominator behind the rest of the section's signals. The date range counts issues that were alive in the window: first recorded by MetaFrazo on or before the end date, with their most recent event on or after the start date.

Total spikes(3.2.1)

The total number of backlog-spike events detected in the window across all your projects. A single number that summarizes how stable your inflow has been recently. The day in progress is shown at its count so far. Because the day is not yet complete, it is not compared against the rolling baseline and is not evaluated for a spike. While no day in the window has a baseline yet, the card shows "Collecting data" rather than 0.

Total unowned issues(2.5.3)

How many open tickets currently have no assignee, counting both those that never had one and those whose assignee was later removed. A ticket counts as open when the latest status its events record is in Jira's To Do or In Progress category, and each ticket counts once, under its current project; deleted tickets, tickets in a project moved to the trash or deleted, and tickets whose events record no status that maps to a Jira status category are left out, so this is a live queue rather than a running total.

Transition Events(2.1.12)

Detailed event log with one row per changed field on an issue update—status changes and every other field Jira records, such as description, resolution, priority or summary. Columns: date, issue, summary, field, from, to, actor and project. Each row's actor is labeled with the type Jira reports for it: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. This is the audit log behind every aggregated chart above; it's the starting point for any investigation that begins with "let me check what actually happened". Filter by actor, ticket, project, or window to drill into specific patterns the charts surfaced. Use Deep Analysis to get an AI-generated read on patterns in your filtered set and what they likely mean.

Transition Volume Over Time(2.1.5)

Timeline chart of daily status-transition counts across your connected projects. Spikes often correlate with sprint closures, release pushes, or catch-up periods—check whether work quality holds during the peaks. Sustained drops that don't match known holidays or planned downtime are worth a question: is work waiting on a dependency, or has it moved to another project or tool? A steady, consistent rhythm without extreme peaks or valleys is the healthiest pattern. Use Deep Analysis to get an AI-generated read on whether your current rhythm reflects healthy delivery or a problem worth catching early.

Unlogged resolutions(5.5.1)

Count of tickets that were resolved with no work-log entry attached. Where time-tracking is part of the process, this is the clearest signal that effort isn't being recorded.

Unowned High-Priority Clock(1.4)

Lists Highest- and High-priority open tickets that currently have no assignee, with how long each has been unowned. A Highest-priority ticket counts as past its window as soon as it has no owner, and a High-priority ticket once it has gone four hours without one. For the entries that have waited longest, a reviewer could ask who is expected to own them and whether their priority still reflects the work.

Unowned High-Priority Issue Clock(3.1.9)

Live list of Highest- and High-priority tickets currently without an assignee, with the time each has been unowned. A Highest-priority ticket counts as past its window as soon as it has no owner, and a High-priority ticket once it has gone four hours without one. For the entries that have waited longest, a reviewer could ask who is expected to own them and whether their priority still reflects the work. A cluster from one project that grows over time means the unowned tickets are concentrated there rather than spread across projects. Use Deep Analysis to get an AI-generated read on where the unowned tickets sit and how long they have waited.

Unowned highest priority(3.1.4)

How many open Highest-priority tickets currently have no assignee.

Unowned in progress(2.5.4)

The narrower slice: open tickets whose latest recorded status is in Jira's in-progress category, whatever it is named and in whichever language, but still have no owner, whether they never had one or lost the one they had. Unlike fresh intake, these are work in progress with no assignee on record; deleted tickets, tickets in a project moved to the trash or deleted, and tickets whose events record no status that maps to a Jira status category are not counted.

User Account Change Timeline(2.2.9)

A weekly bar of the net change in user accounts (creations minus deletions), with a line for all account activity (creations, updates, and deletions); hovering a week lists each count by the type of account the event is about: a person, an app, a service-desk customer, or unknown or erased. Account changes are among the most compliance-sensitive events: deletions of people's accounts outside known offboarding windows and creation spikes without matching onboarding are the events a reviewer is most likely to ask about, while a steady pattern aligned with HR cycles means account changes follow joiners and leavers. App accounts belong to apps and integrations and customer accounts to service-desk customers, so only people's accounts are reconciled with HR. Use Deep Analysis to get an AI-generated read on whether recent lifecycle activity matches expected HR rhythm and which events warrant verification. Follows the date filter in whole weeks: a week is included when it falls entirely inside the selected range, and the week in progress is included when the range reaches it.

User events (Admin & permission activity)(2.6.1)

Count of user-account events in the window: accounts added, changed or removed, each classified by the type of account it is about (a person, an app, a service-desk customer, or unknown or erased). Reconcile the changes to people's accounts against your identity provider's off-boarding log; app accounts belong to apps and integrations and customer accounts to service-desk customers.

User events (Configuration changes)(2.2.3)

Configuration events affecting user accounts: accounts added, changed or removed. Each event is also classified by the type of account it is about (a person, an app, a service-desk customer, or unknown or erased), so changes to people's accounts can be read apart from app and customer accounts. The audit-relevant slice of the change stream. Counts the selected date range in whole weeks: a week is included when it falls entirely inside the range, and the week in progress is included when the range reaches it. This total covers every week in the selected range, including the week in progress.

User Lifecycle Heatmap(2.6.7)

Heatmap tracking user lifecycle events (creations, updates, deletions) across weeks, with each event classified by the type of account it is about: a person, an app (an account Jira marks as belonging to an app or integration), a service-desk customer, or an account whose type is unknown or that was erased. Among the most compliance-sensitive activities—a week with multiple deletions of people's accounts and no creations is a potential offboarding event worth verifying with HR; many updates without creations or deletions may indicate privilege changes happening without formal approval. Only people's accounts follow joiners and leavers: app accounts belong to apps and integrations, including built-in ones such as Automation for Jira, and customer accounts to service-desk customers. Use Deep Analysis to get an AI-generated read on which lifecycle weeks need cross-verification with HR records.

Weekly Activity Density by Project(4.1.6)

Project-by-week heatmap showing raw event counts per project per ISO week—absolute activity volume rather than anomaly scores. Enables executives to compare recorded activity side by side across the portfolio. A project that consistently records far more activity than its peers, or far less, raises a question a reviewer could ask: does that match how work is allocated? Each cell's count is split by the type of account Jira reports: people's events form the headline, and events by apps such as Automation for Jira, service-desk customers and accounts Jira returned no type for are counted beside them, never inside them. Use Deep Analysis to get an AI-generated read on which activity patterns stand out and which question to ask first.

Weekly Assignment Volatility Index(2.5.6)

Weekly index measuring what share of assignment activity is reassignment—work handed off again after initial assignment. A consistently high index above 30 indicates that ownership isn't being established clearly at the point of assignment; rising volatility alongside stable total activity means the team is reassigning more often rather than handling more volume. A declining index over time means issues are changing hands less often after assignment. Use Deep Analysis to get an AI-generated read on whether your team is structurally over-reassigning or experiencing a temporary disruption.

Weekly Effort Trend(4.5.11)

Total team effort trended weekly. Distinct from output—two teams can burn the same effort and ship very different amounts of work. Useful as the team's overall capacity-consumption signal; a sustained climb without matching throughput growth is a pattern worth raising with the team before it becomes the norm. A stable trend at a sustainable level is the goal; a downward trend during a quiet quarter is healthy recovery.

Weekly Governance Score by Project(5.7.5)

The weekly MetaFrazo Governance Score for each project on a 0-100 scale, so you can see which projects sit above the 70-point line and how the score is trending over time. The 70-point line marks the floor. How it's calculated: MetaFrazo Governance Score.

Weekly Lead Time Trend(2.7.9)

Weekly trend of the average lead time for delivered tickets alongside the worst single project's P90—the worst-project line surfaces tail risk that a stable average can hide. Lead time here runs from issue creation to the first delivered closure, so it includes the wait before anyone started work; the Cycle Time Control Chart measures from first entry into a work-in-progress status instead, which is why the two panels report different numbers for the same tickets. Whether a closing status counts as delivered follows your organization's terminal-status settings (a MetaFrazo default reading of the status name applies until configured); discarded and canceled work is excluded from the figures and reported as its own count. A rising worst-project P90 with a stable average is one of the clearest early-warning signs of SLA drift: most work is still on pace while one corner takes disproportionately long. Both lines declining together indicates genuine improvement across the board; a spike in both in a specific week often reflects a sprint disruption or particularly complex batch. Use Deep Analysis to get an AI-generated read on whether your trend is building tail risk or holding steady.

Weekly Team Throughput by Actor(4.5.5)

Ranked horizontal bar chart of each actor's average weekly event count, with their busiest week beside it. Both figures come from the actor's weekly totals across all of their projects, over the complete weeks in the selected range in which the actor recorded events. It shows where recorded activity is concentrated and how far an actor's busiest week sits above their usual pace; the events show a change, not its reason, and say nothing about the quality or value of anyone's work. Apps such as Automation for Jira and service-desk customers are left out of the ranking, as Jira reports the account type; an account Jira returned no type for stays in, labeled unknown. Use Deep Analysis for a read on which actors' weekly volume has moved and what a reviewer could ask about it.

WIP Aging(2.4.11)

Shows how long open tickets have been in their current status—WIP age. Helps catch tickets that "look" active but haven't actually moved in two weeks. A long right tail indicates active-status work that's effectively stalled; a left-skewed distribution indicates a team genuinely working through its WIP. The view is the inverse of the cycle-time chart: instead of measuring how long completed tickets took, it measures how long active tickets have been sitting.

WIP Limit Pressure by Project(2.4.7)

For each project, the number of distinct issues sitting in an in-progress status on a given day, reported as the average and the peak across the days that carried any work in progress. An issue counts from the transition that moved it into an in-progress status until its next status transition, whatever that next status is; when its most recent recorded status change is still an in-progress one it has no exit yet and is counted through today. The number of those still-open issues is measured per project and is available to Deep Analysis, so a project whose average sits close to its peak can be told apart as long-running work rather than a steady stream of new arrivals. A pressure badge compares the peak with the WIP limit you set in the filter. Use Deep Analysis to get an AI-generated read on which projects need a structural WIP-limit conversation and which can self-correct.

WIP over limit count(2.4.3)

How many projects reached a single-day peak of concurrently in-progress issues above the WIP limit set in the filter. The peak is each project's busiest day in the history the panel below draws, not a reading for today, so a project can be counted here on the strength of one crowded week months ago. Zero means no project's busiest day crossed the limit. Projects the view could not measure are counted separately and never as within limit.

WIP Run Chart(2.1.17)

Plots work-in-progress count over time. Sustained WIP above the team's healthy ceiling is one of the cleanest signals that the team is starting more than it can finish; this chart shows the trend before sprint retrospectives surface the symptom. Periodic dips below the ceiling are normal between sprints; sustained crossings indicate structural overcommitment. Pairs with the Cumulative Flow Diagram for a full picture of flow health.

Work Breakdown Structure(4.1.11)

Hierarchical tree of work in your portfolio—epics at the top, stories and tasks below, with completion progress per branch. The "what are we building this quarter" picture: useful both for planning sessions and for quarterly review decks. Long branches with little completion are typically scoping problems; branches with high completion but new children appearing are scope expansion. The view complements the Portfolio Health Matrix by adding the structure-of-work dimension to the cross-project scorecard.

Workflow Adherence Score by Project(4.4.7)

Horizontal bar chart of workflow adherence per project: of the transitions that delivered work (into a completed status that counts as delivered under your organization's terminal-status settings; a MetaFrazo default reading of the status name applies until you configure one), the share that came from a work-in-progress status rather than jumping straight from a new status (0-100). Tiers match the chart: mature at 80 or above, developing 60-79, at risk below 60. A week with no completions shows no tier rather than a zero. Useful for grounding workflow-revision conversations in data: if completions keep skipping the same working states, the workflow step is the problem, not the team. Use Deep Analysis to get an AI-generated read on which projects' adherence pattern suggests workflow simplification.

Workflow Drift Stream(5.8.2)

A real-time stream showing how your team's actual workflow practice is drifting from the documented workflow, with entries rolling in as new transitions are recorded. A steady upward drift trend can appear well before a release crunch, giving the team time to correct either the workflow or the practice. A quiet stream means current practice matches documentation—the steady-state target.

Workflow Transition Matrix(2.1.6)

Heatmap matrix with the "from" status on rows and "to" status on columns; cell color encodes how often that exact transition happened. A healthy matrix is dominated by forward diagonal movement; off-diagonal cells expose backward transitions and unintended shortcuts. High volume on "To Do -> Done" cells, for example, almost always points to skip transitions bypassing required workflow steps. Use Deep Analysis to get an AI-generated read on which off-diagonal cells matter most and what question each one raises about how work moves.

Workload Distribution by Project(2.1.10)

Bar chart of total event volume per project over the whole recorded history—aggregates all workflow activity by project; the page's date and project filters do not narrow it. An 80/20 split where one project dominates is often a sign that resources need rebalancing or that quieter projects are being neglected. Unexpected spikes in a previously quiet project may signal escalation or crisis; a balanced distribution typically indicates healthy portfolio management. Use Deep Analysis to get an AI-generated read on whether your current distribution reflects intentional focus or unmanaged drift.

Worklog Effort Distribution per Actor(4.5.9)

Horizontal bar chart showing total worklog hours and average hours per week per actor, ranked by total hours descending. Useful as a sanity check rather than a performance metric—two teams can burn similar effort and ship very different amounts of work. It answers how logged hours are spread across the team, and raises the question of how work is assigned. Each actor is labeled with the type Jira reports for the worklog's author: a person, an app such as Automation for Jira, a service-desk customer, or unknown when Jira returned no type. Use Deep Analysis to get an AI-generated read on which actors' effort patterns have changed enough to be worth a conversation.

Worst breach multiplier(3.5.4)

The largest ratio of delivery time to SLA budget among delivered tickets in the window. Tickets that were abandoned are excluded from the ratio: a stale ticket someone cleaned up is not a late delivery. For example, a 4.7x multiplier means one ticket took nearly five times its allowed window—worth a forensic timeline review. The budget is the target resolved from your configured SLA policy by issue type where set, and a MetaFrazo default otherwise.

Worst-project P90 lead time(2.7.3)

The highest per-project 90th-percentile lead time — creation to delivery — in the most recent complete week: in the slowest project, 90 percent of delivered tickets closed faster than this number. Whether a closing status counts as delivered follows your organization's terminal-status settings (a MetaFrazo default applies until configured); discarded and canceled work is excluded and reported as its own count. This is an exact statement about one project rather than a portfolio percentile, and it is the card for spotting where delay concentrates: a rising worst-project P90 with a stable average means one corner of the portfolio is slowing while the rest holds pace. This card reads the latest complete week and names the week it read.

Zero-comment close rate(5.2.1)

Share of the tickets first delivered in the selected date range, each counted once per project on its first move into a delivered status (a ticket moved between projects counts in each project it was delivered in, with only the comments recorded in that project), that closed with no comment recorded in Jira at all. A closure without a recorded comment is not proof that no review happened, and trivial tickets often close without discussion; a high rate shows a reviewer where to ask how reviews are recorded. Counted over closures into delivered statuses only, under your organization's terminal-status settings (a MetaFrazo default applies until configured); zero-comment discards are backlog hygiene and are not counted.

Zero-Comment Closures by Project(5.2.5)

Stacked bar chart per project comparing delivered closures that had no comment recorded in Jira with those that had at least one. Closures into statuses your organization classifies as abandoned (a MetaFrazo default applies until configured) are backlog hygiene and are not counted. A zero-comment closure means no comment was recorded on the issue, not that no review happened: a review can take place in a pull request, a meeting or another tool. Where a project's zero-comment rate is above MetaFrazo's 15% reference level, a reviewer could ask where the review of those closures is recorded. Use Deep Analysis to see which projects and kinds of work account for the zero-comment closures.