Cross-Module UAT — Open High/Critical Bugs & Improvements

1. Bugs by Module, Source and Status

Every High/Critical bug currently WITH WHITESHIELD, split by source (Client = client-raised, has a Client Jira link; Internal = raised by us) and status. Tickets already completed by WS and awaiting Client verification (Client Validation) are not counted here - they appear in the Client-only table below.

24h Created counts genuinely new tickets only. Re-opened Client tickets - each logged as a fresh ticket on the WS board when Client re-opens - are excluded from 24h Created and shown separately under 24h Reopen.

2. Bugs by Module and Area - Functional vs Data Migration

Every open High/Critical bug (Client-raised and Internal together), grouped by area - Functional (Reopen vs New/Other) and Data Migration - and raw WS Jira status.

Legend: each cell shows two clickable counts - Client-raised / Internal. A grey 0 means no tickets on that side.

Data Migration = carries a data-migration label on the WS board. The Functional rest splits into Reopen (client re-opened - the ticket title starts with REOPENED; each client re-open is logged as a fresh WS ticket) and New/Other. Columns are the raw WS Jira workflow statuses; the same bugs as the table above, Client-raised and Internal combined.

3. Bugs (Client only) by Module and Status

Where the Client-raised bug load stands. To Do and WS Implementation reflect our board (linked to our Jira - To Do = not started, WS Implementation = in progress); Client Validation and Hold are pulled live from the Client Jira board and linked there (Validation = Deployed to staging + In Staging testing, completed by WS and awaiting Client verification).

Total = To Do + WS Implementation (open with WS, from WS Jira) + Client Validation (completed by WS, awaiting Client verification, from Client Jira) + Hold (from Client Jira).

Cross-check vs the by-source table above: the 50 here = 23 with WS + 27 in Client Validation. The With WS total above (38) = 23 Client-raised with WS + 15 Internal - it excludes the 27 in Client Validation, which are with Client for verification.

1 item(s) currently syncing between the boards (counted once on each side until the next sync): SE-209

4. Bugs - Created vs Closed (3-Week Trend and Forecast)

Cumulative Created vs cumulative Closed over the last 3 weeks (21 days). Created counts ALL intake - both new and re-opened Client tickets (every Client re-open is logged as a fresh ticket on the WS board); Closed counts tickets closed on the Client board (any Done-category status). The gap between the two lines shows whether the open load is closing (narrowing) or enlarging (widening). Open Trend forecasts the landing point for the items currently with Whiteshield (same scope as the first chart: Client-raised and Internal, High/Critical; items in Client Validation are with Client and outside this balance): a Monte Carlo simulation of 10,000 runs burns down the pending balance at the daily closure throughput observed on the Client board over the last 3 weeks, marking the dates by which all pending items are closed with 50 percent and 85 percent confidence. New intake after today is not modeled.

5. Bugs (Client only) by Module, Priority and Status

Client-raised bugs by priority (Critical = Client Highest, High = Client High) and status.

6. Improvements by Module, Source and Status

Client-raised improvements currently WITH WHITESHIELD (our type Enhancement = client Improvement) for Scholarships and Exemptions. Items in Client Validation are not counted here - see the Client-only table below.

24h Created counts genuinely new tickets only. Re-opened Client tickets - each logged as a fresh ticket on the WS board when Client re-opens - are excluded from 24h Created and shown separately under 24h Reopen.

7. Improvements - Created vs Closed (3-Week Trend and Forecast)

Cumulative Created vs cumulative Closed over the last 3 weeks (21 days). Created counts ALL intake - both new and re-opened Client tickets (every Client re-open is logged as a fresh ticket on the WS board); Closed counts tickets closed on the Client board (any Done-category status). The gap between the two lines shows whether the open load is closing (narrowing) or enlarging (widening). Open Trend forecasts the landing point for the items currently with Whiteshield (same scope as the first chart: Client-raised and Internal, High/Critical; items in Client Validation are with Client and outside this balance): a Monte Carlo simulation of 10,000 runs burns down the pending balance at the daily closure throughput observed on the Client board over the last 3 weeks, marking the dates by which all pending items are closed with 50 percent and 85 percent confidence. New intake after today is not modeled.

8. Improvements (Client only) by Module and Status

Where the Client-raised improvement load stands. To Do and WS Implementation reflect our board (linked to our Jira); Client Validation and Hold are pulled live from the Client Jira board and linked there.

Total = To Do + WS Implementation (open with WS, from WS Jira) + Client Validation (completed by WS, awaiting Client verification, from Client Jira) + Hold (from Client Jira).

Cross-check vs the by-source table above: the 23 here = 21 with WS + 2 in Client Validation. The With WS total above (21) = 21 Client-raised with WS - it excludes the 2 in Client Validation, which are with Client for verification.

9. Improvements by Module, Priority and Status

Client improvements by priority and status.