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.

Active custom fields(1.14)

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 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. 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 weekly event count per actor over time, with a consistency rating: steady contributors rate high, irregular ones rate low. Variability alone isn't a problem, but paired with sustained absence it becomes a useful retention or wellness signal. A team of mostly consistent contributors is a sustainable engine; one dominated by irregular patterns is structurally fragile. Use Deep Analysis for a read on which irregular patterns are role-driven versus warning signs. An actor active in only one week of the window 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. An actor at the top with a high bypass count warrants a direct conversation; a service account or integration ranking high is a security concern. A broad spread across many actors points to a process-design problem rather than to any one person. Use Deep Analysis for a read on which actors need conversations and which signals 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. 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 median 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. An actor well above the portfolio median with a high ticket count warrants a conversation; compare issue types before drawing conclusions, and a cluster near the median indicates a balanced team. Use Deep Analysis to get an AI-generated read on the team-balance picture and which 1:1 conversations are highest leverage.

Actor Ownership Churn Ranking(2.5.9)

Ranks actors by a weighted ownership churn score that separates triage behavior from avoidance patterns. 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 may be dropping work, and churn concentrated in one or two actors is a bus-factor risk. Use Deep Analysis to get an AI-generated read on each top actor's specific pattern and what's likely driving it. 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. Cross-portfolio actors are bus-factor risks for the projects depending on them; specialists may need cross-training to maintain delivery resilience. A team where most actors are amber or red is structurally spread thin; a team where most are green has deep focus but limited interchangeability. 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 -- particularly important for identifying over-permissioned accounts (service accounts with admin rights they shouldn't have) or unusual activity from unrecognized admin accounts. A service account appearing at the top with deletion events is a potential security concern; accounts with no recognized name or unclear purpose warrant an immediate access review. Use Deep Analysis to get an AI-generated read on which actors warrant access review and which look operationally normal.

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.

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.

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 a governance red flag; consistent low-level activity spread across weeks is normal housekeeping. A spike dominated by deletion events (field deletions, user removals) is more significant than a creation spike and warrants closer review. 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 structurally unstable ownership for that work; a project dark across all types signals a portfolio-wide accountability problem. Use Deep Analysis to see which cells matter most and what a process clarification should target.

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 indicate broader changelog policy gaps. Use Deep Analysis to get an AI-generated read on which event-type gaps are most diagnostic of the underlying policy gap. 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, the team has likely loosened acceptance criteria without realising it. This rate covers every week in the selected range, including the week in progress.

Avg carryover %(2.4.2)

The average percentage of sprint scope that the team carried over from one sprint to the next, across recent sprints. Useful for spotting structural over-commitment rather than one bad sprint.

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(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, accountability, 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(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, accountability, 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.

Avg lead time(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 Lead Time(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. 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 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, root-cause discipline across the team is slipping.

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. 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.

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 open tickets by age since their last status transition across four buckets: fresh (0-7 days), aging (8-14), stale (15-30), frozen (30+). When frozen issues exceed 50 percent of open issues in any project, an amber banner is shown. A large frozen bucket is the clearest signal of a backlog problem -- those tickets are occupying planning space without prospect of delivery. Frozen-dominated projects need a deliberate grooming session, not just faster delivery. Use Deep Analysis to get an AI-generated read on which projects' frozen volume warrants triage first. 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 sat untouched the longest -- 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, but it marks closing and reopening habits worth a direct conversation. A spread across many actors points to a systemic process gap; the same name recurring across compliance visuals is a stronger escalation signal. Use Deep Analysis to see which actors warrant a one-on-one and what to discuss.

Backward Transition Rate Over Time(5.1.5)

Grouped bar chart of weekly forward workflow transitions alongside backward ones (Done or Closed reopened into an active status). When backward transitions stay above a small baseline share, rework is structural rather than incidental -- a sign that requirements, handovers, or definition-of-done are unclear. Use Deep Analysis to see whether rework concentrates in specific projects, periods, or actors, and what to address first.

Backward transitions(5.1.1)

How often tickets move backward in the workflow (for example, from In Review back to In Progress). Some backward movement is healthy (revising work after feedback); excessive backward movement signals process or quality problems. 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. Use Deep Analysis for an AI read on whether your batch closes are efficient reviews or process bypass, 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.

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.

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.

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 signals multiple concurrent control gaps and a pattern of process bypass, not an isolated 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: observed priority, inactivity, reopen history, priority escalation history, and a single-observation flag. A ticket whose priority never appears in the event stream shows Unknown and carries no priority points. This measures governance risk, not complexity: high-scoring tickets show multiple warning signs that they may not resolve cleanly without intervention. The top 5-10 are usually your next focused-effort backlog. Use Deep Analysis for a read on each top ticket's risk shape and the most likely intervention. 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 creation date cannot be computed: the Created column shows a dash rather than a guess. Those issues are still ranked. The window places them by the date MetaFrazo first observed the issue, 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. 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 or changed, fields and field contexts added 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) and destructive ones (deleted, trashed, soft-deleted). 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, User, Project, Other). 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 points to a well-governed, stable instance. 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)

How many contributors show consistent week-over-week activity. A higher count means a more sustainable workforce; a low number with high concentration means the team relies heavily on a few engines. Actors without enough history to measure (a single active week) 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.

Contributor Acceleration Index(2.4.10)

A per-actor index comparing the work each person advances against what they create or are assigned; 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. This isn't a performance ranking, but when low-index contributors coincide with backlog growth it's worth a targeted conversation. 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 resolutions that passed all defined controls -- worklog present, a second actor involved before closure, and required workflow stages traversed. It's the most direct measure of program effectiveness, revealing how much work is escaping the compliance safety net: above 90 percent is strong discipline, below 70 percent means the program isn't in routine use. Use Deep Analysis for an AI read on which controls are most frequently bypassed and which projects need attention.

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 of compliance health that individual signals can obscure -- three or more consecutive weeks of rising deviations means the program is losing ground. A flat or declining trend with steady activity volume indicates discipline is holding. 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 effectiveness is improving or whether more work is slipping through the cracks; a rising compliant share reflects successful enforcement, a falling share is an early warning. 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.

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, you have a portfolio-level problem rather than a few outlier tickets.

Critical issues(5.4.2)

How many of the detected events crossed the critical-severity threshold. These are the events to address this week, not next quarter.

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 tickets are sitting in a non-done 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. 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 -- when two separate projects both experience issue spikes at the same time, consistently, it may not be coincidence. Shared deployment pipelines, infrastructure components, or dependencies can cause correlated failures across multiple projects simultaneously. A pair that stands out above the rest of the matrix is a candidate for a shared timing driver, worth investigating together rather than separately. Portfolio-wide swings in activity raise many pairs at once, so read any single pair against the whole matrix. Use Deep Analysis to get an AI-generated read on which pairs stand out against the portfolio-wide pattern 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 -- one of the clearest early signals of access drift. Sudden multi-project access may be a legitimate role change or access granted without proper review; gradual expansion is far less concerning. A clean chart indicates stable, predictable access across the portfolio. Use Deep Analysis to see each flagged actor's expansion shape and which need verification 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. 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 — the bar is drawn, 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, accountability, and control coverage. Consistently above 80 signals healthy governance; watch for sustained downward trends and when they began. 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. Persistent gaps where creation exceeds resolution are early warnings to address before they become a resourcing crisis; convergence over time suggests a well-balanced team at steady cadence. 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.

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 a targeted enforcement gap, while a project dark across all types signals a culture problem rather than a type-specific one. A uniformly light heatmap indicates consistent compliance across all work categories. Use Deep Analysis for an AI read on which cells matter most and what targeted enforcement should look like.

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 the team is either closing tickets without doing the work or skipping the review stages that catch quality issues. 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-end pressure; a steady decline means workflow compliance is improving. 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. 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.

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 shows remediation working. 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, stabilising after an intervention, 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 look most concerning and which deserve a "what worked" study. 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 warrant attention, from automation under a user's credentials to inactive accounts that should be deprovisioned. 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. Aligned actors are operating as expected. 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 were almost certainly never worked -- they were rubber-stamped, possibly to inflate completion metrics. 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 signals systematic rubber-stamping; a distribution skewed toward longer lifecycles is healthy. Use Deep Analysis to see which projects and actors drive the fastest closures and where to focus an investigation.

Field events(2.2.2)

Configuration events specifically affecting custom fields and their contexts: fields added, deleted, or moved to trash, plus field contexts added, removed, or reconfigured. Often the noisiest category in a healthy admin practice. Counts the selected date range, bucketed by week, so a week is included when it starts inside the range.

Field events(2.6.2)

Permission events affecting field configuration -- adding restricted fields, changing who can edit a field, restructuring field-permission contexts. Often the most subtle category and the one auditors ask about most.

First Response Time(2.7.11)

How long new issues wait before someone first responds, either a comment on the issue or its first move out of the opening status, whichever comes first. 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 step is shaded by how long work typically waits there, the busiest hand-offs stand out, and a side panel ranks the distinct routes work takes end to end — 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. 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. 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 shows every actor and the share behind each one.

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.

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. Bright cells outside the dominant pattern often indicate automation or after-hours human activity worth verifying. 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 consumed enough of their SLA budget to be at significant risk of breaching soon (typically above 80 percent consumed). These are still recoverable with a same-day push. Tickets whose creation was never observed cannot be aged and are not counted here; the SLA Breach Clock shows them in its age-unknown segment, so read this number as a floor.

Inactive count(3.3.4)

How many high-risk-scoring tickets are also currently inactive (no recent transitions or comments). 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. 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(1.15)

Shows the share of your projects in each activity bucket: active (events in the last 90 days), slowing (90-180), dormant (180-365), abandoned (365+), archived (removed from active use at the Jira level but recoverable), and deleted (permanently removed). When dormant, abandoned, and archived together exceed roughly a third of the portfolio, project pickers and filters start returning stale results, so it is worth a cleanup pass.

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(1.12)

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.

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 maps directly to this view -- faster resolution and a tighter distribution are stronger MTTR. A long right tail in either cohort reveals where capacity should be targeted. Use Deep Analysis to get an AI-generated read on what's driving the slow-end distribution and how to compress it.

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)

Permission events affecting issue type configuration -- new issue types, changed permission schemes per type, retired types. Less common than user events but 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 currently past their SLA budget. Each is a customer commitment we're failing to keep; pair with priority + customer-visible flag to triage the order of escalation. Tickets whose creation was never observed cannot be aged and are not counted here; the SLA Breach Clock shows them in its age-unknown segment, so 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, accountability, 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.

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 creation to first delivered resolution) 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 reveal type-specific process or capacity issues -- if Bug lead time held steady while Feature lead time doubled in the last quarter, the team is keeping reactive promises but starving proactive work. Use Deep Analysis to get an AI-generated read on which type's divergence is most diagnostic of an underlying capacity allocation problem.

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. 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 that shouldn't exist often signals a routine workaround, while a map that matches your documentation is strong evidence practice and policy align. 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: the missing-approval rate. Closures into abandoned-classified statuses are backlog hygiene and are not counted (a MetaFrazo default applies until configured). A dark cell at one project-and-type combination points to a targeted policy failure; a project dark across all types signals a portfolio-wide culture problem. A uniformly light heatmap is the target state. Use Deep Analysis to see which cells matter most, what they point at, and what an intervention should look like.

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. Tickets reopened twice or more should be discussed in the next retrospective; if several cluster in the same project or epic, the problem may be at the requirement or design level rather than execution. Use Deep Analysis to get an AI-generated read on whether your top repeat-reopens share a root cause and where to invest in clarity.

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 for new accounts. A moderate first week is normal onboarding; an unusually high one may indicate account takeover, improper access provisioning, or a service account given overly broad access. Multiple burst actors in the same period often signal a systematic provisioning gap. 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. 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. Use Deep Analysis for an AI read on which off-hours patterns look like automation, 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. A consistent cell across weeks often flags automation or someone deliberately working unusual hours. Use Deep Analysis to see whether the pattern is automation, after-hours work, or 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. A long tail of issues older than 90 days is the usual signature of unmanaged scope creep -- visible in this view even when each individual project looks healthy on its own. Concentrations in the 0-7 day band are healthy intake; concentrations in 90+ are structural drag. Use Deep Analysis to get an AI-generated read on which projects' age shape argues for active triage versus accepted noise.

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 and discarded work is excluded. Unowned in-progress work is a governance and delivery risk that needs immediate action — assign it or move it back to backlog; a large unowned backlog count indicates grooming isn't happening regularly. Use Deep Analysis to get an AI-generated read on which ownership gaps need immediate action and which are symptoms of intake-process problems.

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 permission-related events into four buckets: user, field, issue type, and project. A sudden field-level spike without related user changes often means someone restructured the permission scheme, making this a useful daily compliance touchpoint.

Permission drift events(1.3)

How many access-related changes have occurred over the recent window -- users added or removed, fields and project permissions altered, issue type permission schemes touched. 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. 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)

Time series of detected events as a percentage of total activity rather than an absolute count, which is the more meaningful view since a busier portfolio naturally has more incidents. A falling rate as activity grows means hygiene is improving; a rising rate signals that the share of work generating exposure is increasing. The plotted total 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 tells you where to focus training. A project with zero detections may be very clean or simply low on text, so context matters. Use Deep Analysis to see which projects to prioritize and the highest-impact training topic.

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. Use Deep Analysis to see which actors to approach individually and which patterns suggest a team-level fix.

PII Severity Score Distribution(5.4.10)

Distribution of current detections across four severity tiers, from Critical down to Low. Not every detection needs the same urgency: a phone-shaped digit run in a closed ticket differs from email-plus-digits in an active one. A high Critical count needs immediate action; a large Medium count is lower urgency but still needs a remediation plan, since the data persists after closure. Low is the numeric-ID-only tier and carries the highest false-positive rate. Use Deep Analysis to see which Critical entries to triage first and what a remediation queue should look like.

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. Identifies projects with too few contributors (concentration risk) -- a project with very few active actors is fragile to individual unavailability, a key bus-factor risk for the portfolio. A project where the events-per-actor ratio is very high suggests work is concentrated on a small number of 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. Use Deep Analysis to get an AI-generated read on which projects' staffing pattern warrants resilience attention.

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 compliance on a 0-100 scale. Each cell is the average of that project's weekly scores across the selected window, so it summarizes a period rather than a moment. A project dark across all three warrants immediate leadership attention; bright in velocity but dark in quality 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. 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, using unique-issue counting so each ticket is counted once. 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 this week than last 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 -- if it's trending down sustainably, the underlying interventions are working. 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 warrant escalation versus monitoring. 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 systematic pattern of de-escalations can signal priorities inflated at creation and quietly downgraded, or sprint pressure driving deprioritization to dodge missed-target accountability. A balanced, low-volume distribution indicates stable, accurate initial prioritization. Use Deep Analysis for an AI read on which projects show priority gaming and how to address it.

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 activity is often used to game SLA tracking, not to reflect changing urgency. 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 has a specific capacity problem at the top of the queue, not a general delivery problem. Healthy patterns put breach rate inversely to priority (Highest breaches least); inverted patterns reveal escalation paths that aren't actually accelerating delivery. Use Deep Analysis to get an AI-generated read on which priority+project cells are most diagnostic and what they call for.

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(2.2.4)

Configuration events touching projects themselves -- creating, archiving, renaming, or reassigning a project's lead. Less frequent but each event tends to have a bigger downstream effect on the dashboard.

Project events(2.6.4)

Permission events at the project level -- adding admins, changing roles, reassigning project lead, updating permission schemes. The biggest blast-radius category; each one is worth a quick look.

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 based on the recent trend slope. 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 MetaFrazo currently has under analysis for your organization. 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 problem in one project is contained, the same problem across ten projects is a process gap.

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. Use Deep Analysis to see which tickets to spot-check first and the likely process gap.

Rapid-transition issues(5.1.3)

Number of tickets that have undergone many status changes in a short window -- often an early sign someone is using the workflow to "look busy" rather than to manage work.

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 (share of resolved tickets that came back) alongside mean time between incidents. A recurring incident is a systemic failure left unaddressed at its root. High recurrence with low time between incidents is active firefighting; high recurrence with long gaps usually reflects scheduled-but-incomplete fixes. Use Deep Analysis for a read on which projects' recurrence is structural and the likely root cause.

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.

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 indicates a systemic problem, while spikes in specific weeks often track sprint pressure or deadline crunch; a sustained decline is strong evidence that process improvements are working. 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 ranked table of which actors triggered the most reopen events, with reopen count, unique issues reopened, and 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. 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.

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 warrants investigation; spikes often track reviews, incidents, or deliberate record manipulation. Use Deep Analysis to see whether the pattern is automation, legitimate 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. In some projects Bugs carry the highest risk; in others it's Stories or Tasks. Bright cells are diagnostic targets for governance attention -- a project where Bug risk dominates likely has a quality and triage problem; one where Story risk dominates has a scoping or specification problem. Use Deep Analysis to get an AI-generated read on the most concentrated risk cells and what category of intervention they call for. 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, evidence that an intervention is having a real effect rather than a temporary dip. It's the good-news complement to the escalation timeline, useful for sharing post-mortems on what worked. 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 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 a dash in the Week column and are grouped by the week MetaFrazo first observed them, 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. 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)

Tickets that show signs of rubber-stamp closure -- closed fast, with no review activity, often by the same actor who opened them. The most visible signature of process bypass. 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.

Schema Change Category Breakdown(2.6.8)

A proportional split of permission-drift events by category (field, user, project, scheme). 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. The person who creates work shouldn't be the only one approving its completion, so a rising rate is the early signal that independent review is breaking down. A clean trend means two-actor closure is the norm. 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. 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. Use Deep Analysis to see whether the variance reflects healthy team design or a process gap.

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.

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 the separation of duties compliance relies on was entirely absent. A high hop count over a short span is the most critical pattern, and actors recurring across weeks warrant review. An empty log means every ticket had at least two distinct actors, a healthy sign. Use Deep Analysis to see which actors warrant a conversation and the likely process gap.

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, platform teams and service accounts that work across many projects, and is not itself a finding. 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 closures where the creator also closed the issue against closures involving at least one other actor. A solo close means no independent review and no peer validation -- the most basic form of missing approval. A rising solo-close rate signals deteriorating approval discipline; a consistently low rate is the target. 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. Use Deep Analysis to see whether the pattern is role-driven or culture-driven, and which actors warrant a closer look.

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 (over 100 percent), and age unknown for tickets whose creation was never observed, which are drawn in their own segment rather than dropped. Each ticket's budget is a target resolved from your configured SLA policy by 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. 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 process gap they all share. 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)

Summarizes the last 24 hours of SLA activity: how many tickets breached and how many are at risk, meaning over 80 percent of their time budget is already consumed. A Highest-priority bug at 92 percent consumed shows amber so the team can act before it becomes a recorded breach. 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", "approaching breach", "in warning", or "already breached". Not a historical chart -- a live exposure snapshot for prioritizing action. A ticket showing "207 percent of SLA target consumed" isn't just overdue; depending on your compliance obligations it may require formal incident documentation. 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, 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 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 an anomaly; a multi-week increasing trend is systemic. Catching the deterioration early -- before three consecutive bad weeks -- is the whole point. Projects trending up from 3 percent to 12 percent over two months usually have either a capacity or an SLA-aggression problem, each with different fixes. Use Deep Analysis to get an AI-generated read on which projects' trend looks recoverable versus structural. 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)

Percentage of analyzed actors flagged as participating in patterns that violate segregation-of-duties expectations (for example, both opening and closing the same ticket). 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 tickets that were resolved end-to-end by a single contributor with no other actors involved. Tells you how much of your work is genuinely two-person-reviewed versus relying on the original author's judgment. 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 indicates stable, predictable inflow -- a positive governance signal. 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 carry-over(1.2)

The share of work items that rolled over from the previous sprint into the active one. Useful for measuring planning accuracy and execution capacity; sustained high values mean the team is consistently overcommitting.

Sprint Open Share(1.6)

Share of the issues in the most recent sprint that are not yet in a done status, measured now, shown against the same share on the six sprints before it. The share starts high at sprint start and should fall as the sprint runs; a share that stays high late in the sprint, or sits well above the earlier sprints' shares, is the cue for a scope conversation at the next planning meeting.

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 shown. 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 to get an AI-generated read on whether the trend is recoverable, structural, or already healing.

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. 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) indicates a capacity or maturity problem specific to that project. 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(1.18)

Counts the status-category conflicts observed across your workflows, of two kinds, and every finding says which kind it is. A name collision is two or more different statuses that share one display name while sitting in different categories, so statusCategory = "Done" in JQL returns one project's issues and silently omits another's. A category change is a single 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 tile means neither kind was observed, which is the healthy state.

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 is the healthy state.

Status Transition Frequency(1.16)

Shows the most-used status names over the last 12 months. Near-duplicates with different casing or spacing ("Ready for review" vs "READY FOR REVIEW") are a textbook drift signal; an excess of Done-bucket statuses ("Done", "Completed", "Resolved", "Closed") in the top 10 means status names are being used where Resolution values should be.

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(1.13)

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.

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)

Surfaces tickets that have stayed in the same status well past a healthy duration: items waiting on review for days, or sitting in QA without progress. Catching these early helps you clear ticket-flow bottlenecks before they affect a whole sprint. A healthy 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.

Stuck-in-Status Detector(3.1.6)

Open tickets stuck in the same status well past the normal time for that stage, ranked by how overdue they are. Velocity charts miss these because the tickets aren't moving, yet they're still delivery blockers. A cluster stuck in one status points to a shared bottleneck; a stuck ticket with no assignee is the highest priority. Use Deep Analysis for a read on which to triage first and the bottleneck driving the rest.

Team Engagement & Activity Mix(2.1.9)

Breakdown of the Jira events recorded for your site by event type -- issue creations and updates, comments, worklog entries, assignments, others -- with the number of distinct people behind each type. 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; a healthy mix shows issue updates as the dominant activity. High comment-to-update ratios often signal unclear requirements or ongoing back-and-forth slowing delivery; very low worklog activity alongside many issue updates can suggest time isn't being tracked accurately. Use Deep Analysis to get an AI-generated read on whether your team's activity mix points to clear scope, scope drift, or tracking gaps.

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(1.17)

Shows the custom fields receiving the most write activity over the last 12 months, with each field's type, helping you distinguish fields doing real work, worth careful change management, from clutter worth retiring. A field with "test" or "TDG" in its name still receiving edits in production is a likely retirement candidate.

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.

Top bottleneck(2.7.4)

The workflow status where work waits longest before moving on. The figure is an average dwell taken across every project and every day in the window at once, 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. 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. Actors high across multiple types are systematic bypassers; an actor high on one type may simply have a knowledge gap better closed with targeted guidance. A clean table indicates strong individual-level compliance. 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. Concentrated approval gaps often reflect a specific role or process issue rather than team culture. A high count with a high percentage may mean approvals are being skipped on that person's closures; a high count with a low percentage may just be a very active person, so context matters. Use Deep Analysis to walk through each top actor's pattern and what's likely driving it.

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 (field edits, user changes, project changes, scheme changes). 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 total number of open tickets across your tracked projects. A standing baseline you can compare week-to-week to spot growth, and the denominator behind several of the other backlog signals.

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 or a timestamp. 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 tickets have a recent risk score recorded. The denominator behind the rest of the section's signals. The date range counts issues that were alive in the window: created 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.

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. Closed and discarded work is excluded, so this is a live queue rather than a running total. Some unowned tickets are normal (fresh intake awaiting triage); a growing pool that doesn't drain is a sign triage capacity is the bottleneck.

Transition Events(2.1.12)

Detailed event log with one row per status-change event -- columns include issue key, summary, from status, to status, triggered by, and timestamp. 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 investigating: teams may be blocked or disengaged. 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)

Flags Highest- and High-priority tickets that currently have no assignee, with how long each has been unowned. For Highest priority, every hour without an owner is unmitigated risk; for High, the SLA window is four hours. Any Highest-priority entry here is the morning's first action: assign it now or escalate.

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. For Highest priority, every hour without an owner is unmitigated risk; for High priority, the SLA window is four hours. Any Highest-priority entry here requires an immediate response -- assign or escalate. A cluster from one project that grows over time indicates a systemic ownership assignment problem, not isolated incidents. Use Deep Analysis to get an AI-generated read on what's driving the recent ownership gap and how to prevent recurrence.

Unowned highest priority(3.1.4)

How many Highest-priority tickets are currently sitting without an assignee. Almost always zero in a healthy operation; a non-zero count is something to fix the same day.

Unowned in progress(2.5.4)

The narrower, more urgent slice: tickets that have moved into an active status 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 accountable individual -- worth fixing the same day.

User Account Change Timeline(2.2.9)

A weekly stacked bar of user account creations, updates, and deletions. Account changes are among the most compliance-sensitive events: deletions outside known offboarding windows and creation spikes without matching onboarding are potential audit flags, while a steady pattern aligned with HR cycles signals well-governed access. 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, bucketed by week, so a week is included when it starts inside the selected range.

User events(2.2.3)

Configuration events affecting accounts -- new users added, existing users deactivated, group memberships changed. The audit-relevant slice of the change stream. Counts the selected date range, bucketed by week, so a week is included when it starts inside the range. This total covers every week in the selected range, including the week in progress.

User events(2.6.1)

Count of user-account-related permission events in the window: accounts added or removed, group memberships changed, role assignments altered. Reconcile against your identity provider's off-boarding log.

User Lifecycle Heatmap(2.6.7)

Heatmap tracking user lifecycle events (creations, updates, deletions) across weeks. Among the most compliance-sensitive activities -- a week with multiple deletions 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. A predictable HR-aligned pattern indicates mature access governance. 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 team workload side by side and detect under- or over-activity across the portfolio. A project consistently dark may be understaffed for its scope; one consistently bright may be carrying disproportionate load relative to its peers. Use Deep Analysis to get an AI-generated read on which workload distributions look intentional versus accidental.

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 is evidence that ownership discipline is improving. 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 are meeting the governance baseline 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 average weekly event count per actor, with peak-week annotated. Useful for spotting volume outliers in both directions; designed for leadership conversations, not individual evaluation. A sustained increase or a sudden drop in an actor's event volume is a change worth understanding; the events show the change, not its reason. Use Deep Analysis to get an AI-generated read on which actors' patterns have changed enough to be worth a one-on-one and which look like role-appropriate cadence.

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 process gap they imply.

Workload Distribution by Project(2.1.10)

Bar chart of total event volume per project for the selected window -- aggregates all workflow activity by project. 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. The chart pairs naturally with engagement and retention conversations. 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 completed tickets that closed with no comments at all. Some zero-comment closes are legitimate (truly trivial tickets); a high rate usually means the team is skipping the documentation step under pressure. 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 showing the share of delivered closures that had no comments versus those closed with comments. Closures into statuses your organization classifies as abandoned (a MetaFrazo default applies until configured) are backlog hygiene and are not counted. A project where more than a small fraction of closures have zero comments has a systematic approval gap, not an isolated exception. A falling rate means review culture is strengthening; a rising one warns approval discipline is slipping. Use Deep Analysis to see what's driving the pattern and which projects to address first.