DQ Score Calculation
CryspIQ® surfaces a single Organisation DQ Score (0–100) on both the Function Dashboard and the Steward Dashboard. This page explains exactly how that score is derived, what drives it up or down, and how to interpret the result.
Purpose
The score is designed to:
- Decrease as the volume of open data quality issues grows
- Penalise overdue issues more heavily than fresh ones
- Apply a lighter penalty for ownership gaps
- Decay smoothly — so every issue resolved produces a visible improvement, even when overall volumes are high
Inputs
| Input | Description |
|---|---|
| Issues | All DataStewardIssue records returned by the API for the selected time range |
| SLA Days | The number of days before an open issue is considered overdue (default: 15 days) |
| Scope filter | When a Business Function or Data Steward is selected in the dashboard, only matching issues are included in the calculation |
Step 1 — Identify Open Issues
An issue is counted as open if its Status field is anything other than OK.
Resolved issues (Status = OK) are excluded from all score calculations.
Step 2 — Derive the Three Signals
From the set of open issues in scope, three counts are derived:
Overdue Issues
An open issue is overdue if its age exceeds the SLA threshold:
Age (days) = floor( (Now − ExceptionDateTime) / 86400000 )
Overdue = Age > SLA Days (default 15)
Critical Risks
An open issue is a critical risk if either:
- Its type is explicitly classified as
Critical, or - It has been open for more than 30 days regardless of type
Critical risks are surfaced as a standalone KPI in the dashboard header but do not feed directly into the score (they are already captured within the open and overdue counts).
Unassigned Ownership
An open issue is unassigned if it has no Business Function or no Data Steward name recorded.
In CryspIQ®, all source messages are governed and ownership is always assigned as part of the data governance framework. The unassigned count provides an early-warning signal for any newly arrived data that has not yet been mapped to a steward.
Step 3 — Weighted Pressure
The three signals are combined into a single weighted pressure value that reflects the composite health burden:
weightedBad = openCount
+ (2.0 × overdueIssues)
+ (0.5 × unassignedOwnership)
Weight rationale:
| Signal | Weight | Reason |
|---|---|---|
| Open issues | 1.0× | Baseline measure of outstanding work |
| Overdue issues | 2.0× | Represents a broken SLA commitment — carries twice the pressure |
| Unassigned ownership | 0.5× | A governance concern, but newly arrived data may not yet be breaching SLA — half weight |
Step 4 — Exponential Decay Formula
The weighted pressure is converted to a 0–100 score using an exponential decay curve:
k = ln(2) / 100 ≈ 0.00693
orgScore = round( 100 × e^(−k × weightedBad) )
= clamp to [0, 100]
The decay constant k is chosen so that 100 units of weighted pressure halves the score (the half-life point):
| Weighted Pressure | DQ Score |
|---|---|
| 0 | 100 — no open issues |
| 100 | 50 — half-life point |
| 200 | 25 |
| 300 | 13 |
This curve means:
- A perfect score of 100 requires zero open issues in scope
- The score never reaches zero unless weighted pressure is extremely high
- Every issue resolved always produces a measurable improvement
Score Bands
The score is grouped into three health bands used for colour coding across the dashboards:
| Score | Band | Colour |
|---|---|---|
| 85 – 100 | Healthy | Green |
| 70 – 84 | Watch | Amber |
| 0 – 69 | At Risk | Red |
League Table Score (Function and Steward)
The Function League Table and Steward's League Table use a simpler relative score based purely on open issue volume within each group:
dqScore (per function/steward) = max( 0, 100 − round( openCount / maxOpenCount × 100 ) )
Where maxOpenCount is the highest open issue count across all functions or stewards in the current view. This normalises performance so the worst performer scores near 0 and the best performer scores near 100, making the league table a relative ranking rather than an absolute health measure.
MTTR (Mean Time to Resolve)
The dashboard also surfaces MTTR in days, calculated as:
MTTR = average( FixDateTime − ExceptionDateTime )
Only issues with both an open date (ExceptionDateTime) and a close date (FixDateTime or ResolvedDate) are included. Issues where the close date precedes the open date are excluded.
Example
An organisation has the following open issues in scope:
- 40 total open issues
- 12 are overdue (older than 15 days)
- 5 have no steward assigned
Weighted pressure:
weightedBad = 40 + (2.0 × 12) + (0.5 × 5)
= 40 + 24 + 2.5
= 66.5
DQ Score:
k = ln(2) / 100 ≈ 0.00693
orgScore = round( 100 × e^(−0.00693 × 66.5) )
= round( 100 × e^(−0.4608) )
= round( 100 × 0.631 )
= 63
Result: Score of 63 — At Risk (red). The largest driver is the overdue issues, which are weighted at double the base rate. Resolving the 12 overdue issues would reduce weighted pressure to 42.5, lifting the score to approximately 74 — Watch (amber).
Adjusting the SLA Threshold
The SLA Days threshold (default 15) is configurable. Reducing it means issues are classified as overdue sooner, which increases overdueIssues and applies greater weighted pressure — resulting in a lower score for the same volume of open work. This allows organisations to tune the sensitivity of the score to their own governance commitments.