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 40 here = 9 with WS + 31 in Client Validation. The With WS total above (20) = 9 Client-raised with WS + 11 Internal - it excludes the 31 in Client Validation, which are with Client for verification.

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

Running totals of the Client-raised load, counted in Client-board tickets and accumulated over the whole engagement - the chart and the table below it both cover the last 3 weeks (21 days), and every count links to the tickets behind it. Created counts every item raised on the Client board; Closed on WS Jira marks a ticket once every WS ticket linked to it (re-open rounds included) is closed - the fix is delivered from the WS side; Closed on Client Jira counts tickets verified and closed by Client. Because the totals are all-time, the vertical gaps are the live backlog: Created minus Closed on WS Jira = still with Whiteshield, the gap between the two Closed lines = delivered and awaiting Client validation, and Created minus Closed on Client Jira = everything open on the Client board - matching the by-module table above. Open Trend forecasts the landing point for the Client-raised items currently with Whiteshield (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 (Client only) - Created vs WS Closed vs Client Closed (3-Week Trend and Forecast)

Running totals of the Client-raised load, counted in Client-board tickets and accumulated over the whole engagement - the chart and the table below it both cover the last 3 weeks (21 days), and every count links to the tickets behind it. Created counts every item raised on the Client board; Closed on WS Jira marks a ticket once every WS ticket linked to it (re-open rounds included) is closed - the fix is delivered from the WS side; Closed on Client Jira counts tickets verified and closed by Client. Because the totals are all-time, the vertical gaps are the live backlog: Created minus Closed on WS Jira = still with Whiteshield, the gap between the two Closed lines = delivered and awaiting Client validation, and Created minus Closed on Client Jira = everything open on the Client board - matching the by-module table above. Open Trend forecasts the landing point for the Client-raised items currently with Whiteshield (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 22 here = 20 with WS + 2 in Client Validation. The With WS total above (20) = 20 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.