KPI Dashboard Requirements and Data Quality Audit

Develop a KPI dashboard requirements package and data quality audit from the information and evidence supplied below.

Inputs

Blocking prerequisites:
- Business goal: [Business goal]
- Dashboard audience: [Dashboard audience]
- Decisions the dashboard should support: [Decisions the dashboard should support]
- Possible KPIs: [Possible KPIs]
- Data sources: [Data sources]
- Stakeholder questions: [Stakeholder questions]

Useful supporting context:
- Current reports: [Current reports]
- Known data quality issues: [Known data quality issues]
- Update frequency: [Update frequency]
- Tools available: [Tools available]
- Definitions or formulas: [Definitions or formulas]
- Definition of done: [Definition of done]

ChatGPT operating boundaries

Use ChatGPT to inspect and synthesize only the text, tables, schemas, query results, report extracts, data dictionaries, screenshots, or files actually made available in the chat through enabled capabilities. State which materials were inspected. Do not imply that ChatGPT connected to a database, queried a BI platform, profiled a full dataset, validated a production dashboard, or changed any system unless direct execution evidence is supplied in the conversation.

You may propose metric logic, SQL or pseudocode, validation queries, dashboard requirements, test specifications, and visualization designs. Label these as proposed and unexecuted. Do not claim that a test passed or failed from a proposed query alone. Treat supplied query results or profiling outputs as execution evidence only when their source, scope, and run context are identifiable.

Do not publish, approve, deploy, edit, or certify a dashboard. Final metric approval, source-of-truth designation, access authorization, financial reconciliation, privacy review, and production release remain human responsibilities.

Input triage and missing-information rules

1. Check the blocking prerequisites before developing the package.
2. Request clarification before proceeding when the business goal, audience, supported decisions, KPI candidates, source inventory, or stakeholder questions are absent or mutually incompatible.
3. If partial progress is safe, continue with a bounded draft. Mark unresolved items as Unknown, Conflict, or Approval required; explain the consequence; and do not invent formulas, thresholds, targets, owners, benchmarks, source fields, or stakeholder priorities.
4. When definitions conflict, preserve each definition, identify its source, explain the reporting impact, and name the decision owner needed to resolve it.
5. If only metadata or sample rows are supplied, limit conclusions to that scope. Do not generalize sample observations to the complete dataset.

Evidence discipline

Classify material statements using these labels where relevant:
- Supplied fact: explicitly stated in the inputs or source material.
- Inspected observation: directly visible in supplied evidence; cite the artifact, table, field, report, or result.
- Execution evidence: result from an identified query or test that was actually run and supplied.
- Assumption: a bounded premise used to continue.
- Hypothesis: a possible explanation requiring a test.
- Unknown: information not available.
- Conflict: incompatible definitions or evidence.
- Recommendation: proposed design or action.

Keep proposed checks separate from executed checks. Never convert absence of evidence into evidence that data is complete, accurate, timely, unique, or reconciled.

Workflow

1. Establish the decision contract.
- Restate the business goal, intended audience, review cadence, decisions, and actions the dashboard must support.
- Map each stakeholder question to a decision and anticipated action.
- Define measurable dashboard success criteria from the supplied definition of done.
- Exclude metrics and content that do not influence a stated decision.
- Record open questions that could change scope or interpretation.

2. Review and prioritize KPI candidates.
Classify each candidate as Core KPI, Supporting metric, Diagnostic metric, Vanity metric, Not recommended, or Pending definition. For each candidate, document:
- stakeholder and decision served;
- management action it could trigger;
- rationale for the classification;
- placement on the main view, drill-down, supporting report, or exclusion list;
- risk of misinterpretation or gaming;
- definition status and approval owner.

Reject or defer a KPI when it lacks a decision link, stable definition, feasible source, appropriate grain, or responsible owner. Do not prefer visual appeal over decision utility.

3. Build the metric dictionary.
For every recommended KPI, specify:
- canonical metric name and aliases;
- business definition;
- formula or calculation steps;
- numerator and denominator, including zero-denominator behavior;
- unit, currency, sign convention, and rounding;
- event date or accounting date used;
- reporting grain and aggregation behavior, including whether the metric is additive, semi-additive, or non-additive;
- source system, tables or entities, required fields, and system of record status;
- join keys, expected join cardinality, deduplication rule, and late-arriving data treatment;
- filters, exclusions, cohort rules, status rules, and cancellation or refund treatment;
- dimensions and permitted segments;
- comparison period, baseline, target, or benchmark only when supplied;
- time zone, fiscal calendar, and period-closing rules;
- refresh cadence, latency tolerance, and restatement policy;
- metric owner, approver, and access restrictions;
- known caveats, unresolved conflicts, and human review requirements.

If calculation logic is missing, provide a definition template and list the exact decisions needed to complete it rather than fabricating a formula.

4. Audit source fitness.
For each source, assess the supplied evidence for:
- system and business owner;
- entities, fields, grain, date coverage, and history retention;
- extraction method and access requirements;
- freshness and refresh behavior;
- completeness, validity, uniqueness, consistency, and referential integrity;
- join keys and cardinality risks such as many-to-many inflation;
- slowly changing dimensions, mutable historical values, and snapshot availability;
- time-zone, currency, tax, unit, and fiscal-calendar handling;
- manual entry, backfill, deletion, schema-change, and source-system migration risks;
- privacy classification and whether personal, confidential, regulated, or financial data is involved;
- KPI coverage and fitness conclusion.

Rate each source as Supported by evidence, Partially supported, Unsupported, or Unknown. Include the evidence reference and confidence rationale. Do not assign a favorable rating solely because a source exists.

5. Specify data quality and reconciliation controls.
Design controls relevant to the proposed metrics, including missing required values, duplicates, invalid formats or domains, impossible values, outliers, broken joins, unexpected cardinality, inconsistent definitions, stale loads, time-zone shifts, currency or unit mismatches, manual-entry errors, historical gaps, schema drift, and source changes.

For each control, provide:
- control identifier and related KPI;
- failure mode and business consequence;
- fields, grain, scope, and comparison period;
- proposed SQL, pseudocode, or reproducible test procedure when feasible;
- threshold and its provenance; if not supplied, mark Threshold awaiting owner approval and optionally offer a clearly labeled candidate for discussion;
- expected observation;
- actual observation only when execution evidence is supplied;
- evidence reference and run timestamp if supplied;
- owner, severity, escalation route, and remediation action;
- retest requirement and status: Proposed, Executed-pass, Executed-fail, Blocked, or Not run.

Include reconciliation controls where applicable, such as dashboard totals versus ledger, billing platform, CRM, warehouse, or an approved existing report. Define acceptable variance only from supplied policy; otherwise leave it pending approval.

6. Design the dashboard information architecture.
Recommend a practical structure for the available BI tool and team capacity:
- executive decision summary;
- core KPI scorecards with period comparison and freshness status;
- trend analysis;
- approved segment breakdowns;
- diagnostic drivers and drill paths;
- data quality, reconciliation, and refresh indicators;
- metric definitions, assumptions, caveats, and last-updated details.

For each section, state the user question, metric, grain, default filters, visualization, interaction, drill-down, and reason for inclusion. Address misleading axes, truncated scales, dual-axis confusion, inappropriate aggregation, excessive precision, inaccessible color use, small-sample disclosure, and comparisons across incomplete periods.

7. Create implementation requirements and traceability.
Translate the design into requirements with:
- requirement identifier;
- stakeholder need and supported decision;
- metric or control dependency;
- source and required fields;
- transformation or semantic-layer requirement;
- visualization or interaction requirement;
- priority and rationale;
- accountable owner and approver;
- dependency, privacy or access constraint, and failure impact;
- acceptance criterion and required evidence;
- status: Ready, Blocked, Pending clarification, or Pending approval.

Maintain traceability from stakeholder decision to KPI, metric definition, source, quality control, dashboard component, and acceptance criterion. Flag every broken link.

8. Determine build readiness.
Choose exactly one status:
- Ready to build: every core KPI has an approved calculation-ready definition, identified source and fields, acceptable source evidence, approved access, specified controls, resolved critical conflicts, and testable acceptance criteria.
- Ready for prototype only: enough information exists for a non-production prototype, but definitions, evidence, access, controls, or approvals remain incomplete.
- Ready after minor fixes: bounded issues have owners and do not threaten core metric validity once corrected and retested.
- Not ready: unresolved issues could materially change KPI values, expose protected data, break reconciliation, or mislead decisions.

Provide criterion-by-criterion evidence for the selected status. A proposed test is not proof of readiness. If no profiling or reconciliation results were supplied, explicitly state that data quality remains unverified and limit the readiness claim accordingly.

Safety and stop conditions

- Do not request or reproduce passwords, API keys, connection strings, or unnecessary personal data.
- Prefer schemas, aggregated extracts, masked samples, and field-level profiling over row-level sensitive records.
- Stop and request human review if the design may expose personal or regulated data, permit re-identification, conflict with access policy, or use sensitive attributes for segmentation without authorization.
- Require finance or accounting owner approval for revenue, margin, cash, tax, or investor metrics and reconciliation.
- Require legal, privacy, compliance, or regulatory review when applicable.
- Do not recommend production release when a critical KPI definition, source lineage, reconciliation, access approval, or severe data quality issue is unresolved.
- Preserve current approved reports and definitions until authorized replacements are validated; recommend versioning and rollback to the last approved dashboard or metric definition for implementation handoff.

Required output

## 1. Scope and Materials Inspected
List supplied materials actually inspected, unavailable evidence, scope limitations, assumptions, unknowns, and conflicts.

## 2. Dashboard Decision Contract
Summarize goal, audience, cadence, decisions, actions, exclusions, success criteria, and blocking questions.

## 3. Stakeholder Decision Matrix
Provide a table with Stakeholder, Decision, Question, Required evidence, Review cadence, Trigger condition, Likely action, and Confirmation status.

## 4. KPI Prioritization Register
Provide a table with KPI, Classification, Decision link, Actionability, Main view or drill-down placement, Definition status, Misinterpretation risk, Owner, and Recommendation.

## 5. Metric Dictionary
Provide the complete calculation and governance fields defined in the workflow. Use TBD only with a named resolution question and owner.

## 6. Source Fitness and Lineage Matrix
Provide source-level assessments, evidence references, KPI coverage, join and grain risks, privacy constraints, confidence, and fitness status.

## 7. Data Quality and Reconciliation Control Register
Separate proposed controls from supplied execution results. Include expected versus actual observations, evidence, severity, owner, response, retest requirement, and status.

## 8. Dashboard Information Architecture
Describe sections, user questions, metrics, filters, visuals, interactions, drill paths, caveats, freshness indicators, and accessibility considerations.

## 9. Requirements and Traceability Matrix
Connect every requirement from stakeholder decision through KPI, source, control, dashboard component, acceptance criterion, evidence requirement, owner, and handoff status.

## 10. Readiness Decision
State one allowed readiness status, criterion-level evidence, blockers, approvals, residual risks, and the conditions required to advance.

## 11. Verification and Acceptance Checklist
For each acceptance check, include Check, Expected result, Actual result, Evidence, Owner, and State. Use Not run or Blocked when no execution evidence exists. At minimum verify:
- every core KPI has a stakeholder decision and action;
- definitions specify grain, formula, filters, time handling, and ownership;
- source grain and joins cannot silently duplicate or omit values;
- core metrics reconcile to an approved reference where required;
- refresh timing meets the stated decision cadence;
- visuals use valid aggregation and comparison periods;
- privacy and access requirements are approved;
- critical controls have executed evidence before production acceptance.

## 12. Handoff Plan
Prioritize clarification, definition approval, access work, remediation, test execution, prototype work, stakeholder review, and production approval. Name owners where supplied and preserve unknown owners as unassigned.

Final integrity check

Before returning the package:
- ensure no unsupported benchmark, formula, threshold, owner, result, or approval is presented as fact;
- ensure observations identify their supplied evidence and scope;
- ensure proposed, executed, blocked, unverified, approved, and completed states remain distinct;
- ensure dashboard recommendations do not outrun source fitness or data quality evidence;
- ensure the readiness decision agrees with the unresolved blockers and acceptance checklist;
- ensure consequential financial, privacy, compliance, executive, investor, or customer-facing reporting is assigned human review.