Reusable AI capability
Operationalize Approved Metrics Across Dashboards and Reports
Carry an owner-approved metric contract through an internal dashboard and disabled recurring report, then reconcile both outputs and prepare evidence for controlled release.
This Skill is a reusable set of instructions based on the linked Amo.ng Prompt or Workflow. It tells you what to provide, how to apply the method and how to know when the task is complete. It does not run automatically.
# Operationalize Approved Metrics Across Dashboards and Reports Skill ID: AMO-S-000037 Skill URL: https://amo.ng/skills/operationalize-approved-metrics-dashboards-reports Purpose: Enable analytics engineers, BI developers, operations teams, and metric owners to implement the same governed metric definitions consistently across interactive and recurring reporting. The capability produces traceable repository changes, calculation and access tests, source reconciliation, failure evidence, recovery instructions, and an accountable release handoff. It does not define disputed metrics or authorize production access, scheduling, delivery, or decision use. Required inputs: - Owner-approved metric contracts with stable IDs, formulas, grain, dimensions, time rules, units, tolerances, and owners - Approved dashboard requirements and disabled report/schedule contract - Authorized repository, schemas or read-only interfaces, and synthetic or sanitized fixtures - Roles, access boundaries, authoritative reconciliation totals, and data-freshness rules - Allowed files and commands, performance expectations, release owners, and rollback constraints How to use: When to use: - When approved metrics must be implemented in both an internal dashboard and a repeatable report; when existing reporting needs a governed implementation/reconciliation cycle; when release owners need observable evidence before enabling use. When not to use: - To resolve disputed metric meaning; to obtain production credentials; to mutate source records; to activate schedules or delivery; or to make management decisions. Method: Use W32 in order. Carry the owner-approved metric contract into the dashboard specification and implementations. Keep unresolved definitions blocked. Implement only within authorized repository/data boundaries. Reconcile representative dashboard and report values to authoritative supplied totals. Test access, dates/timezones, stale/partial/error states, reruns, idempotency, and recovery. Keep delivery disabled and route the evidence pack to metric, data, security, and release owners. Expected output: A metric-to-dashboard-to-report traceability register, change manifests, access and state tests, reconciliation matrix, failure/rerun evidence, disabled schedule/delivery proof, recovery instructions, and release-owner handoff. Boundaries: Do not redefine metrics, infer missing owner decisions, request or expose credentials, use unapproved personal or confidential data, treat fixtures as production evidence, deploy or enable production refresh, scheduling, delivery, or external communication, or claim accuracy, readiness, or successful implementation without executed evidence and accountable approval. Based on Workflow: Implement an Operations Dashboard and Automated KPI Reporting Source ID: AMO-W-000032 https://amo.ng/workflows/implement-operations-dashboard-automated-kpi-reporting Completion criteria: Complete when every implemented output traces to an approved metric ID; dashboard and report calculations use the same governed contract; access, stale/error, date/timezone, and rerun paths have recorded results; authoritative totals reconcile within approved tolerances or differences remain explicitly blocked; delivery remains disabled; and accountable owners receive the release and recovery evidence. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Operationalize Approved Metrics Across Dashboards and Reports Skill ID: AMO-S-000037 Skill URL: https://amo.ng/skills/operationalize-approved-metrics-dashboards-reports Purpose: Enable analytics engineers, BI developers, operations teams, and metric owners to implement the same governed metric definitions consistently across interactive and recurring reporting. The capability produces traceable repository changes, calculation and access tests, source reconciliation, failure evidence, recovery instructions, and an accountable release handoff. It does not define disputed metrics or authorize production access, scheduling, delivery, or decision use. Required inputs: - Owner-approved metric contracts with stable IDs, formulas, grain, dimensions, time rules, units, tolerances, and owners - Approved dashboard requirements and disabled report/schedule contract - Authorized repository, schemas or read-only interfaces, and synthetic or sanitized fixtures - Roles, access boundaries, authoritative reconciliation totals, and data-freshness rules - Allowed files and commands, performance expectations, release owners, and rollback constraints How to use: When to use: - When approved metrics must be implemented in both an internal dashboard and a repeatable report; when existing reporting needs a governed implementation/reconciliation cycle; when release owners need observable evidence before enabling use. When not to use: - To resolve disputed metric meaning; to obtain production credentials; to mutate source records; to activate schedules or delivery; or to make management decisions. Method: Use W32 in order. Carry the owner-approved metric contract into the dashboard specification and implementations. Keep unresolved definitions blocked. Implement only within authorized repository/data boundaries. Reconcile representative dashboard and report values to authoritative supplied totals. Test access, dates/timezones, stale/partial/error states, reruns, idempotency, and recovery. Keep delivery disabled and route the evidence pack to metric, data, security, and release owners. Expected output: A metric-to-dashboard-to-report traceability register, change manifests, access and state tests, reconciliation matrix, failure/rerun evidence, disabled schedule/delivery proof, recovery instructions, and release-owner handoff. Boundaries: Do not redefine metrics, infer missing owner decisions, request or expose credentials, use unapproved personal or confidential data, treat fixtures as production evidence, deploy or enable production refresh, scheduling, delivery, or external communication, or claim accuracy, readiness, or successful implementation without executed evidence and accountable approval. Based on Workflow: Implement an Operations Dashboard and Automated KPI Reporting Source ID: AMO-W-000032 https://amo.ng/workflows/implement-operations-dashboard-automated-kpi-reporting Completion criteria: Complete when every implemented output traces to an approved metric ID; dashboard and report calculations use the same governed contract; access, stale/error, date/timezone, and rerun paths have recorded results; authoritative totals reconcile within approved tolerances or differences remain explicitly blocked; delivery remains disabled; and accountable owners receive the release and recovery evidence.Copy Skill copies the full Skill instructions. Use with AI copies those instructions with a short guide for your chosen AI tool. Both actions only copy text—they do not send anything to an AI provider or run the Skill.
Portable Agent Skill
Instruction-only package. Inspect the contents and your agent client’s permissions before use.
Purpose
Enable analytics engineers, BI developers, operations teams, and metric owners to implement the same governed metric definitions consistently across interactive and recurring reporting. The capability produces traceable repository changes, calculation and access tests, source reconciliation, failure evidence, recovery instructions, and an accountable release handoff. It does not define disputed metrics or authorize production access, scheduling, delivery, or decision use.
Required inputs
Have these details available before following the usage instructions.
- Owner-approved metric contracts with stable IDs, formulas, grain, dimensions, time rules, units, tolerances, and owners
- Approved dashboard requirements and disabled report/schedule contract
- Authorized repository, schemas or read-only interfaces, and synthetic or sanitized fixtures
- Roles, access boundaries, authoritative reconciliation totals, and data-freshness rules
- Allowed files and commands, performance expectations, release owners, and rollback constraints
How to use this Skill
When to use:
- When approved metrics must be implemented in both an internal dashboard and a repeatable report; when existing reporting needs a governed implementation/reconciliation cycle; when release owners need observable evidence before enabling use.
When not to use:
- To resolve disputed metric meaning; to obtain production credentials; to mutate source records; to activate schedules or delivery; or to make management decisions.
Method:
Use W32 in order. Carry the owner-approved metric contract into the dashboard specification and implementations. Keep unresolved definitions blocked. Implement only within authorized repository/data boundaries. Reconcile representative dashboard and report values to authoritative supplied totals. Test access, dates/timezones, stale/partial/error states, reruns, idempotency, and recovery. Keep delivery disabled and route the evidence pack to metric, data, security, and release owners.
Expected output:
A metric-to-dashboard-to-report traceability register, change manifests, access and state tests, reconciliation matrix, failure/rerun evidence, disabled schedule/delivery proof, recovery instructions, and release-owner handoff.
Boundaries:
Do not redefine metrics, infer missing owner decisions, request or expose credentials, use unapproved personal or confidential data, treat fixtures as production evidence, deploy or enable production refresh, scheduling, delivery, or external communication, or claim accuracy, readiness, or successful implementation without executed evidence and accountable approval.
Based on an Amo.ng Workflow
Implement an Operations Dashboard and Automated KPI Reporting
Open the linked Workflow to read the instructions this Skill is based on.
Open workflow
# Implement an Operations Dashboard and Automated KPI Reporting
Workflow ID: AMO-W-000032
Workflow URL: https://amo.ng/workflows/implement-operations-dashboard-automated-kpi-reporting
## Outcome
Metric contract catalogue, dashboard specification, dashboard and reporting change manifests, source-to-output traceability, reconciliation matrix, failure/rerun tests, trust classification, decision restrictions, and release-owner handoff.
## Before you begin
- Decisions and users
- Disputed/current metric definitions
- Source contracts and authoritative totals
- Roles/access
- Dashboard interactions
- Report destinations/schedule kept disabled
- Repository/data context
- Acceptance and release owners
## Step 1 — Metric Definition Contract and Semantic Layer Blueprint
**Prompt**
Metric Definition Contract and Semantic Layer Blueprint
**Instructions**
Resolve metric definitions into governed, testable contracts and semantic-layer boundaries.
**Input for this step**
Decision uses, current definitions, formulas, grain, sources, owners, access and change rules.
**Carry forward**
Metric contract catalogue, lineage, tests, ownership and unresolved decisions for accountable-owner approval.
**Review note**
Stop if an accountable metric owner will not resolve a material definition conflict, and do not continue until the applicable metric contracts are owner-approved.
**Prompt ID**
AMO-P-000263
**Prompt URL**
https://amo.ng/prompts/metric-definition-contract-semantic-layer-blueprint
**Prompt content**
You are a senior analytics governance and semantic-layer architect experienced in business metric design, dimensional modelling, aggregation behavior, data lineage, access control, testing, versioning, and change management.
Your task is to turn disputed or inconsistently implemented business metrics into explicit, testable, versioned contracts and a practical semantic-layer blueprint.
Produce a metric contract catalogue, definition decision log, semantic model, lineage and consumer map, test specification, access-control plan, and controlled rollout roadmap. Treat all proposed definitions and implementations as candidates until the appropriate business and technical owners approve them.
## Context to Provide
Replace every bracketed placeholder. If blocking information is missing, ask for it in one consolidated list before recommending a governed definition. Continue with clearly labelled assumptions only when the missing information is non-blocking.
- [Metric governance objective and decision deadline]
- [Business decisions, audiences, and materiality]
- [Candidate metrics, aliases, and disputed definitions]
- [Source systems, models, and authoritative records]
- [Entities, events, facts, dimensions, and grain]
- [Metric formulas, types, units, and aggregation behavior]
- [Time, calendar, currency, status, and restatement rules]
- [Filters, cohorts, segments, exclusions, and edge cases]
- [Lineage, joins, transformations, and manual adjustments]
- [Existing reports, APIs, tools, and consumer dependencies]
- [Data quality evidence, tests, and reconciliation tolerances]
- [Access, privacy, retention, and audit constraints]
- [Owners, approval process, migration window, and allowed changes]
- [Definition of done]
## Evidence and Working Rules
- Separate confirmed evidence, assumptions, hypotheses, unresolved disputes, risks, recommendations, and owner decisions.
- Do not invent definitions, formulas, source behavior, owners, approvals, policies, lineage, test results, platform capabilities, or stakeholder consensus.
- Record each material source with its owner, scope, effective date, last-verified date, and known limitations.
- Preserve conflicting definitions until their intended decisions, populations, grains, time rules, and owners have been compared.
- Do not force one canonical metric when distinct business decisions require legitimate variants. Give each retained variant an unambiguous name, scope, and owner.
- Distinguish definition quality, implementation correctness, current data health, and consumer adoption. Approval in one area is not proof of the others.
- Prefer direct artifacts such as model definitions, transformation code, queries, contracts, policies, test results, and approved calculation examples.
- Use `Not provided`, `Not inspected`, `Not run`, `Unresolved`, or `Owner decision required` when evidence is unavailable.
- Do not describe an inspection, query, test, reconciliation, approval, deployment, or migration as completed unless its result was supplied.
- Redact credentials, personal data, customer records, financial details, and confidential values that are unnecessary for the analysis.
- Remain platform-neutral unless a semantic-layer tool is supplied. When proposing tool-specific syntax, use the supplied version and current authoritative documentation; otherwise provide pseudocode and label it accordingly.
## Metric Contract Requirements
For every proposed metric, define the applicable fields below.
### Identity and Governance
- stable metric identifier;
- display name and aliases;
- plain-language meaning;
- intended business decision;
- owner, steward, technical maintainer, and approver;
- lifecycle status;
- semantic version;
- valid-from and valid-to dates;
- review cadence and last-verified date.
### Population and Grain
- eligible population;
- entity being measured;
- event or state being observed;
- source fact;
- observation unit;
- calculation grain;
- reporting grain;
- primary and foreign keys;
- deduplication rule;
- join relationships and expected cardinality.
### Calculation
- metric type, such as simple, ratio, derived, conversion, cumulative, snapshot, or semi-additive;
- numerator and denominator where applicable;
- formula and calculation order;
- units, sign, precision, and rounding;
- currency source and conversion rule;
- weighting;
- null and zero handling;
- allowable dimensions;
- dimensions across which the metric must not be added or averaged;
- expected aggregation behavior.
For ratios, state whether the result is calculated as a ratio of aggregated components or an aggregation of row-level ratios. Do not treat these as interchangeable.
For conversion metrics, define the base event, conversion event, linking entity, qualifying sequence, conversion window, and attribution rule.
For cumulative metrics, define the window, time spine, reset behavior, and treatment of missing periods.
For snapshot or semi-additive metrics, define the as-of rule and the dimensions, especially time, across which addition is invalid.
### Time and State
- event, processing, effective, snapshot, billing, service, and accounting dates where relevant;
- selected reporting date;
- time zone;
- fiscal or calendar period;
- cutoff and lateness rules;
- status and eligibility rules;
- cancellation, refund, reversal, and reopening treatment;
- restatement policy;
- historical reproducibility requirements.
### Lineage and Controls
- authoritative source;
- source fields;
- transformations;
- joins;
- filters and exclusions;
- manual adjustments;
- semantic objects;
- downstream consumers;
- data-quality controls;
- access and privacy controls;
- reconciliation source and tolerance.
Manual adjustments must identify their owner, reason, source, effective period, approval, expiry or review date, and reconciliation treatment.
## Investigation Workflow
1. Define the governance objective, decisions being supported, materiality, deadline, owners, tools, consumers, and definition of done.
2. Inventory every current name, description, formula, query, model, dashboard calculation, spreadsheet adjustment, API field, and reported variant.
3. Build a dispute matrix showing where variants differ in business purpose, population, entity, grain, time, status, filters, formula, aggregation, source, or adjustment.
4. Determine whether each difference represents:
- an error;
- an outdated definition;
- a tool implementation difference;
- a data-quality problem;
- a legitimate decision-specific variant;
- or an unresolved owner decision.
5. Classify each metric by type and specify its aggregation behavior, allowable dimensions, null handling, and edge cases.
6. Trace source-to-contract-to-semantic-object-to-consumer lineage. Check keys, join cardinality, fanout risk, slowly changing dimensions, late-arriving data, duplicate events, and missing relationships.
7. Reconcile time, currency, status, eligibility, cancellation, refund, attribution, and restatement rules.
8. Identify every manual adjustment and determine whether it is governed, reproducible, approved, time-bounded, and visible in lineage.
9. Map access requirements from authoritative sources through the semantic or query layer to dashboards, APIs, exports, spreadsheets, embedded applications, and AI consumers.
10. Design contract tests, reconciliation fixtures, access tests, historical-comparison tests, and consumer-parity checks.
11. Classify proposed changes as editorial, non-breaking, behavior-changing, or breaking.
12. Design versioning, approval, dual-running, deprecation, migration, communication, rollback, and post-release monitoring.
13. Recommend the smallest safe next action that materially reduces uncertainty or implementation risk.
## Failure Modes to Test
Treat each item as a hypothesis until supported by evidence.
- The same metric name represents different business decisions, populations, grains, time rules, or statuses.
- A ratio is averaged or filtered differently across tools.
- A non-additive or semi-additive metric is summed across an invalid dimension.
- Event time, processing time, snapshot time, billing time, and accounting time are mixed.
- Many-to-many joins or incorrect cardinality inflate results.
- Slowly changing dimensions assign historical facts to the wrong current state.
- Duplicates, missing keys, late events, reversals, refunds, or reopened records change results inconsistently.
- Null values and true zero values are treated as equivalent.
- Manual spreadsheet adjustments become authoritative without controlled lineage.
- Currency conversion uses inconsistent rate dates, rate sources, or rounding.
- Dashboard-level filters or permissions are bypassed by APIs, exports, direct queries, or other consumers.
- A definition change silently rewrites history or breaks trend comparability.
- A technically consistent metric is treated as business-approved without owner review.
- A governed definition is assumed to guarantee current data quality.
- One canonical number suppresses valid variants needed for different decisions.
For each material hypothesis, state the confirming evidence, disconfirming evidence, missing evidence, affected decisions or consumers, and cheapest safe verification check.
## Decision and Safety Controls
- Keep business-definition approval with the named accountable owner.
- Require finance, accounting, privacy, legal, employment, clinical, or regulatory review when the metric affects those domains.
- Do not modify production models, semantic objects, reports, APIs, access controls, or published historical figures without approved impact analysis.
- Do not silently replace an existing metric definition.
- Require an explicit decision on whether a behavior-changing definition applies prospectively, restates history, or creates a versioned parallel metric.
- Enforce sensitive-data controls in the governed query path where possible, not solely through dashboard presentation.
- Test access behavior for each material consumer type and privilege level.
- Keep manual adjustments visible and reproducible.
- Use staged, reversible changes with documented rollback and reconciliation procedures.
- Record exceptions with their owner, justification, affected scope, approval, and expiry or review date.
- Do not substitute AI output for business, data, financial, privacy, or production approval.
## Output Contract
Use concise markdown and tables where they improve comparison, ownership, lineage, sequencing, or status tracking.
### 1. Input Sufficiency and Governance Boundary
State:
- governance objective;
- decisions and audiences;
- metrics in scope;
- authoritative evidence supplied;
- tools and consumers in scope;
- materiality and deadline;
- critical missing inputs;
- assumptions;
- responsible owners;
- activities that remain outside the analysis.
### 2. Decision and Metric Inventory
Provide:
| Decision | Audience | Metric or alias | Intended purpose | Current source | Owner | Materiality | Current status |
|---|---|---|---|---|---|---|---|
### 3. Definition Dispute Matrix
Provide:
| Metric or alias | Variant | Purpose | Population | Grain | Time rule | Formula or filter difference | Owner | Classification | Decision needed |
|---|---|---|---|---|---|---|---|---|---|
Classify each difference as error, outdated definition, implementation difference, data-quality issue, legitimate variant, or unresolved dispute.
### 4. Metric Contract Catalogue
Create a complete contract for each in-scope metric using the identity, population, grain, calculation, time, state, lineage, access, test, ownership, version, and validity requirements defined above.
Assign one status:
- `BLOCKED — CRITICAL INPUT MISSING`
- `OWNER DECISION REQUIRED`
- `CONTRACT CANDIDATE`
- `READY FOR PILOT`
- `READY FOR GOVERNED RELEASE`
- `DEPRECATED — MIGRATION REQUIRED`
Do not assign `READY FOR GOVERNED RELEASE` unless the supplied evidence includes the required approvals and test results.
### 5. Semantic-Layer Blueprint
Map:
- entities and keys;
- facts and dimensions;
- measures and derived metrics;
- metric types;
- join paths and cardinality;
- time dimensions;
- allowable dimensions;
- aggregation restrictions;
- naming and descriptions;
- defaults and null behavior;
- access policies;
- semantic versions;
- tool-specific implementation considerations.
If the selected tool cannot express a required contract rule directly, identify the limitation and propose an explicit upstream, downstream, or procedural control.
### 6. Lineage and Consumer Impact Map
Provide:
| Metric | Authoritative source | Transformations and joins | Manual adjustments | Semantic object | Consumer | Current version | Proposed impact | Owner | Migration requirement |
|---|---|---|---|---|---|---|---|---|---|
Identify ungoverned copies, embedded formulas, extracts, spreadsheets, APIs, and reports that could continue producing the old definition.
### 7. Test and Reconciliation Pack
Provide:
| Test | Contract rule | Fixture or evidence | Expected result | Tolerance | Execution layer | Owner | Status |
|---|---|---|---|---|---|---|---|
Include applicable tests for:
- uniqueness and referential integrity;
- join fanout;
- duplicates and deduplication;
- null and zero behavior;
- ratio aggregation;
- non-additive dimensions;
- time-zone and period boundaries;
- late-arriving events;
- slowly changing dimensions;
- cancellations, refunds, and reversals;
- currency conversion and rounding;
- historical restatement;
- access controls;
- cross-tool parity;
- reconciliation to authoritative records.
Do not invent expected numeric results. Where values are unavailable, specify the fixture structure and approval needed.
### 8. Access and Privacy Enforcement
Explain:
- restricted data and dimensions;
- applicable row-, column-, tenant-, purpose-, or region-level rules;
- enforcement location;
- affected identities and roles;
- API, export, spreadsheet, embedded, and AI-consumer behavior;
- evidence required to verify enforcement;
- exception and audit requirements.
### 9. Change, Versioning, and Migration Protocol
Define:
- change classification;
- proposal and approval workflow;
- semantic-version rule;
- validity dates;
- prospective versus historical treatment;
- dual-run and reconciliation period;
- affected consumers;
- deprecation notice;
- migration acceptance criteria;
- rollback trigger;
- audit record;
- post-release review.
### 10. Rollout and Adoption Plan
Provide:
| Phase | Action | Metric or consumer | Owner | Required evidence | Acceptance condition | Review gate | Rollback or recovery | Target date |
|---|---|---|---|---|---|---|---|---|
Separate pilot, reconciliation, owner approval, consumer migration, release, monitoring, and retirement.
### 11. Unresolved Decisions and Smallest Safe Next Action
List only unresolved questions that could materially change the contract or rollout.
End with the smallest reversible action that would most reduce uncertainty, naming the owner, required evidence, expected result, and completion condition.
## Verification Checklist
Before finalizing, confirm that:
- every metric supports a named decision and has accountable ownership;
- legitimate variants were not erased for naming simplicity;
- population, entity, event, grain, formula, unit, status, time, filters, and exclusions are explicit;
- metric type and aggregation behavior are defined;
- ratios distinguish ratio-of-aggregates from aggregation-of-ratios;
- non-additive and semi-additive dimensions are identified;
- join cardinality, fanout, duplicates, lateness, and slowly changing dimensions were considered;
- null, zero, refund, reversal, restatement, and historical rules are explicit;
- lineage reaches authoritative sources and material consumers;
- manual adjustments remain visible and governed;
- tests include reproducible fixtures, expectations, tolerances, owners, and execution status;
- access controls cover material query and export paths;
- definition approval is not represented as proof of current data quality;
- unrun tests and unresolved disputes are not described as complete;
- behavior-changing definitions have versioning, impact analysis, migration, and rollback;
- every conclusion is supported by supplied evidence or labelled as an assumption;
- no definition, implementation result, approval, or product capability was invented.
Begin by reviewing the supplied context for blocking gaps. If none remain, build the evidence inventory and complete the workflow in order.
## Step 2 — Dashboard Requirements Specification Prompt
**Prompt**
Dashboard Requirements Specification Prompt
**Instructions**
Turn approved contracts and user decisions into dashboard requirements.
**Input for this step**
Step 1 contracts, users/decisions, source constraints, interaction, access and delivery needs.
**Carry forward**
Implementation-ready dashboard specification, source mappings, data states, interactions and acceptance criteria.
**Review note**
Hold if decision use, source feasibility, access rules, or KPI intent remains contradictory.
**Prompt ID**
AMO-P-000058
**Prompt URL**
https://amo.ng/prompts/dashboard-requirements-prompt
**Prompt content**
Use ChatGPT to convert the supplied dashboard context into a decision-ready requirements specification that business owners, analysts, data engineers, BI developers, security reviewers, and testers can review and implement.
Inputs
- Dashboard objective and scope: [Dashboard objective and scope]
- Users and decisions: [Users and decisions]
- Metric definitions and targets: [Metric definitions and targets]
- Data sources and constraints: [Data sources and constraints]
- Interaction and delivery needs: [Interaction and delivery needs]
- Governance and operational constraints: [Governance and operational constraints]
- Existing artifacts and acceptance criteria: [Existing artifacts and acceptance criteria]
Input and clarification rules
1. Treat the objective, primary users, decisions to support, candidate metrics, and candidate data sources as minimum prerequisites. Named owners, wireframes, data dictionaries, sample extracts, query results, current reports, policies, platform constraints, service levels, and acceptance criteria are useful supporting evidence.
2. If the objective, primary decision, metric intent, or source feasibility is missing or contradictory, ask only the questions that block a reliable specification. Explain why each answer matters. Do not silently choose a business definition.
3. When bounded progress is possible, produce a clearly marked draft and preserve unresolved items in an open-questions register. Use provisional assumptions only when they are reversible and low risk.
4. Classify important statements as supplied fact, observed in an artifact, assumption, proposed requirement, conflict, or unknown. Cite the relevant artifact, page, table, field, query output, or stakeholder statement when that reference is available.
5. Do not infer that similarly named fields or KPIs are equivalent. Surface conflicts involving formula, grain, population, status logic, timezone, currency, fiscal calendar, historical treatment, or source of record.
ChatGPT capability and authority boundaries
- Inspect only text, files, schemas, screenshots, query results, and other materials actually available in the conversation. State when a file, live database, BI workspace, catalog, or external system is unavailable.
- Draft requirements, mappings, test cases, questions, and recommendations. Do not claim to have queried a database, profiled data, tested calculations, changed permissions, configured alerts, published a dashboard, or obtained approval unless direct execution evidence is supplied.
- Do not authorize KPI definitions, source-of-record choices, access rules, privacy classifications, or production releases. Assign these decisions to the appropriate business metric owner, data owner, security or privacy reviewer, and BI product owner.
- Do not reproduce credentials, secrets, or unnecessary personal or confidential records. If source material contains credentials or excessive sensitive data, stop that line of analysis and request a redacted or aggregated version.
- Treat compliance, privacy, financial, and employment-related measures as requiring human review. Recommend least-privilege access, aggregation or suppression where appropriate, and a rollback path for production publication or access changes.
Requirements development workflow
1. Frame the decision problem. Identify the dashboard purpose, in-scope and out-of-scope decisions, audiences, usage frequency, current workaround, business owner, expected action after viewing, and the cost of stale or incorrect information.
2. Define audience and access needs. Separate viewers, explorers, operators, metric owners, administrators, and approvers. Capture row-level or column-level restrictions, export permissions, regional boundaries, segregation requirements, and accessibility needs.
3. Build the KPI contract. For every KPI or diagnostic measure, define its business question, formula, numerator and denominator where applicable, aggregation behavior, unit, grain, dimensions, inclusion and exclusion rules, status logic, time basis, comparison period, target or threshold, display format, owner, source of record, and known caveats. Flag non-additive measures, ratios, distinct counts, snapshots, and metrics that cannot safely be summed across time or groups.
4. Map data feasibility and lineage. Connect each measure and dimension to source systems, tables or entities, fields, join keys, expected cardinality, transformation rules, history strategy, and owner. Address duplicate keys, nulls, late-arriving records, slowly changing dimensions, deleted records, backfills, timezone conversion, currency conversion, fiscal calendars, and mismatched grains. Mark mappings as confirmed only when supported by supplied evidence.
5. Specify the information architecture. Define pages or views, visual purpose, chart or table choice, grouping, sort order, labels, units, reference lines, explanatory text, default state, and empty, loading, stale, partial, and error states. Avoid visual precision unsupported by the data.
6. Define interaction behavior. Document filter scope and defaults, cascading behavior, date controls, cross-filtering, drilldown and drill-through paths, reset behavior, search, tooltips, export, subscriptions, alerts, bookmarks, and navigation. State what context must persist and how restricted or unavailable detail should appear.
7. Establish refresh and operational controls. Specify source availability, refresh cadence, acceptable data latency, freshness timestamp, failure notification, retry or recovery expectation, ownership, support route, retention, usage monitoring, performance targets, and change-control expectations. Distinguish business freshness from pipeline completion.
8. Resolve trade-offs explicitly. Compare alternatives where requirements conflict, including accuracy versus latency, detail versus privacy, flexibility versus performance, self-service versus governed definitions, historical restatement versus reproducibility, and feature scope versus delivery effort. Recommend an option with rationale, dependencies, and approval owner.
9. Prioritize implementation. Give each requirement a stable identifier, priority, rationale, dependency, accountable owner, acceptance method, and status. Separate minimum viable decision support from later enhancements; do not label unresolved dependencies as implementation-ready.
10. Design verification before handoff. Include calculation reconciliation, source-to-dashboard totals, filter and drill path checks, boundary dates, timezone and currency cases, null and duplicate handling, access-control tests, export behavior, refresh and stale-data behavior, performance, browser or device needs, and accessibility. Each test must state preconditions, test data or evidence, expected result, actual result, and status. If no test was run, record the actual result as unavailable and the status as not run.
Required output
1. Decision and scope brief
- Dashboard objective, supported decisions, audiences, expected actions, scope boundaries, success measures, assumptions, and blockers.
2. Evidence and uncertainty register
- Table with ID, statement, classification, evidence reference, confidence, conflict or limitation, impact, owner, and resolution needed.
3. Stakeholder and access matrix
- Table with audience or role, decisions supported, required detail, permitted interactions, data restrictions, approver, and unresolved access questions.
4. KPI dictionary
- Table with KPI ID, name, business question, precise definition, formula, grain, dimensions, filters, time basis, unit, target, aggregation behavior, source of record, owner, caveats, evidence status, and approval status.
5. Data mapping and lineage specification
- Table with requirement or KPI ID, source system, entity or table, fields, join keys, cardinality, transformation, history treatment, refresh dependency, data-quality rule, owner, and confirmation status.
6. Dashboard behavior specification
- Organize by page or view. For each component, provide its purpose, visual form, measures, dimensions, defaults, filters, interactions, drill path, tooltip content, restricted-data behavior, and empty, stale, partial, loading, and error states. Add a concise text wireframe when no supplied mockup is available.
7. Non-functional and operating requirements
- Cover freshness and latency, performance, accessibility, supported delivery channels, security and privacy, export controls, monitoring, failure notification, recovery, retention, support ownership, and change control. Use measurable thresholds where supplied; otherwise mark the threshold for owner decision.
8. Prioritized requirements backlog
- Table with requirement ID, requirement statement, priority, rationale, dependency, owner, acceptance method, evidence status, and readiness state.
9. Decisions, risks, and open questions
- Separate confirmed decisions from proposed decisions. For each risk or unresolved question, include impact, likelihood where defensible, mitigation or options, decision owner, approval point, and due stage. Highlight privacy exposure, misleading aggregation, stale data, source instability, access leakage, reconciliation failure, and performance risk when applicable.
10. Acceptance and reconciliation plan
- Table with test ID, linked requirement, scenario, preconditions, test data or evidence, procedure, expected result, actual result, status, and responsible reviewer. Include a traceability summary showing whether every high-priority requirement has at least one acceptance test and an owner.
11. Approval and handoff state
- List the artifacts ready for review, unavailable evidence, blocking decisions, required business, data, security, and BI approvals, and the smallest safe next action. Label the overall result draft, blocked, ready for review, or approved only when the corresponding evidence exists. Never describe work as validated, tested, approved, implemented, published, or complete without evidence that the action occurred.
## Step 3 — Build an Internal Operations Dashboard from Approved Metrics
**Prompt**
Build an Internal Operations Dashboard from Approved Metrics
**Instructions**
Implement the internal dashboard without redefining metrics.
**Input for this step**
Approved metric contracts and dashboard specification, authorized repository/data context, roles.
**Carry forward**
Dashboard change manifest, metric-component traceability, reconciliation, access/performance tests, rollback handoff.
**Review note**
Stop if data access is unauthorized, metrics conflict, confidential data is exposed, or publishing is requested.
**Prompt ID**
AMO-P-000341
**Prompt URL**
https://amo.ng/prompts/build-internal-operations-dashboard-approved-metrics
**Prompt content**
Implement a functioning internal operations dashboard in the supplied repository using the approved metric contracts and access rules. Make actual repository changes only when the repository, data interface, authorized scope, and test environment are available. Do not redefine business meaning or publish the dashboard.
## Required inputs
Approved metric contracts, including stable metric IDs, formulas, grain, units, inclusions, exclusions, time rules, dimensions, tolerances, and owners:
{{approved_metric_contracts}}
Repository, application stack, schemas or data interfaces, sanitized samples, existing query patterns, and permitted read-only or test access:
{{repository_and_data_context}}
Approved roles, permissions, row or tenant boundaries, confidential-metric rules, and access-review owners:
{{roles_and_access_rules}}
Approved views, decisions supported, components, filters, date behavior, refresh expectations, exports, states, and operational requirements:
{{dashboard_requirements}}
Acceptance criteria, allowed files and commands, performance budgets, rollout controls, prohibited actions, reviewers, and release authority:
{{acceptance_criteria_and_authorized_scope}}
## Evidence and assumption rules
- Classify consequential statements as supplied definition, observed repository or data evidence, inference, assumption, conflict, missing information, or execution evidence. Cite metric IDs, files, schema objects, queries, fixtures, and test output where available.
- Treat the approved metric contracts as the business-definition authority. Do not silently reconcile conflicting formulas, grains, periods, status rules, currencies, or owners. Mark the affected metric and dependent components Blocked until the metric owner resolves the conflict.
- Inspect the repository before editing. Read applicable instructions, check the working tree, identify unrelated changes, and preserve them. Do not overwrite, reformat, stage, commit, or discard work outside the approved scope.
- Do not invent fields, joins, source-of-truth designations, metric values, access rules, refresh success, production performance, test results, or approvals. Sample and fixture results are not production evidence.
- Minimize data. Use synthetic, sanitized, aggregated, or approved read-only test data. Never request passwords, tokens, connection strings, private keys, production exports, or unnecessary personal information.
## Authorization boundary
Work only in the supplied repository and authorized test or read-only data environment. Change only approved application, query, configuration, and test files. Ask before installing dependencies, changing lockfiles, creating migrations, changing authorization policy, making an external request, or executing an operation with material data or cost impact.
Do not grant production access, modify source-system records, publish or deploy the dashboard, expose confidential metrics, use unapproved personal data, change approved metric definitions, enable a production refresh, or present sample results as live operating evidence. Production credentials and live data are not required and must not be requested.
## Implementation method
1. Establish the contract. Build a metric-to-component register covering each approved metric ID, formula, grain, dimensions, filters, date and timezone rule, source fields, confidentiality class, owner, display component, and acceptance test. Identify unresolved conflicts and stop work on dependent components rather than selecting a definition.
2. Inspect the implementation context. Identify framework and version, routes, controllers or handlers, query and data-access layers, models or schemas, authorization mechanisms, UI and chart conventions, caching, background refresh behavior, export support, tests, observability, and existing performance budgets. Record only what was inspected.
3. Present a concise implementation checkpoint. List the files expected to change, metrics and views covered, queries or interfaces affected, authorization checks, test commands, risks, rollout control, and recovery plan. Ask only questions that block safe implementation.
4. Implement source access and calculations. Reuse approved query and semantic-layer conventions. Preserve declared grain before joining or aggregating, parameterize filters, apply explicit date and timezone boundaries, handle nulls and duplicates according to the metric contracts, and make source and refresh timestamps visible where required. Avoid unbounded queries and N+1 access patterns.
5. Implement the dashboard components. Connect each component to stable metric IDs and approved labels. Add required date ranges, filters, segmentation, units, comparisons, and drill paths. Preserve filter state and communicate when filters alter the population or denominator. Do not add unsupported interpretation or recommendations to the UI.
6. Implement observable states. Provide appropriate loading, empty, no-access, stale, partial-data, validation, timeout, source-unavailable, and unexpected-error behavior. A stale or partial result must not look current or complete.
7. Enforce access on the server side. Apply the approved roles, tenant or row boundaries, and confidential-metric restrictions at the data and endpoint layers, not only by hiding components. Test allowed and denied paths. Do not broaden existing permission grants.
8. Implement export only when expressly authorized. Apply the same filters, definitions, and access boundaries as the displayed result. Include relevant generated-at and freshness context. Neutralize spreadsheet-formula injection for text fields and avoid exporting hidden or unauthorized columns. Keep export absent or disabled when its contract is unresolved.
9. Check accessibility and performance. Use semantic structure, accessible names, keyboard-operable controls, visible focus, non-color-only status cues, meaningful table headers, and readable error states. Measure authorized query counts, query plans, response times, payloads, and rendering costs against supplied budgets. Do not claim formal accessibility or production performance from incomplete checks.
10. Verify calculations and failure paths. Use approved fixtures, sanitized extracts, or authorized read-only results. Recalculate representative metrics independently; reconcile totals to supplied authoritative results within approved tolerances. Test date and timezone boundaries, segment totals, nulls, duplicates, empty data, stale data, source failure, unauthorized roles, filter combinations, export boundaries, slow queries, and applicable responsive behavior. Record commands, inputs, outputs, and checks not run.
11. Prepare reversible rollout and handoff. Prefer an existing feature flag, protected route, or equivalent reversible control when supplied. Document changed files, configuration, cache implications, rollback steps, required monitoring, and release-owner gates. Do not activate the feature in production.
## Stop conditions
Stop with a precise blocked-handoff report when an approved metric contract is missing or contradictory, the repository or safe data interface is unavailable, authorization rules are unresolved, supplied data would expose prohibited information, overlapping working-tree changes cannot be preserved, required validation needs production mutation, or implementation exceeds the allowed files or actions. Do not replace missing definitions with inferred business logic.
## Output contract
Return:
1. Implementation status: Implemented, Partially implemented, or Blocked.
2. Evidence and data scope, including exactly what was inspected and what remains unavailable.
3. Metric-to-component traceability table: metric ID, source and grain, implementation location, display component, access rule, test, result, and evidence.
4. Repository change manifest: file, reason, metric or requirement served, substantive change, and rollback action.
5. Data and query record: source objects, joins, filters, aggregation, date and timezone logic, freshness, limits, and unresolved assumptions.
6. Access-control matrix: role, allowed data or action, enforcement point, test case, and observed result.
7. Reconciliation table: metric and slice, expected value, implemented value, tolerance, difference, evidence, and status.
8. State, export, accessibility, and performance verification results.
9. Complete test matrix with command or procedure, fixture or evidence, expected result, actual result, and Passed, Failed, Not run, or Blocked status.
10. Unresolved decisions, accountable owner, and smallest safe next action.
11. Feature-disable, file, configuration, and data recovery instructions.
12. Operational and release-owner handoff explicitly stating that no production access was granted and the dashboard was not published or deployed.
Completion requires an approved definition behind every displayed metric, traceability from metric to source to component to test, verified access boundaries, reconciled representative calculations, accounted-for error and stale states, preserved unrelated work, and a reversible handoff. Use Partial or Blocked when any material condition is unmet. Never describe the dashboard as accurate, secure, accessible, production-ready, published, or complete without the corresponding evidence and accountable approval.
## Step 4 — Automate KPI Reporting from Approved Metric Definitions
**Prompt**
Automate KPI Reporting from Approved Metric Definitions
**Instructions**
Reuse the approved contracts and implemented transformations to build disabled recurring KPI reporting.
**Input for this step**
Step 1 contracts, verified source mappings and calculation evidence from step 3, report and destination contract.
**Carry forward**
Report implementation, calculation traceability, reconciliation, failure/rerun tests, disabled schedule/delivery evidence.
**Review note**
Stop for unapproved data, disputed metrics, unavailable source contracts, or any request to enable delivery.
**Prompt ID**
AMO-P-000343
**Prompt URL**
https://amo.ng/prompts/automate-kpi-reporting-approved-metric-definitions
**Prompt content**
Implement a repeatable KPI-reporting process from the approved metric definitions. Work only in the authorized repository and non-production data context supplied in this session. The result must be working code or editable configuration with test evidence, not another metric definition, dashboard brief, audit, or implementation plan.
## Required inputs
Approved metric definitions:
{{approved_metric_definitions}}
Source and repository context:
{{source_and_repository_context}}
Report and output specification:
{{report_and_output_specification}}
Schedule and destination contract:
{{schedule_and_destination_contract}}
Acceptance criteria and authorized scope:
{{acceptance_criteria_and_authorized_scope}}
## Evidence and assumption rules
1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite file paths, symbols, configuration keys, supplied data-contract sections, and command results where available.
2. Do not invent metric definitions, formulas, owners, source fields, joins, schedules, destinations, tolerances, credentials, data values, command output, test results, or approvals.
3. Treat the approved metric definitions as the calculation authority. If definitions conflict or omit a material grain, formula, inclusion, exclusion, time, currency, unit, or rounding rule, stop the affected metric and request a decision from the data owner. Do not redefine or silently reconcile it.
4. Distinguish sanitized fixture results from observations made against an approved read-only source. Never present fixture output as production evidence.
5. Use only the minimum data needed for implementation and testing. Do not request secrets, credentials, production exports, unnecessary personal data, or confidential values. Refer to connections through environment-variable or credential-reference names, never values.
6. Preserve unrelated repository and configuration changes. Do not reformat, replace, or repair out-of-scope work.
## Authorization boundary
- Implementation requires an editable repository or configuration export, approved metric contracts, a usable output specification, and either sanitized fixtures or an explicitly authorized read-only data source.
- Inspect only the supplied workspace, files, schemas, interfaces, fixtures, and command output. Do not imply access to a source, scheduler, reporting destination, or production environment that is not available in this session.
- You may change only files and configuration within the supplied authorized scope. Keep schedules disabled and external delivery disconnected or directed to an approved test sink.
- Do not mutate source systems, enable a production schedule, send a report, publish an output, change access, make a management decision, install dependencies, run a destructive migration, deploy, merge, commit, or communicate externally unless separately authorized.
- Stop before any irreversible data operation, production connection, external send, secret exposure, destructive command, or change outside the allowed file boundary. State the blocked action, evidence needed, accountable owner, and safest next step.
## Implementation method
### 1. Run the input gate
For every metric, confirm that the supplied contract identifies its stable identifier, business meaning, formula, source, grain, dimensions, inclusions, exclusions, date field, timezone, currency or unit behavior, null treatment, correction or restatement treatment, precision, rounding rule, owner, and reconciliation tolerance where applicable.
Confirm the report structure, period controls, sort order, labels, file or view format, destination, schedule, and acceptance criteria. Record missing or contradictory items. If a missing item could alter a calculation or disclose data, block that metric rather than guessing.
### 2. Inspect the implementation context
Before editing, inspect the repository tree, current working-tree state, framework and runtime, package manifests, relevant source adapters, models or queries, transformation code, report generators, scheduling configuration, delivery adapters, test framework, fixtures, logging, and existing operational documentation.
Identify what is observed, unavailable, or not inspected. Establish the current baseline using only safe, authorized commands. Do not add a dependency when the existing stack can meet the contract.
### 3. Create a concise implementation checkpoint
Map each metric and acceptance criterion to the files, functions, queries, transformations, report sections, fixtures, and tests that will implement it. State the intended changes, protected files, authorized commands, external effects that will remain disabled, and rollback method.
If there is no editable workspace, approved metric contract, safe data interface, or testable output target, stop with a blocked handoff. Do not substitute pseudocode and call the work implemented.
### 4. Implement source extraction safely
Use approved read-only interfaces or sanitized fixtures. Implement explicit source selection, field mapping, filters, join keys, expected cardinality, incremental or full-extract behavior, and watermark or cutoff handling where required.
Validate missing fields, malformed values, duplicates, late records, corrected records, unexpected nulls, and schema changes. Fail visibly when a required source or field is unavailable. Do not update source records as part of reporting.
### 5. Implement transformations and calculations
Implement the approved formulas exactly. Preserve source-to-metric traceability through named transformations, tests, or generated lineage metadata supported by the repository.
Apply the stated grain, dimensions, eligibility rules, dates, timezones, currencies, units, precision, rounding, and restatement behavior. Prevent invalid aggregation, duplicate contribution, divide-by-zero, silent coercion, and implicit timezone or currency conversion. When a metric contract remains unresolved, return an explicit unavailable or blocked state rather than a fabricated value.
### 6. Implement report generation
Generate the approved report shape with stable labels, ordering, period markers, source freshness, generated-at time, unit or currency labels, and data-quality status where specified. Make empty, partial, stale, and failed states distinguishable from a true zero.
Keep output deterministic for identical approved inputs. Normalize ordering and formatting where needed, and avoid volatile values in comparisons unless the contract requires them.
### 7. Implement scheduling and delivery in a disabled state
Represent the approved schedule, timezone, cutoff, destination, retry policy, and ownership in editable configuration, but leave the schedule disabled. Keep external delivery disabled, disconnected, or directed to an approved test sink.
Provide evidence of the disabled state without revealing credential values. Do not send messages, upload reports, publish files, or activate jobs.
### 8. Add rerun, idempotency, and recovery controls
Define a stable run identity and reporting period. Ensure a retry cannot create duplicate outputs or inconsistent partial files. Use atomic output replacement, temporary files, checkpoints, or equivalent repository conventions when appropriate.
Handle extraction failure, transformation failure, report-generation failure, unavailable destinations, and uncertain completion. Preserve enough safe diagnostic evidence to reconcile a failed run. Document how to resume, rerun, quarantine, replace, or roll back an output without changing authoritative source data.
### 9. Reconcile to authoritative supplied totals
For each metric with an approved comparison, reconcile record counts, component totals, final values, period boundaries, and tolerances. Record absolute and relative differences where meaningful. A tolerance pass must use the supplied rule; do not invent one after seeing the result.
Treat unexplained differences as unresolved. Do not force a match through an undocumented filter, adjustment, or overwrite.
### 10. Test domain-specific failure paths
Create and run the narrowest safe tests supported by the repository. Cover, as applicable:
- an approved valid period and expected metric fixture;
- missing, duplicate, late, corrected, and malformed records;
- null, zero, negative, boundary, currency, unit, rounding, and timezone cases;
- invalid joins, unexpected cardinality, schema drift, and unavailable sources;
- empty, partial, stale, and failed report states;
- deterministic output for repeated identical inputs;
- rerun idempotency and recovery after failure between extraction, calculation, generation, and delivery;
- reconciliation within and outside the declared tolerance;
- disabled scheduling and disabled external delivery.
Record each exact command and its exit status. If a test cannot run, mark it not run or blocked and explain why. A successful build is not calculation evidence, and fixture success is not proof about production data.
### 11. Prepare the operational handoff
Describe configuration inputs, schedule and destination enablement steps, required permissions, monitoring signals, reconciliation cadence, data-quality alerts, failure ownership, rerun procedure, output rollback, and post-release checks. Enabling, sending, and release remain actions for the data owner and release owner under their normal change process.
## Stop conditions
Stop with a precise blocked handoff when any of the following applies:
- metric meaning or a material calculation rule is missing or conflicting;
- the repository, editable configuration, approved fixture, or authorized read-only source is unavailable;
- requested access exceeds the supplied authority;
- a source write, production schedule, external delivery, deployment, or destructive change would be required;
- confidential or personal data cannot be minimized and protected;
- expected totals or tolerances would need to be invented;
- tests expose an unexplained calculation or reconciliation failure;
- rollback or safe rerun behavior cannot be established.
## Output contract
Return these sections:
1. **Implementation status**: `Implemented and tested in the authorized environment`, `Partially implemented`, or `Blocked`. Separate requested, inspected, changed, executed, demonstrated, and unresolved work.
2. **Evidence and assumptions register**: source, classification, location, relevance, limitations, and owner needed for each material item.
3. **Metric implementation register**: metric ID, approved formula reference, grain, dimensions, time and unit rules, implementation location, test coverage, status, and unresolved issue.
4. **Source-to-report traceability**: source fields, extraction, transformations, calculations, report fields, filters, and evidence references.
5. **Repository change manifest**: every file or configuration item changed, purpose, acceptance criterion, applied or proposed state, and rollback method.
6. **Calculation and transformation record**: implemented logic, boundary handling, unresolved conflicts, and direct evidence.
7. **Reconciliation matrix**: metric, period, authoritative supplied value, implemented result, difference, declared tolerance, status, and evidence. Do not fill unavailable values.
8. **Failure and rerun test matrix**: case, fixture, expected observation, actual observation, command, status, idempotency result, recovery result, and evidence.
9. **Disabled schedule and destination evidence**: configured schedule and destination references, disabled state, test sink if any, and evidence without secrets.
10. **Recovery instructions**: detection, containment, safe rerun, reconciliation, output rollback, escalation threshold, and owner.
11. **Data-owner and release-owner handoff**: outstanding definition decisions, access or privacy review, activation prerequisites, release checks, and approvals. Do not make management decisions.
12. **Completion statement**: map every acceptance criterion to implementation and execution evidence. End with the smallest safe next action and its accountable owner.
Completion requires actual authorized repository or configuration changes, traceability for every implemented metric, domain-specific tests with recorded results, reconciliation or an explicit unresolved result, proof that scheduling and delivery remain disabled, and workable recovery instructions. Otherwise report partial or blocked status without claiming the automation is complete, accurate, production-ready, scheduled, or delivered.
## Step 5 — Business KPI Dashboard Trust and Definition Audit
**Prompt**
Business KPI Dashboard Trust and Definition Audit
**Instructions**
Reconcile definitions, source lineage, dashboard/report outputs, freshness, and decision trust.
**Input for this step**
Implemented dashboard/report evidence, authoritative totals, owner-approved definitions, test outputs.
**Carry forward**
Trust classification, discrepancy register, decision restrictions, remediation owners and release recommendation.
**Review note**
Hold decision use when material reconciliation, freshness, definition, or ownership evidence is missing.
**Prompt ID**
AMO-P-000228
**Prompt URL**
https://amo.ng/prompts/business-kpi-dashboard-trust-definition-audit
**Prompt content**
You are an expert business intelligence, data governance, and performance reporting analyst specializing in KPI definitions, dashboard reliability, data lineage, source-of-truth governance, reconciliation, executive reporting, and decision risk.
Analyze the supplied KPI dashboard and supporting context. Produce an evidence-based trust and definition audit that identifies where metric meaning, calculation logic, data sources, transformations, refresh timing, ownership, or presentation may create unreliable or misleading decisions.
## Context Placeholders
Use the supplied context. If critical information is missing, ask for it before assigning a trust status or recommending changes to executive reporting.
- [Dashboard link, screenshots, or export]
- [KPI list]
- [Business purpose]
- [Metric definitions]
- [Calculation logic]
- [Data sources]
- [Transformations or semantic layer]
- [Filters and exclusions]
- [Reporting period and timezone]
- [Refresh cadence and last refresh]
- [Report and metric owners]
- [Conflicting reports]
- [Executive or operational decisions supported]
- [Known issues]
- [Historical comparisons or reconciliations]
- [Allowed changes]
- [Audit deadline]
## Important Constraints
- Do not invent KPI values, definitions, formulas, source systems, refresh results, owners, reconciliation differences, targets, benchmarks, or business impact.
- Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations.
- Distinguish clearly among:
- Business definition
- Technical calculation
- Dashboard display
- Source-system value
- Interpretation used in decisions
- Do not treat a KPI label as a complete definition.
- Do not assume that metrics with the same name use the same population, grain, period, filters, attribution rules, currency, timezone, or calculation logic.
- Do not treat a successfully refreshed dashboard as proof that the underlying data is complete, accurate, or current.
- Do not treat a visually polished dashboard as evidence of reliability.
- Do not classify a metric as trusted without evidence supporting its definition, source, transformation, freshness, reconciliation, and ownership.
- Do not create trust percentages or confidence scores unless a scoring method has been supplied.
- Do not silently choose one conflicting report as the source of truth.
- Do not recommend changing KPI definitions, historical values, targets, executive reports, compensation calculations, forecasts, public statements, or board materials without named owner approval.
- Do not recommend deleting, overwriting, backfilling, restating, or republishing dashboard data without backup, impact review, approval, and rollback steps.
- Preserve the distinction between data defects, definition disagreements, timing differences, filter differences, and legitimate reporting variations.
- Flag personal data, restricted financial information, confidential customer data, row-level security concerns, and inappropriate dashboard access.
- If the dashboard, query, export, or supporting documentation is incomplete, state how that limits the audit.
- If evidence conflicts, show the conflict and identify what must be verified before a conclusion is accepted.
## Step-by-Step Instructions
1. Review the dashboard purpose, intended audience, decisions supported, KPI list, known concerns, owners, and audit deadline.
2. Create a dashboard inventory covering:
- Dashboard or report name
- Business purpose
- Audience
- Decision use
- Owner
- Data source
- Refresh cadence
- Last confirmed refresh
- Criticality
3. Review each KPI definition for:
- Business meaning
- Numerator
- Denominator
- Unit
- Population
- Inclusion criteria
- Exclusion criteria
- Record grain
- Reporting period
- Timezone
- Currency
- Status rules
- Attribution window
- Cohort treatment
- Handling of cancellations, refunds, reversals, duplicates, and missing values
- Historical restatement policy
4. Distinguish the approved business definition from the implemented calculation.
5. Trace the data lineage for each material KPI:
- Source system
- Source object, table, report, or file
- Extraction method
- Transformations
- Joins
- Filters
- Aggregations
- Semantic or modelling layer
- Dashboard query
- Display formatting
- Downstream exports
6. Review calculation and transformation risks, including:
- Broken or incorrect joins
- Duplicate amplification
- Missing records
- Many-to-many relationships
- Changed field meaning
- Schema drift
- Incorrect aggregation
- Distinct-count errors
- Null handling
- Currency conversion
- Timezone conversion
- Late-arriving data
- Restated source data
- Snapshot versus live-data differences
- Cached dashboard results
7. Review filters and dashboard controls. Identify:
- Hidden filters
- Default date ranges
- Excluded segments
- User-specific filters
- Row-level security
- Drill-down inconsistencies
- Filters that do not apply uniformly across visuals
- Export results that differ from the displayed dashboard
8. Review refresh reliability:
- Scheduled refresh status
- Last successful run
- Partial refresh risk
- Delayed source data
- Failed credentials
- API or extract limits
- Query timeouts
- Cached results
- Manual refresh dependencies
- Missing freshness indicators
9. Compare conflicting reports. Determine whether differences arise from:
- Definition
- Population
- Grain
- Period
- Timezone
- Currency
- Filters
- Attribution
- Source system
- Refresh time
- Transformation logic
- Manual adjustments
- Data defects
10. Reconcile material KPIs to available source records, approved reports, finance records, operational systems, or controlled extracts.
11. Assess metric ownership. Confirm:
- Business owner
- Technical owner
- Data steward
- Definition approver
- Dashboard maintainer
- Escalation owner
- Review frequency
- Change-control responsibility
12. Classify each metric using only the following statuses:
- `Trusted`
- `Trusted with caveats`
- `Unverified`
- `Contradicted`
- `Not decision-ready`
- `Retired or duplicated`
13. Do not use `Trusted` unless the definition, implementation, source, freshness, reconciliation, and ownership are sufficiently supported.
14. Assess the decision risk attached to each KPI. Consider:
- Financial materiality
- Operational impact
- Customer impact
- Forecast impact
- Compensation impact
- Regulatory or reporting exposure
- Frequency of use
- Reversibility of the decision
15. Separate:
- Confirmed dashboard defects
- Definition disagreements
- Data lineage gaps
- Refresh and freshness risks
- Ownership gaps
- Presentation risks
- Decision-use risks
- Issues requiring further validation
16. Recommend immediate containment separately from permanent remediation.
17. Define verification, documentation, ownership, monitoring, signoff, rollback, and follow-up actions.
## Output Format
Use markdown sections and concise tables where comparison, reconciliation, ownership, or status tracking is useful.
### Executive Summary
Summarize the dashboard purpose, overall trust position, most material concerns, affected decisions, immediate containment, and recommended next action.
### Context Review and Audit Limitations
List the supplied evidence, missing critical inputs, known limitations, and assumptions affecting the audit.
### Dashboard Inventory
| Dashboard or Report | Purpose | Audience | Decision Use | Owner | Source | Refresh Status | Criticality |
|---|---|---|---|---|---|---|---|
### KPI Definition Review
| KPI | Business Definition | Population and Grain | Period and Timezone | Filters and Exclusions | Definition Gap |
|---|---|---|---|---|---|
### Definition-to-Implementation Comparison
| KPI | Approved Definition | Implemented Logic | Difference | Evidence | Impact |
|---|---|---|---|---|---|
### Data Lineage Review
| KPI | Source | Transformation | Join or Aggregation | Dashboard Output | Lineage Gap |
|---|---|---|---|---|---|
### Calculation and Data Quality Findings
| Finding | KPI Affected | Evidence | Likely Cause | Decision Impact | Validation Required |
|---|---|---|---|---|---|
### Filter, Period, and Presentation Review
Assess hidden filters, date ranges, timezone, currency, segment exclusions, drill-down behaviour, display rounding, labels, and export differences.
### Refresh and Freshness Review
| Data Source or Dashboard | Expected Cadence | Last Confirmed Refresh | Observed Issue | Staleness Risk | Owner |
|---|---|---|---|---|---|
Do not invent refresh dates where logs or dashboard evidence are unavailable.
### Conflicting Report Analysis
| KPI | Report A | Report B | Difference | Likely Explanation | Required Decision |
|---|---|---|---|---|---|
Do not select a source of truth without documented owner approval.
### Reconciliation Results
| KPI or Control Total | Dashboard Result | Source or Reference Result | Difference | Status | Explanation |
|---|---|---|---|---|---|
Where full reconciliation is unavailable, propose a representative sample and state its limitations.
### Metric Trust Classification
| KPI | Trust Status | Supporting Evidence | Caveat or Gap | Approved for Decision Use? |
|---|---|---|---|---|
Use only the permitted trust statuses.
### Decision Risk Matrix
| Decision | KPI Dependency | Trust Concern | Potential Impact | Materiality | Owner Review |
|---|---|---|---|---|---|
Do not invent materiality thresholds. Use `To be agreed` where no threshold has been supplied.
### Ownership and Governance Review
| KPI or Dashboard | Business Owner | Technical Owner | Definition Approver | Review Cadence | Governance Gap |
|---|---|---|---|---|---|
### Immediate Containment
List reversible actions that reduce current decision risk without overwriting, restating, deleting, or republishing data.
### Fix and Signoff Plan
| Priority | Action | Owner | Evidence Required | Approval Gate | Verification | Rollback |
|---|---|---|---|---|---|---|
### Monitoring Plan
| Control | Trigger | Expected Condition | Alert Owner | Review Frequency |
|---|---|---|---|---|
Mark undefined thresholds or tolerances as `To be agreed`.
### Executive Reporting Caveats
Draft concise caveats that accurately communicate unresolved metric, freshness, reconciliation, or ownership concerns.
Do not conceal material uncertainty or present unverified figures as final.
### Risk Register
| Risk | Evidence | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
### Unresolved Questions
List only questions that could materially change the trust classification, decision-risk assessment, or remediation plan.
## Verification Checklist
- Confirm every material KPI has a clear business definition.
- Confirm the definition includes population, grain, period, timezone, unit, filters, and exclusions where relevant.
- Confirm approved definitions are compared with implemented calculations.
- Confirm source systems, transformations, joins, filters, and aggregations are traced.
- Confirm metrics with the same name are not assumed to use the same logic.
- Confirm refresh success is not treated as proof of completeness or accuracy.
- Confirm hidden filters, default periods, row-level security, caching, and export differences are reviewed.
- Confirm conflicting reports are explained before a source of truth is selected.
- Confirm material KPIs are reconciled where supporting evidence is available.
- Confirm trust classifications are evidence-based and use only the permitted statuses.
- Confirm executive-ready claims include material caveats.
- Confirm source-of-truth, definition, restatement, and publication decisions require owner signoff.
- Confirm historical values are not overwritten or restated without approval and rollback steps.
- Confirm every decision risk is tied to a specific KPI, source, calculation, freshness issue, or governance gap.
- Confirm every major finding is supported by supplied evidence or clearly labelled as an assumption.
## Final Instruction to Begin
Begin by reviewing the dashboard purpose, KPI list, definitions, calculation logic, data sources, transformations, filters, refresh evidence, owners, conflicting reports, and decisions supported.
If critical context is missing, ask only the questions necessary to continue safely. Otherwise, produce the complete KPI dashboard trust and definition audit in the requested markdown format.
## Completion criteria
No metric is silently redefined; dashboard and report calculations trace to the same approved contract; access/data-state/failure behavior is tested; authoritative totals are reconciled or discrepancies bounded; schedule and external delivery remain disabled; owners accept or hold decision use.
Completion criteria
Complete when every implemented output traces to an approved metric ID; dashboard and report calculations use the same governed contract; access, stale/error, date/timezone, and rerun paths have recorded results; authoritative totals reconcile within approved tolerances or differences remain explicitly blocked; delivery remains disabled; and accountable owners receive the release and recovery evidence.
Was this useful?
Component Prompts
Browse PromptsMetric Definition Contract and Semantic Layer Blueprint
Turn disputed metrics into testable, versioned semantic contracts with explicit grain, time logic, lineage, access controls, ownership, and change governance.
Dashboard Requirements Specification Prompt
Turn dashboard goals, user decisions, KPI definitions, data sources, interactions, and governance constraints into an implementation-ready requirements specification.
Build an Internal Operations Dashboard from Approved Metrics
Implement an internal operations dashboard from approved metric contracts, with source reconciliation, enforced access rules, observable data states, performance evidence, and a reversible release handoff.
Automate KPI Reporting from Approved Metric Definitions
Implement a repeatable KPI-reporting process from approved metric definitions, with traceable calculations, authoritative reconciliation, failure and rerun tests, disabled delivery, and recovery evidence.
Business KPI Dashboard Trust and Definition Audit
Audit a business KPI dashboard for ambiguous metric definitions, unreliable data sources, stale logic, conflicting reports, ownership gaps, and decision risk.
Explore related Workflows
Browse WorkflowsBuild a Governed KPI Dashboard from Approved Metric Definitions
Translate already-approved metric definitions into a SQL-backed internal dashboard, with source-field mapping, authorized implementation, query-result reconciliation and an accountable release review. Metric definition approval and recurring report automation are outside this Workflow.
Safely Plan, Build, Review, and Release a High-Risk Laravel Feature
Prepare a Laravel repository for AI-assisted coding, plan a complex feature, control migration and rollout risk, implement only within approved scope, review the pull request, and produce deployment-readiness evidence.
Safely Build and Review a Multi-Tenant Laravel Feature
Plan, implement, and review one approved multi-tenant SaaS feature with migration safety, authorization coverage, test evidence, pull-request review, and deployment readiness controls.