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 average covers complete weeks only. The week in progress is shown as its own bar but does not enter the average.

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 Accountability Rate(4.4.8)

Per-project percentage of events with known actor attribution (latest available week). Color-coded: green 75 percent or above, amber 60-74 percent, red below 60 percent. Auditors care about this number more than most -- significant actions without identifiable owners are a compliance gap. A project below 60 percent usually has automation or integration sources logging without an actor identity. Use Deep Analysis to get an AI-generated read on which projects' attribution gap is automation-driven versus governance-driven.

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 individual non-compliance. 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 Cycle 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 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.

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

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 authorising 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 recent weeks contained portfolio-level anomalies -- unusual deviations from the recent baseline across multiple projects. Spikes here often signal a shared external event rather than independent project issues.

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.

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 the primary process bottleneck -- focus improvement efforts there, not on execution speed. If the same stage (e.g. In Review) is slow across all projects, the problem is structural -- a shared resource or process constraint; a project where To Do dominates has a backlog problem, not a delivery problem. Use Deep Analysis to get an AI-generated read on whether your bottleneck is project-specific or organizational.

Avg Accountability Rate(4.4.4)

Average accountability rate across actors -- the share of significant actions clearly attributed to a single owner rather than diffuse or unowned. Auditors care about this number more than most.

Avg alert density(5.7.4)

Average rate of compliance alerts raised per project. High alert density without scoring improvements usually means alerts are firing but not acted on -- a process bottleneck rather than a detection problem. The week in progress is shown at its value so far. Because the week is not yet complete, it is marked as still in progress and does not enter the trend comparison.

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.

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 -- what share of expected controls are actively enforced. A high score means the controls exist; the next question is whether they're effective.

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. The week in progress is shown at its value so far. Because the week is not yet complete, it is marked as still in progress and does not enter the trend comparison.

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. The week in progress is shown at its value so far. Because the week is not yet complete, it is marked as still in progress and does not enter the trend comparison.

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. The week in progress is shown at its raw count so far. Because the week is not yet complete, it carries no week-over-week change and does not enter the moving average.

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.

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 week carried too few events to support a score are left out of the average rather than counted as zero.

Avg volatility index(2.5.2)

A summary measure of how shuffled your tickets are across teammates. Higher values mean the same tickets keep changing hands; lower values mean ownership tends to stick once assigned.

Avg Weekly Hours Logged(4.5.3)

Average weekly hours logged by contributors. Useful as a sanity check rather than a performance metric; sustained increases over months often correlate with later burnout. The average covers complete weeks only. The week in progress is shown as its own bar but does not enter the average.

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

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.

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

Backward Transitions(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.

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: median 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, so a busy project's 10 alerts 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.

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. The average covers complete weeks only. The week in progress is shown as its own bar but does not enter the average.

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 in the window 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.

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.

Control Effectiveness(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)

Tickets currently stuck in an active status well past a healthy duration. These are the ones masquerading as active work but not actually moving; left alone they slip into release retrospectives as surprises.

Cross-Project Contagion Matrix(3.6.6)

Matrix showing which project pairs share the most actors who triggered risk events. When the same individual triggers governance failures in multiple projects simultaneously, it isn't coincidence -- it's contagion. Helps identify whether risk is spreading through shared team members, contractors, or service accounts operating across project boundaries. Use Deep Analysis to get an AI-generated read on which project pairs' shared-actor contagion looks structural and what containment looks like.

Cross-Project Spread(5.3.7)

Flags actors who became newly active across three or more projects within a two-week window -- 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-Project 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. Strong correlations identify which projects are likely sharing a failure mode that manifests jointly. Use Deep Analysis to get an AI-generated read on which project pairs' correlations look causal and what shared dependency to investigate.

Cross-Team Collaboration Index(4.5.7)

Matrix showing the percentage of tickets where each pair of actors both generated events within the same project. Higher values mean more frequent joint working; low collaboration with high specialisation is normal in expert teams, low both is silos worth addressing. The matrix is most useful for spotting unexpected collaboration pairs (often a hidden mentor-mentee relationship) and absent expected pairs (which often reveals a structural communication gap). Use Deep Analysis to get an AI-generated read on which collaboration shapes argue for team-design changes.

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 by Priority(2.7.6)

Median and P90 cycle time 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. A large gap between Highest and Low median cycle times confirms priority triage is working as intended; similar medians between High and Medium suggest these two levels aren't being treated differently and one is redundant. A wide P90 versus median 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.

Cycle Time Control Chart(2.7.12)

Statistical-process-control view of cycle time for delivered issues, with average and upper-control-limit bands drawn in. 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; the trend of the average is the long-term capability signal. Teams using this in retrospectives typically focus on the outlier weeks first, then the band drift over months. 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.

Cycle Time Impact: Reopened vs Direct(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.

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), 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→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.

Direct Open→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.

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." The week in progress is shown at its raw count so far. Because the week is not yet complete, it carries no week-over-week change and does not enter the moving average.

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 -- chronic governance failures become 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.

Event Density Anomaly Detector(4.2.9)

Control chart of portfolio-wide weekly event count with a 14-week rolling mean and plus-or-minus two-standard-deviation control limits. Weeks exceeding the upper limit are highlighted red as statistical anomalies. Flags portfolio-level event volume that deviates meaningfully from the recent baseline -- often a shared external event (a major release, an incident, a process change) rather than independent per-project issues. Use Deep Analysis to get an AI-generated read on which anomaly 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.

Event Volume by Actor(5.6.5)

Per-actor activity profile showing total event count and the mix of action types. The breakdown makes role-versus-action mismatches visible -- an actor who is mostly configuration changes may be an admin, or may have access they shouldn't be using. 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 dominant activity is configuration changes may have more access than the role requires. 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 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. Typical response and tail response are drawn on two separate charts, because across measured portfolios the slowest one percent commonly runs hundreds of times longer than the median, and on a shared axis the median bar reads as nothing. 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.

Forensic 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, reopens, comments. 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.

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, Accountability, and Control Coverage (0-100 each, latest available 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 Accountability needs role discipline; 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.

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 programme, 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 measuring fewer than two of the three 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 consecutive recent weeks the backlog grew (arrivals outpacing resolutions). A streak of three or more is a useful trigger for planning-room conversations about capacity vs scope. The week in progress is shown at its value so far. Because the week is not yet complete, it is marked as still in progress and does not enter the trend comparison.

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 with the highest segregation-of-duties risk scores. Usually a small number; their patterns deserve targeted review rather than blanket policy changes.

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

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

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.

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 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 acknowledgement. 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 look causal 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, week by week. 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-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.

Latest governance score(3.1.3)

The most recent MetaFrazo Governance Score for your portfolio, 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. The day in progress is shown at its value so far. Because the day is not yet complete, it is marked as still in progress and does not enter the trend comparison.

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

Median cycle time(2.7.2)

Half of your delivered tickets went from creation to delivery faster than this number, half took longer. Only tickets whose closing status counts as delivered under your organization's terminal-status settings enter the median (a MetaFrazo default reading of the status name applies until configured); discarded and canceled work is counted separately, not as delivery. Median is the right measure for "typical" cycle time because it ignores the long tail of outliers.

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 a healthy threshold, with off-hours measured in the organization's time zone. Often a leading indicator of burnout risk in addition to a compliance 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, deliberate timing to avoid visibility, or 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 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 completed tickets that were later reopened, across your selected projects and window. A sustained value above 10-15 percent usually points to weak definition-of-done or thin 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.

P90 cycle time(2.7.3)

90 percent of delivered tickets went from creation to delivery faster than this number, counted under your organization's terminal-status settings (a MetaFrazo default applies until configured). The P90 is what you use for setting honest expectations with stakeholders -- "most issues close within X days" -- without being misled by the easy ones. Discarded and canceled work is excluded from this percentile and reported as its own count.

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.

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 multiple permission-drift signals -- reporter changes, bursts, cross-project spread, self-assignment hotspots, churn -- 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 Activity Density(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.

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. Use Deep Analysis to get an AI-generated read on which projects' staffing pattern warrants resilience attention.

Portfolio Anomaly Heatmap(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 chronic governance failure needing escalation; 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.

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.

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, accountability, 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 restricted this way and can still include the week in progress.

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). 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. Normalizes across projects of very different scale so cross-project comparison stays apples-to-apples. 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 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.

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.

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. Priority here is the last observed priority 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 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 Ranking(5.7.9)

Leaderboard ranking every project by its current weekly compliance score. Green is above 80 (on target), amber is 60-79 (watch), red is below 60 (immediate attention). 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. The top is good practice worth sharing; the bottom is the agenda for the next focused review. 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 Risk Ranking(4.2.8)

Ranked table of every tracked project by current composite risk score -- 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 hidden 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. The week in progress is shown at its value so far. Because the week is not yet complete, it is marked as still in progress and does not enter the trend comparison.

Projects Improving(4.2.4)

How many projects are showing meaningful risk-score improvement. The good-news counterpart to the Elevated / Critical KPI; the two together give a balanced executive picture. The week in progress is shown at its raw count so far. Because the week is not yet complete, it carries no week-over-week change and does not enter the moving average.

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.

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.

Projects Tracked(4.1.4)

How many projects MetaFrazo currently has under analysis for your organization. Sanity check before drawing portfolio-level conclusions.

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 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 too long). A non-zero count is something to act on this morning. The week in progress is shown at its rate so far. Because the week is not yet complete, it carries no week-over-week change.

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 -- each bar shows total completions and total reopens side by side. Projects above 15-20 percent reopen rate warrant a direct process review; projects at zero may be genuinely clean or closing tickets that were never actually completed, both worth a spot check. A large gap between projects on the same team suggests process consistency issues that culture or coaching can address. 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 reopen rate is accelerating, holding steady, or decelerating. Negative momentum is healthy; positive momentum is the early-warning indicator a quality conversation should follow. 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. Weeks with no changelog activity are unmeasured and never count as zero-reopen weeks in the momentum averages. 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 is deteriorating quality; a falling line is improvement. A week whose events carried no changelog activity has no measurable rate: it plots as a gap and does not enter the moving averages. Most diagnostic on month-over-month timeframes -- weekly noise tends to obscure underlying trend. A project whose reopen rate doubles over a quarter likely has either a scoping problem or a definition-of-done problem; the chart shows the trajectory but the 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 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.

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.

Risk Distribution by Project(3.3.6)

Distribution of risk scores across all open tickets per project. Individual high-risk tickets are problems; a project where most open tickets have elevated scores is a structural governance failure. 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.

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. 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 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 risk turning into compliance risk, 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-organising 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 compliance gaps. 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.

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 four SLA-consumed bands -- on track, caution (50-80 percent), warning (80-100 percent), in breach (over 100 percent). 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 last observed priority change and is blank when the events carry no priority information.

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 prioritising 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 plots no rate rather than 0, and the abandoned count rides in the same row. 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.

SLA Compliance 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. 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 and a visible quality problem. Types below 80 percent have a structural delivery problem requiring process redesign; types above 90 percent indicate strong SLA discipline; a high-compliance type with a rising breach trend is heading toward a problem worth catching early. 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 analysed 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.

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

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 Carry-Over Rate(2.4.6)

A per-sprint stacked bar showing tickets completed before sprint close versus those carried over, with KPI badges for latest carry-over percentage, trend, and sprint count. A sustained high rate signals sprint scope that's consistently too ambitious, and a growing rate is more concerning than a stable one; a declining trend is clear evidence that planning discipline is improving. Use Deep Analysis to get an AI-generated read on whether your trend is recoverable, structural, or already healing.

Sprint Carryover Signal(1.6)

Shows the active sprint's carry-over percentage with context against the last six sprints. A 47 percent carry-over above a 30 percent team average surfaces amber to flag a scope conversation for the next planning meeting; "highest in 6 weeks" is the early-warning callout.

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 is one of the clearest signs of governance failure: either the ticket was never worked, or its history was made to look complete. 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.

Status Category Drift(1.18)

Flags status names that map to more than one Jira status category across your workflows: silent drift that breaks category-pivoted queries, automations, and reports. A status mapping to two categories is bad; three categories is severe.

Status Category Drift(5.10.7)

Table of status names that map to more than one Jira status category (To Do, In Progress, Done) across the tenant's workflows. Each row is a silent configuration drift signal with severe impact: filters return different result sets depending on the source workflow, and category-based reports quietly double-count or miss work. A status mapping to three categories is more severe than two. Use Deep Analysis for an AI read on each drifting status, the human impact, and the most likely remediation.

Status Category Drift Matrix(5.10.8)

A status-name by project matrix for the status names that drift across status categories. Each cell shows the category (To Do, In Progress, Done) that one project's workflow assigns to that status name, color-coded so disagreements stand out at a glance -- and links straight to that project's workflow configuration. Where the flat drift list tells you a name is inconsistent, the matrix tells you exactly which workflow says what, so you know which one to fix.

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.

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 all activity events by type -- status changes, comments, worklog entries, field updates, others. A team can be very busy in Jira while tickets barely move; a healthy mix shows status changes as the dominant activity. High comment-to-status-change ratios often signal unclear requirements or ongoing back-and-forth slowing delivery; very low worklog activity alongside high status changes 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 median and P90 badges. A median first-move above two days suggests intake isn't being triaged fast enough; a large long-tail bucket points to a bimodal pattern where some tickets are picked up immediately and others are systematically ignored. 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 recently, 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 bar chart of the custom fields receiving the most write activity over the last 12 months. 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. Note that low-activity fields used by automations or integrations can still be load-bearing, so verify before deleting. 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 average covers complete weeks only. The week in progress is shown as its own bar but does not enter the average.

Top bottleneck(2.7.4)

The status where tickets currently spend the most time on average. The highest-leverage spot to fix if you want overall cycle time to drop; usually a review, approval, or test step rather than active development.

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 someone is deliberately bypassing approvals; 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.

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 tickets reached a completed status in the window (the denominator for the reopen-rate calculation). Useful sanity check 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.

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.

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.

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

Total spikes(3.2.1)

The total number of backlog-spike events detected in the window across all your projects. A single number that summarises 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 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.

Transitions Events Table(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.

Trigger Attribution Breakdown(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.

Type Reclassification Flows(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.

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

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 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 Cycle Time Trend(2.7.9)

Weekly trend of median AND P90 cycle time for delivered tickets on the same chart -- the P90 surfaces tail risk that a stable median can hide. 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 percentiles and reported as its own count. A rising P90 with a stable median is one of the clearest early-warning signs of SLA drift: most work is still on pace but a growing subset is taking 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 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; sustained climbs without matching throughput growth often precede burnout, retention issues, or process drift. 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 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. Sustained increases over months often correlate with later burnout; sudden drops may indicate disengagement or a change in role. Use Deep Analysis to get an AI-generated read on which actors' patterns warrant 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)

A per-project average and peak count of tickets concurrently in progress, with a pressure badge that flags projects where peak work-in-progress far exceeds the configured limit. Flagged projects are likely seeing delivery slowdowns that velocity metrics won't reveal, while projects comfortably below the limit are focused and predictable. 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 are currently above their healthy WIP ceiling. If this is zero, your teams have headroom; if it's growing week over week, the system is overheating before symptoms surface elsewhere.

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(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. Sustained high weekly hours often correlate with later burnout; the chart pairs naturally with engagement and retention conversations. Use Deep Analysis to get an AI-generated read on which actors' effort patterns warrant a wellness check.

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.

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.